By Harris Kern
The architecture of computer systems is all-important. To misquote the late Vince Lombardi, legendary coach of the Green Bay Packers, “architecture isn’t everything, it’s the only thing.” Or to twist another old saw, “computer applications come and go, but bad architecture is timeless.” I came by this attitude from watching many IT departments struggle with confused high-maintenance architectures that couldn’t be changed quickly enough or managed efficiently enough to support hyperevolving business models.
I regularly visit IT departments of large companies using more that 250 applications, multiple mainframes, hundreds of servers, six (or more) operating systems, several network protocols, and hardware from a half-dozen vendors. The managers usually ask me why their systems cost so much, are so hard to change and upgrade, are often unreliable, and provide poor customer service. They blame their vendors and their staff. The truth is, given the complexity and confusion in these systems, I’m surprised they work at all.
Working without a plan
Many corporate information systems don’t have an underlying architecture that allows change or responsiveness. Many are designed around a series of “point solutions” in response to customer need or complaint.
It reminds me of the Winchester Mystery House in San Jose, CA. For those of you not familiar with the story, in 1884 a wealthy widow named Sarah Winchester began building a house and continued adding to it until the time of her death 38 years later. The house grew to include 47 fireplaces, 40 bedrooms, two basements, and at least five kitchens. She never had a master set of blueprints and her constant changes and additions kept area carpenters and craftsmen occupied for most of their working lives. That’s what you call architecture that just “grows up.” Unfortunately, it’s this kind of reactive approach that many IT organizations take that inevitably leads to inflexibility and confusion.
Computer architecture is not for the compulsive or rigid. We’ve all seen IT departments that think the way to control their architecture is through the rigid use of standards enforced by customer control. Occasionally, departments are successful because of their corporate cultures or their particular business model. But more often either their customers are plotting their overthrow or there’s a leakage of applications beyond the current realm of IT control. Customers are creative, and often “pirated” applications and departmentally oriented “computer undergrounds” spring up around the formal processes.
On the other hand, compliant CIOs who pile one application on top of another soon find they have a mess. To right these wrongs, I suggest you build a standards-based architecture organized around the requirements of the enterprise model.
Focus on the “Big Rules”
Architectural principles should flow from the top to the bottom; that is, from the high-level principles to the fine-grained detail of how the elements of the IT systems interact. Too often, I see IT organizations try to agree on the lower-level specifications and protocol before management has agreed on the “Big Rules.” What are the Big Rules? They’re the basic principles by which people in the organization agree to work out their issues and differences relative to the architecture.
The first rule: Consensus
You must have trust between all those who live within the architectural framework. That means no surprises. You can’t use preferential access to information as a means of control within the IT organization. How often have you walked into a meeting to be surprised by a change of direction or some new piece of information that hasn’t been shared?
All information should be shared with those affected by it, and if a decision has to be made, everyone should have the chance to respond. To do otherwise is to break down the trust level between the parties. Mistrust is a powerful incentive for people to go off and “do their thing” by building shadow systems or otherwise breaking the architecture.
The second rule: Consistency
No one is allowed to break the architecture. You can grant waivers if you have to, but everyone must agree in advance that the architecture cannot be ignored. If this rule is not enforced, you’re going to have chaos. But at the same time, there must always be an appeal mechanism. Architecture is not a club to be used by one IT activity against another, so senior management has to be sensitive to user concerns and respond appropriately.
The third rule: Create a written history
The architecture must be written down, and everyone affected should have input in it. Oral architectures are a tradition in some organizations, but in my experience, unless there’s a simple and clear architecture document, and every supervisor and program developer has a copy, you run the risk of misunderstandings and ill feelings.
The fourth rule: Collective action
No one within the IT organization is allowed to say “not my job.” Everybody must participate and no one can put aside his or her responsibility to the success of the enterprise by passing the buck to someone else. This is a value critical to architecture success. If the staff of an IT organization doesn’t understand the benefits of collective action, the organization won’t be successful in the long term.
IT “cowboys” need to understand the rules by which the organization functions. An IT organization with a strong architecture is better able to accommodate the cowboys and entrepreneurs, because it’s able to clearly articulate the boundary conditions on all activities.
For more information on the Harris Kern Enterprise Computing Institute, visit the company's Web site.