0 to 60 in 1.6 Gigaseconds

Requirements – Those elusive little things that business folks are supposed to know and IT folks are supposed to find out. As the theory goes, if business people are good at specifying requirements and IT people are good at gathering them, the outcome will be technology that is aligned with the business. From 0 to 60, we’ve been trying to align IT with the business, but to push beyond 60 we may need to let go of the alignment concept a little. After all, alignment is a means to an end, not an end in itself. That is an easy thing to forget since alignment sounds so noble a cause, but remember: crappy systems may be perfectly aligned to crappy business processes yielding far less than perfect business performance.

Paul Brown makes a bold opening statement in his book Succeeding with SOA:

Business processes and information systems have become so tightly intertwined that it is no longer possible to design one without designing the other.  

This simple statement rocks with truth, a truth that has massive implications that neither business folks nor IT folks seem to have fully grasped. One such implication is that trying to align IT with the business by agreeing on requirements won’t in itself yield great results. Requirements cannot be the definitive point of handoff from the business to IT – they can’t because the design of business processes and the customer experiences they provide must be orchestrated with the design of services and technological components of services. So there is something in the middle that takes place, something that considers all aspects of business process and customer experience with full appreciation of the problems and opportunities, something that comprehends the richness and risk of available technical capabilities, and something capable of conceiving an overall design. Who does this type of conceptual design? That is a critical question faced by most companies today (even though most do not yet recognize it as a root cause of their problems).

You might be thinking, “No problem, we have Greg the Architect”. Sorry, your IT guru might be extremely bright, but he is more of an engineer than an architect. His burden is trying to keep up with the endless quantity of technology theory and products which advance at a rate beyond mortal comprehension. All the three-letter-acronyms build a wall around him that is so thick and so high that any real world conversation that filters through is a rare event that he often finds confusing. Business processes and the organizational impact on business people are not in his line of sight.

So you might be thinking, “Okay then, it’s a good thing we have Betty the Black-Belt Business Architect”.  I’m sure she can model processes since she earned the coveted certification, but is she given room to understand and alter a business process in a full end-to-end context?  More commonly, she is given a piece of the process that happens to coincide with one existing organization, so from the start her best work could only bring piecemeal improvement and at worse, sub-optimize the whole business process without realizing it. Betty also takes pride in being a business person and is quick to point out that IT is not her cup of tea. In fact, Betty had a bad experience in an IT group years ago so she’s pretty happy to be out of that domain of accountability. She can tell you where defects are being introduced into a process and the cost of (bad) quality. But she’s more of a process modeler than an architect. Like Greg, she is not positioned to provide an effective conceptual design.

She probably is not the right person either. Neither is Greg. I can say this with reasonable certainty not knowing either person because the personal traits of an effective conceptual architect are extremely rare. Some people have a divergent style of thinking. They are hard to pin down. They seem to go off on tangents all the time. There is never a shortage of ideas with them. Other people have a convergent style of thinking. They are always trying to focus the discussion and narrow the options. They are not excited by something new until they see how they can apply it.  An architect has the uncanny ability to be both divergent and convergent at the same time. They are capable of exploring possibilities at the same time they eliminate unlikely alternatives. This trait alone probably filters out over 99% of the earth’s population. Beyond that, architects have a spatial or visual instinct that is second-nature to them. They have unusual mental tenacity – they review options iteratively, changing variables and predicting outcomes. They do this using tools, using others, or in their heads. They do this at work or when they mow the lawn or take a shower. Finally, architects live by the principle of intellectual integrity. They pursue the best conceptual design, not their conceptual design. This principle compels them to seek out knowledge when needed from other sources and to quickly backtrack when facing dead-ends. Combined, all these traits are rarely found in an individual. But they are around. If you have one in your company, you are lucky. If you have several of them, you win the lottery! But when you find some, you can surround them with executive support, tools, techniques, and disciples to develop working conceptual designs. You’ll truly have a Business Architect, not just someone with a cool job title.

I’m reminded of a sporting journalist who interviewed a college basketball coach about how recruiting was going. “Well”, the coach said, “you know some mothers raise big kids, some mothers raise fast kids, and some mothers raise smart kinds. And every now and then, some mothers raise a kid who is a combination of all three. Those are the mothers we want!”