November 17, 2017

In depth security... what when the tables are turned?

With many new initiatives at governments and organisations in the area of security, I see that tables are being turned... and initiatives are lagging. Again.


We all do our best keeping the baddies out of our systems, away of our data. But what if the baddies try to do the same? Trying to keep us out of our systems, away from our data? There's a new threat in town, it's our own systems.

Lately I have been talking a lot with one of the Information Risk Managers of one of my clients. Let's call him Frank, it makes writing this post a lot simpler.
So Frank is a different kind of Information Risk Manager. He's very much involved and active in product development. Frank's not policing, he's establishing policies in stead. Mind that I'm specifically not saying that he's writing policies, instead he's establishing them. Together with those around him that are supposed to live according to these policies, he is ensuring that every step of the way, they're involved. It's pretty cool. Then again, Frank is pretty cool.

Frank and I have been doing a couple of security awareness sessions at the client's site. These sessions revolve around Secure Software Development and the intention of these sessions is making sure that those that are developing the products know that they need to build in security from the start. Yes, we are only looking at IT peeps, even though security is obviously a business concern. Well, one step at a time.

I take it that you're well aware of OWASP's top 10. And likely you've at least heard somebody mentioning the GDPA, General Data Protection Act. And considering you're reading this post, you haven't lived under a rock in the past couple of years, so data breaches like the one at Equifax or Yahoo for that matter should be known facts by you.
I love it when these things are being discussed. Stolen passwords, accounts hacked, social engineering to get into systems. Examples galore to justify all those millions of Euro's and Dollars spend on security. Implementing all kinds of programs at enterprises and organisations. At one client I actually told the ISO (Information Security Officer) that his presentation on the topic leaned towards plain old terrorism considering how she was scaring the CFO to approve her budget request.
Well Frank is not like that. Instead Frank is explaining why awareness is so important. He's addressing it from a business benefit to do in-depth security, privacy by design and so on. I actually had to talk firmly to Frank and have a slide in his deck to convey the amount of vulnerabilities found in our systems in the past couple of months. Just to show that not doing anything is not an option. Reluctantly Frank complied.

At this client, we do threat modeling. We do Privacy Impact Analysis, Business Impact Analysis, etc. We analyse a lot. And we're moving into a way of doing all this such that the developers can keep on becoming more and more agile. Sprint based, epic-by-epic, one story at a time. Ensuring that nobody gets into the systems, privacy sensitive information is encrypted and transaction integrity is ensured.
Nobody gets in, and who's in can't see any data and those that can, won't be able to change is. It's awesome, it's secure. And it's lagging behind today's and more importantly tomorrow's threats.

We're spending so much time to lock things down, in depth, on all levels, by design. Making sure that there're no backdoors, systems are patched. But what about the threat of being locked out yourself?

Data hostage is the new trend. With the advent of biometrics, access to systems by certain individuals becomes more prevalent. Unless it's your iris, you won't get into the server room. Unless it's your fingerprint, you won't be able to unlock the device. With face recognition systems build into operating systems like Windows 10, iOS and Android you only have to look at your screen to be granted access to all that data.

Frank knows about all this stuff as well. Together with a couple of really smart developers he's working on utilizing this new tech to make security more convenient for employees that need to access on a regular basis, sensitive information from their devices. Multi-factor, with biometrics as a second factor is around the corner. It'll be all about what you know (PIN or password) and who the system recognises.

This makes it more and more interesting for cyber criminals to no longer try to get access to your data and instead prevent you to get access to your data. When we rely heavily on the uniqueness of our bodies. By storing precise information about a person's iris, face-metics, fingerprints and in the (near) future a person's DNA, we can ensure that people are uniquely identified. But what is going to happen when that data is compromised? 'Access Denied'.
In today's systems where identification is based on what you know and what you, we are nog focussing on corruption of passwords, PINs or authenticator apps. We're focussing on people not getting in, but we forget about people keeping us out. And when you can't get in, your systems are held hostage. Not only your data, which is typically the target of today's Ransom-ware.

We need to think of new architectures that also consider this aspect of security. It's the availability aspect of security. Data and systems need to be available, but consequently also accessible. Availability is typically associated with redundancy and clustering. Cloning and mirroring. On a more functional level it is associated with the GDPA views on a person's right to always access her data and the right to be forgotten. But what if access is denied? What if you're locked out?

Another interesting feat today is that once security is breached, users need to be informed. But what about the reverse. Your security wasn't breach in the sense that people gained access, but instead people removed your access?

This is new territory for many of us and I don't have a suitable solution for these kind of threats. What I do know is that you'll need to address this from your architecture. And you'll need to involve your Information Risk Manager from day one. And make her tag along full time. Constantly. Just like I talk with Frank on a steady basis. Sharing thoughts, discuss the philosophy of security and challenge each other on everything but mainly on how we can make everybody involved in the process of product development aware of these at times very interesting nuggets of architecture.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.


October 20, 2017

What's the story about those other user stories?

User stories expressing what the Product Owner or her Team want or need are bad practice. The PO delivers, never requests!


Backlogs containing user stories that are catering for the needs and wishes of a Product Owner or Product Team are faulty. These kind of stories are unable to compete with stories that clearly add value to the business. By putting these stories on the PO's backlog compromise the ability of the PO to be successful. Instead these stories should be listed on a second backlog owned by the Team. This will improve the team's sense of autonomy, the Team's relationship with the PO.

In the past 6 months or so I've been actively working with agile teams on their backlogs. Specifically the Product Owners. As you might already know, I consider the Product Owner role as one of the most demanding and challenging roles within an agile environment. You might want to read my post on it, which you can find here. One of the major challenges I'm facing in working on backlogs is getting the Product Owner, and also the Product Team to understand why internal user stories are a bad-practice.

Internal user stories are those stories the PO wants, or the team itself. Most of the time, these are stories where an upgrade of some technology is needed, where technical debt is taken care of, or for example where the Product Owner wants some reporting from the tooling. There're any number of stories on backlogs where it is the Team or the PO in the 'I as a ...' clause of the story. Look at your own backlog and see for yourself.

You might have read my post "Perish or Survive, or being Efficient vs being Effective" on what agile encompasses in terms of motivation, or drive. When you commit to agile practices, you commit to effectiveness and in pretty much all cases you commit to a value-driven approach towards what has the highest priority.

Considering the above, than you realize that in most cases, internal user stories are not really creating value. Mind that you will have to consider the story and not the motivation for the story. Be pure in thought.
This is because of the simpel fact that the user, or customer requires and the PO (and her Team) delivers. That's all there is to it.

All of a sudden it is clear why a story like "We, the Product Team, want to upgrade to the next version of technology such and so, in order to reduce our technical debt" is a no-no on the backlog. Why? Because the user, nor the customer typically doesn't care and shouldn't care about the technology used.
Don't believe me? Well, have the user dictate the version of Ruby on Rails to be used in the development of an iPhone app and listen to what the Team has to say about this. I rest my case.
Having said that, it should also be clear that there is typically a more than valid reason why a Team wants to get rid of technical debt, even suggesting how to get rid of it as well. And in most cases it is related to the request of the user, demanding better stability, performance or security. The Team's story is an implementation aspect and nothing more.

Think about this a bit and then you're bound to see that when the PO or the Team will create their own stories and put them on the backlog, they will need to compete with the stories of the other stakeholders. Stories that add value, for the simpel reason that the stakeholders will ensure a clear value-add because that is what gets the story at the top of the backlog. (Provided the PO will actually prioritize the backlog based on business value and not things like vanity or volume of a voice.)
The last thing anyone should want is have the team's stories be relegated to the black-hole called "Tail-of-the-Backlog".

One of the most common ways of getting the things done, the Team wants done is by allowing the Team to spend some time on other things than stories. Sort of a budget expressed in time, the Team can spend on their own stories. I like to maintain the 80-20 rule here, as it can be applied in pretty much everything related to IT. So 80% of the time is spend on creating value, and 20% on something that is not necessarily adding value. How that 20% is allotted is up to the PO and her Team. Could be a day a week, could be two days during a two week sprint, or possible a full sprint once every five sprints.

I call it budget, because the PO's budget is expressed in time. She has a team available to her, a stable team paid for, for the lifespan of the Product she's owning. Consequently all she has is time to spend. Allowing the Team to work on their own stories, makes perfect sense. This is because the Team itself knows best on what stories are the most valuable. Whether it's the technology upgrade, the refactoring of old code or investigating some new concepts and their applicability.
Once the Team maintains its own backlog of its own stories, there is no need to compete with the stories of other stakeholders, the stories bound more clearly add stories. Moreover, the Team will more so be empowered to autonomously decide how stories are realized. Deciding when it is best to cut corners and when not. All of a sudden, the Team is not only responsible for the product's quality, but also accountable for the technical quality of the product.

The PO's backlog is one expressed in value creation, with the highest priority set to the story (potentially) creating the most value. Allowing the PO to be value-driven. The PO therefore can maintain a backlog consisting of user stories with clear stakeholders. People, not roles, that can be called upon to verify the product's ability to deliver value. And with the opportunity to ask these people beforehand how value is created, what metrics are needed to validate the product's benefits, etc. And of course, the story will contain the name(s) of the people to explicitly invite to the Team's demo of the product.
The Team's backlog at the same time can be prioritized on the account of what will reduce the product's costs the most. Accommodate for future developments as well as operational aspects, etc.

Maintaining both backlogs also strengthens the relationship between the PO and the Team, putting the emphasis on trust, accountability, facilitation and empowerment. The corner stones of agile teams.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.


October 9, 2017

ASAS2017 in hindsight

ASAS2017 in hindsight

A couple of days ago, Thursday October 5th to be exact, I attended ASAS2017. It was my fifth attendance of the Agile Software Architecture Symposium.


This year, as part of keeping a promise, I did a presentation at ASAS 2017 about Agile and Architecting. Adapting the presentation up to the last minute based on feedback I garnered while attending other presentations, I felt really agile.
One of the key take aways for me was that doing a Kahoot! to know the audience instead of raising hands makes a lot of sense when you want to know who your audience was. But you need to keep those stats. And it's almost imperative to have a clear means of being contacted shown on a slide. At the end.

A couple of days ago, Thursday October 5th to be exact, I attended ASAS2017. It was my fifth attendance of the Agile Software Architecture Symposium. This time around I was one of the speakers. It was a promise I made last year to the organizers. The promise was that if 2017 would have an ASAS, I would submit a proposal for a talk and if it would happen as such, I would be one of the speakers at ASAS 2017. Promises are there to keep, so I kept my promise.

Funny part, although at the time I really didn't think it funny, is that just days before my family and I would drive to Croatia for our summer vacation I checked when in November ASAS would be this year. Yup, I was mistaken by a month and the date was instead of somewhere in November, some time early October. The 5th to be exact. And apart from my submission in early April this year, I had nothing prepared at that time.

The topic of my talk would be something about architects being able to survive in an agile world. Something I am talking about almost on a daily basis with clients and especially their architects and agile coaches. But since April I had changed my story continuously... based on the feedback I got during those discussions. Understanding what works and what doesn't is important and crucial when you're coaching. So it was more or less imperative that the contents of the talk would be significantly different when compared to my initial view on the matter in March and the presentation I would give on the 5th of October.
Just to give you a hint, this is what I proposed in April:

How architects can be successfully agile.

Summary: Architects are known for their talent to ensure that projects run out of budget or out of time. The best of architects are successful in ensuring that projects run out of both time and budget. But with the advent of agile practices and the agile manifest, architects are no longer needed, they have no longer a role in continuously postponing a project and ensuring that tons of money are wasted. With waterfall becoming water under the bridge, there is no longer a need for procrastination by the architect. Unfortunately, as evolution goes, architects are genetically inspired to build ivory towers. Doomed to follow the path of the dinosaur. Unless... unless they manage to become agile. This session is about how architects can become agile and thrive again, gaining the respect of... well pretty much everybody and their mother.

When I set off on this journey, I figured I would talk about architects and how they need to change their attitude and way of working. But over the course of the months since April I realized more and more that it's not the architect that needs to change, so I adapted and changed my presentation.
In fact I changed my presentation even 10 minutes before I had to go on stage and give it. Truth be said that in those final minutes the changes weren't significant, yet they were adaptations to feedback I got while attending other presentations that day.

I started of with a Kahoot! to get to know my audience. Instant feedback in terms of laughs meant to me that it was a good way to break the ice... but since I forgot to save the results and in the first place to test the quiz myself, meant that I don't have the right metrics to judge the appropriateness of my slides.

I ended with the opportunity for my audience to ask questions. And that was when the room stayed quiet. Silence. No questions. Not a captivating story that was raising questions. Until a question was asked. By one of the Arc-E-Tect blog followers. There was the answer, and that's when the questions came. And people stayed afterwards, wanting to know more. And then there was the after-party and more people wanted to discuss the presentation.

So in hindsight, the presentation went well. It went well considering the metrics I had set for myself up front. How many people would be in the room, how many would leave during the presentation, how many would join the Kahoot and how many questions would be asked during the presentation. And finally how many would want to talk about the topic after the presentation was done and they had ample opportunity to talk about other things to other people. In all cases it was beyond expectations.
Considering my expectations; the Kahoot! was about getting around 75% of the audience to join, which I think was achieved. I don't have numbers about the audience. Considering people leaving the room during the presentation, I only saw 2 persons leave in a room of about 50 people. Considering questions asked, 3 questions was for me the minimum, based on the fact that I thought I would have time to spare for questions and the story was compelling. 4 questions were asked with 4 different persons asking more questions.

All in all I feel that my presentation at ASAS 2017 was a success, also as an experiment to see if you can consider a presentation to be a product that adds value and can be done in an agile way. 

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.