The Dangers of “Checklist” Architecture
Since we wrote our ZapFlash Is Your SOA Hammer Looking for a Nail? last July, we’ve continued to encounter a steady stream of architects working on SOA initiatives that have unclear or misaligned business drivers. In addition to the three patterns we discussed in our earlier ZapFlash, namely the SOA mandate, the enterprise morass, and the capability conundrum, one more has come to light: checklist architecture. Checklist architecture is a more subtle problem than the three patterns above, because it appears that there are clear business requirements that the architecture will address. However, checklist architecture is just another way to achieve dramatic levels of business/IT misalignment, and furthermore, this mistake can be a spectacular waste of money.
What is Checklist Architecture?
Checklist architecture occurs when there are a fixed set of goals for the architectural initiative, either final goals or interim milestones, where the goals only indirectly correlate to the business drivers for the initiative. Problems arise when the architecture team drives toward the goals without heeding the underlying business problems, expecially as those business problems change over time.
Checklist architectures are endemic to government architecture initiatives. For example, the Department of Defense Architecture Framework (DoDAF) was developed primarily in response to the Clinger-Cohen Act, which mandated Enterprise Architecture at the federal level. DoDAF compliance, in turn, means creating a number of “views,” or architectural artifacts of various sorts. And while these views should help drive a successful architecture implementation that meets the business needs of the organization, far too often the views are the end result, rather than tools for achieving true business value.
We also ran into checklist architecture in the private sector at a client who had instituted a number of “Performance Objectives,” or POs. In this company, every team meets with their manager at the beginning of the year and hammers out POs for the year to come. These POs are intended to drive activity on the team in alignment with business needs, and then form a basis for rewarding the team members for achieving their goals for the year.
What happened, however, is by the end of the year, the team was driving toward the POs without any regard for whether they would end up addressing the business challenges. When ZapThink pointed out that the POs wouldn’t solve the business problems, the response was that the business problems weren’t important, the POs were. After all, they had to achieve the POs by the Holiday break in order to get their bonuses!
Architecture Exacerbates the Problem
The checklist architecture problem isn’t unique to architecture initiatives. After all, it’s possible for this checklist problem to torpedo any sort of effort that experiences a shift in business requirements. When the initiative involves architecture, however, the checklist problem explodes, because architecture is so hard to pin down. In fact, pinning down an architecture effort, that is, distilling broad requirements for architecture into specific action items, is a reasonable part of any architecture planning effort. But the more complex the architecture is, the less it lends itself to specific action items — or more precisely, action items that remain stable over time.
In the case of SOA where a core business driver is business agility, a checklist architecture is virtually guaranteed to be counterproductive. One way of looking at this limitation is the realization that the checklist approach is essentially a traditional systems approach. Because business agility is an emergent property of SOA, it requires a complex systems approach that encourages emergent properties rather than attempting to snuff them out. However, checklist architectures fix business requirements, which will discourage or fully eliminate emergent properties like business agility.
Another way of looking at the checklist architecture problem is from the perspective of the Agile Manifesto, the principles behind the “Agile-with-a-capital-A” software development methodologies. The fourth principle of the Manifesto states that responding to change is favored over following a plan. You can think of the architecture checklist as the framework for a plan — and if there is change in the business context for an initiative, then you should adjust the plan accordingly. Fixing a checklist of goals, therefore, is inherently non-Agile, so it’s no wonder then that such an approach will also impede business agility.
Creating an Agile Checklist
Even though the traditional approach to a checklist architecture is inherently flawed, we don’t mean to say that checklists themselves are bad. After all, it’s important to have measurable milestones and goals that enable the organization to ensure the initiative is on track to meet business needs, and that also provide a means for measuring the effectiveness of individuals and teams that are participating in the overall effort. The secret to creating a checklist that doesn’t lead to the dreaded checklist architecture problem is to approach the problem from an Agile perspective.
Also on the list of Agile principles in the Agile Manifesto is an increased focus on individuals and interactions as well as customer collaboration. These characteristics are missing from checklist architecture, since the technology team works toward the checklist instead of working toward solving the core business problems that originally drove the initiative. It is essential, therefore, for the architecture team to establish interaction with the business stakeholders as a core part of their checklist — not in the sense that “interacting with stakeholders” is itself a checklist item, but rather that there’s a policy for establishing interactions with stakeholders that drive the checklist and how it changes over time, as part of the governance framework.
Architects, therefore, must always be thinking in terms of change. Whenever there’s a requirement, artifact, or policy, it’s not sufficient for the architect to ask what that requirement or artifact or policy is. The architect must also ask how it will change over time. Once architects focus more on how things change than on what they are, the next set of questions should focus on what sorts of changes are desirable and what sorts are undesirable, and how to achieve the desirable changes and avoid the undesirable ones. If this change-focused approach to architecture sounds a bit like herding cats, well, that’s the way architecture is supposed to be!
The ZapThink Take
Establishing an approach to changing the milestone checklist as a matter of policy is a fundamental complex systems engineering technique. One way of thinking of complex systems engineering is as an analogue to the natural selection process that gives us the evolution of living creatures. Our governance framework must favor the behavior we desire and discourage the behavior we seek to avoid. Over time, we’ll end up adapting to changes in the environment. In other words, the architect focuses on change itself more so than the specific things that are changing.
This shift from traditional to complex systems approaches requires a fundamental change in the way we think about how IT meets business needs. We move away from the “business requires X so we build X” mentality, and move toward a “business desires the ability for requirement X to change so we deliver a system that can deliver X as well as whatever changes to X the business requires” way of thinking. Checklist architectures are the former, as they fix requirements in a manner that doesn’t end up leading to an implementation that meets the underlying business requirements. Establishing a governance framework that allows for changes in the checklist by favoring changes that keep the checklist in alignment with changing business needs is the true best practice approach for establishing goals and milestones for any agile architecture.