Monday, July 16, 2012

In Agile development planning, a security framework loses out

In Agile Estimating and Planning, Mike Cohn explains the different factors that go into prioritizing work on a software development project: financial value, cost, knowledge and risk. He then works through a couple of examples to show how these decisions are made. One of these examples is whether or not to build a security framework for an application – an example that I want to explore in more detail here.

Financial value / return

The first factor to consider when prioritizing work is the financial return that the customer or business will get from a feature: how much money will the customer/business earn or save from this feature over a period of time. For some features the business case is clear. In other cases, you have to do some creative accounting work to invent a business case, or decide based on other subjective business factors – often, how badly somebody important wants something.

Based on financial return, there is no clear business case for having a better/simpler security capability in the application by implementing a security framework. Security, and how it is implemented, is usually hidden from the business – it’s not something that they can see or use or make money from. You could try to argue that by improving the security of an application you could save on direct and indirect future costs of security breaches, and try to build a financial model around this. But unless the company or a close competitor has recently suffered from an expensive and embarrassing security problem, it is difficult to make a convincing case based on some future possibility.

Cost of development

How long will it take, how much will it cost to build it – and does this cost change over time? Is it cheaper to build it in early, or is it better to wait until later when you understand more about the problem and how to solve it properly?

Will it cost more to build security in later? Maybe. But probably not – because unless there’s a management or compliance requirement to make sure that everything is done correctly, there’s a chance that some of the security work won’t get done at all.

If you do decide to do the work early, there’s a greater chance that you will have to come back and change this code again later because of new requirements. So this adds to the future cost of development, rather than saving money and time.

Knowledge – how much do we learn by working on this

Another important factor to the development team is how much they might learn about the problem space or design, or how much they might learn about their ability to deliver the project, by working on something sooner rather than later. This is the point of technical spikes and prototyping – to learn and to reduce uncertainty.

As Mike Cohn points out, implementing a security framework doesn’t add much if anything to the team’s knowledge about the problem space or the design of the product. And it doesn’t answer any important questions for the team about their ability to deliver the project, about the technology platform or their tools and practices. It’s unlikely that whatever the team might learn from implementing a security framework will be material to the project’s success.

Risk

Of course there are risks to not implementing security correctly from the beginning. But the risks that we’re most concerned about when making prioritization decisions like this are schedule risks (how long is it going to take to deliver the key features, can we hit deadlines) and fundamental technical risks (is the architecture sound, will the system perform and stay up under load).

“Is there a risk to the project’s success that can be reduced or eliminated by implementing security earlier rather than later?”
The answer in this case is: probably not.

The project will still succeed – you’ll be able to deliver the project without a security framework. Bad things may happen later when the system is live, assuming that without a framework the team won’t do as good a job securing the app, but that won’t stop the project from getting delivered.

Security isn’t a feature

Using these decision factors (financial value, cost, knowledge and risk), there’s no compelling reason to build a security framework into the application. It doesn’t make the business any money, it doesn’t save time, it doesn’t tell us anything useful about the project or the problem domain, it doesn’t reduce project risk or technical risk in a significant way.

There’s nothing wrong with prioritizing features this way. What’s wrong is treating a security framework as a feature.

The decision on whether to implement a security framework shouldn’t be made based on any of these factors. Security isn’t a feature that can be traded off with other features, or cut because of cost. In the same way that data integrity isn’t a feature. Making sure that the system writes data correctly and consistently to the database or files, that data isn’t lost or partially updated or duplicated if something goes wrong, is a necessary part of writing a system. You don’t decide to do this now or never based on “customer value” or cost or time or whether you will learn something by doing this.

Whatever security is required by the type of system and the business needs to be architected in. It's not a product management decision. It’s part of the development team’s job to do this right. They can’t depend on other people, on the customer or a product manager to decide whether they should implement security sooner or later or not at all.

5 comments:

Jonathan Kohl said...

Good post.

I often use a restaurant as an analogy. The customer does not order food expressly detailing that:
- the ingredients are fresh and safe to eat
- the ingredients were stored correctly
- the utensils, containers, counters, pots, pans, etc are clean
- the restaurant would pass a health inspection
- the food is safe to eat

That's all implied - they expect us to take care of those details because we are professionals. It's the same in software dev - they expect us to be professionals about the underlying infrastructure and systems. So we have to be careful about looking at systems too narrowly.

Of course people want systems to be reasonably safe, secure, follow local laws, etc, but they don't have the expertise to ask us specifically, they depend on us to provide that. Just as a restaurant menu item may be tracked easily with ROI, that belies the changes that a risky food item might bring about with supply, storage, preparation and presentation might bring about. You can't just look at the feature cost/benefit without taking other important factors into account. Insurance, fire prevention and off-site disaster recovery and security systems are costs, and hard to quantify as ROI because they aren't really investments, but you will be glad you have them if and when trouble strikes. WIthout them, incalculable damage to your biz can occur, sometimes effectively wiping out your goodwill and positive mindshare.

Jim Bird said...

@Jonathan, Thank you. I like your restaurant analogy. It's important to separate out the implied/essential requirements, the professional work that is part of building a system, from the functional design and feature planning.

You can make trade off decisions between one feature or another, or between details on usability and time-to-market for example, but you can't trade off designing and writing code that works or doesn't.

Anonymous said...

I absolutely agree with the conclusion that appropriate security must be designed in from the start. However, I disagree completely with many of the statements leading up to it.

Cohn's planning framework is clearly deficient if it excludes business risks. Since it doesn't recognize risks from security breaches, I'd assume it also doesn't account for performance, availability, maintainability, scalability, etc. Quite frankly, he has a poor grasp of what constitutes "customer value".

Additionally, I've found security is often tied up with the domain (for example, in many of the system's I've designed, access depended not only on a role but also assignment to/ownership of a particular entity). By virtue of that, the security model definitely adds to the understanding of the domain.

Lastly, security, like other quality of service requirements, are absolutely features. These features exist as a continuum rather than a binary state. Some applications will require more, some less. It is up to the business owner to decide on the appropriate level. It is up to the development team to provide sufficient information for the customer to make an informed choice.

kumari said...

Thanks for sharing, I will bookmark and be back again






Agile Software Development

Unknown said...

I give also this analogy:

Imagine you have to build a house.

In order to see it'll rock, you will love it, you'll go to specific shops to choose
- the color of the rooms,
- the paintings,
- the objects from designers,
- the kitchen,
- ...

These are "slidewares" parts of the house, useful to the "WOW" effect, to be pleased at the end to live there ...

But ... in order to live well later, you should also have to think on
- foundations
- electric network
- water in and out ...
- way to warm the house
- how to not waste water and heat
- house security
- ...

Instead the project/house will be a WOW project and people won't live in/with it well ...

Site Meter