This article builds on a preceding article that you might want to read before you read this one. That article's name is Can agile software development support Business Agility? .

Most seasoned software developers/designers agree that software should align to the business. But what does it mean? What's the purpose of doing it? And what happens if you don't align your software to the business?

The idea behind it is simple. It's to map software entities to business entities. This requires some analysis, though. First of all, you must decide what kind of business entities to choose for software entity mapping. To be able to do that, you must first know what the relevant business entities are.

The purpose is to support Business Agility. This includes making the software entities more sustainable. Making it easier, faster, and less risky to change them to match future business requirements.

With software not well aligned to the business, this is hard to achieve. The system will look like a spider's net already from the beginning. For each change, it will become worse. Each item you change is liable to harm an innocent consumer. By time, the system will become a liability rather than a resource for the business.

So, to what kinds of business entities can software align? And which kind is the best choice?

You can describe the structure of a business in at least three different ways:

• There's the organizational perspective. It describes who performs a specific task and sometimes where they do it. It's not a stable perspective, because businesses tend often to reorganize themselves. When this happens, tasks may move from one business unit to another. Over time, this will destroy the initial software-to-business alignment, piece by piece. The complexity of the software will increase. Future changes, meant to adapt the software to changed business requirements, will come harder. Doing them will be more difficult, take more time, be more expensive, and carry more risk.
• There's the process perspective. It describes how to perform a specific task. It's more stable than the organizational perspective. Even if the who or where change, the how can remain the same. Sometimes, though, it's the how that changes. Toyota, for example, allegedly revisits each of its major processes monthly fo look for opportunities for improvement. When a process changes, many things can happen. Tasks may be performed in a different order. What used to be sequential may become parallel. Tasks may move from one process to another. When things like that happen, the alignment suffers from the same consequences as when re-organizing as described in the preceding paragraph.
• And there's the capability perspective. It describes what the task is. No matter who's doing it, or how it's done, the what can remain the same. That's why this perspective is far more stable than the others. That's why aligning software to it is not only easier, safer, and longer-lasting. It will also take less time to change it in order to meet new or changed business requirements.

There's a final interesting point to make here. The relevant business capabilities are so accessible to you. Most of them will already be in your product's backlog when you need them.

Do you want to know more about this? If so, don't miss the How product backlog items relate to business capabilities article soon coming up.