It?s impossible to adequately understand business agility without the appropriate level of systems thinking. After all, individual people and pieces of technology don?t exhibit business agility, organizations do. And yet, we cannot treat an organization as a traditional system. In fact, once we take the conceptual leap that organizations as a whole can exhibit business agility, while the people and technology components that make up the organization do not, then we have just cast business agility as an emergent property of the enterprise. The logical conclusion of this point is that enterprises are complex adaptive systems, systems of systems where the people and technology systems within the organization are the individual subsystems that self-organize within the enterprise.
This insight is meaningless, however, if we?re not able to translate it into practical steps for achieving business agility. The first of these steps is to break down the notion of business agility. I include responsiveness, resilience, and innovativeness in my definition of business agility because the organization itself must exhibit these qualities. However, other qualities such as versatility, flexibility, and adaptability would apply more to individual people or technology systems within the organization. This distinction is important, because we need to differentiate between emergent properties and ordinary properties, as how we influence such properties varies dramatically.
Thus properties like flexibility can lead to emergence, but not necessarily, and not predictably. And yet, it’s possible for a vendor or technology team to build flexible software. The Agile Architecture challenge, then, is to help the organization understand how changing the behavior of subsystems (people and technology) affect the behavior of the organization overall in order to achieve the business agility goals of the enterprise. How to accomplish this task is core to the Bloomberg Agile Architecture (BAA) Technique.
When you allow a complex adaptive system to run on its own for a while, it ends up in one of four basic states: stable, cyclical, chaotic, or a distinct pattern. In the case of an enterprise, stable and cyclical are out of the question. Instead, we have two possibilities: chaotic, or the distinct pattern we?re going to call agile. The challenge of BAA, therefore, is to move away from chaotic, which is the usual behavior of an enterprise, to agile.
All we have to work with in order to affect this change are the component systems ? people and technology systems. To affect the behavior of these subsystems, we need to minimize adverse events while emphasizing positive behaviors that lead to the emergent properties we are looking for, as opposed to the usual chaos. In fact, that concept is the thrust of the entire first section of my book, The Agile Architecture Revolution. I’m expanding and deepening that thinking in the BAA Technique — as well as providing practical advice for how to get it all to work in practice.
So far so good, but how much business agility do we need, anyway? And how much is all this architecture work going to cost? Do we need to hammer out all the details ahead of time in order to set a budget? The answer is, in part. It’s important for the architects to understand the agility drivers of the organization, which will necessarily include budgetary considerations. But it’s a fool?s errand to believe it’s possible to pin down agility requirements sufficiently to assign a firm budget. After all, we’re talking about agility here! The whole point is that we’re expecting everything to change.
The better approach is to get a broad, high-level understanding of the business agility drivers, and then iterate. Create a tentative roadmap, maturity model, and enterprise architecture. Identify and complete a pilot project. Analyze the results of the pilot and feed back that analysis in order to adjust the business case, which will also lead to adjustments of the budget. Then iterate again, solving real problems in each iteration while the overall maturity of the approach improves.
Of course, there’s a lot more to say on this subject. I’ll continue to provide the details over time. This approach is also the subject of my course, The Bloomberg Agile Architecture Certification Course, as well as the advisory I do with management and architecture teams. Drop me a line for more information.
