IT Architecture: The Rules
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
The purpose of an architecture is to provide a template for the development and evolution of the IT environment. (IT architecture means different things to different people, but for our purposes, I mean the rules that govern the interaction of all of the component pieces of an IT system.) An effective architecture will naturally help all IT functions keep aligned with each other, and do so in a non-constraining way. That is, if the architecture is effective, individual service and application providers will be able to go about their business and by referring to the architecture specifications will be able to make their activities work together seamlessly. This is a tall order, to be sure, but a well-designed architecture can be tremendously empowering to IT organizations and have benefits in productivity and group dynamics well outside the obvious benefits of interoperability and cost minimization. The challenge to IT architects is growing greater, however, because as IT complexity grows the need for well-designed architectures grows as well.
I think computer systems architecture is important. To paraphrase 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 to this attitude by watching many IT departments struggle with confused high-maintenance architectures that can't be changed quickly enough to support modern hyper-evolving business models, nor can they even be efficiently maintained.
I regularly visit IT departments of large companies using more than 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 staffs. The truth is that given the complexity and confusion in these systems, I'm surprised they work at all.
Although many IT managers blame the lack of responsiveness of their systems on budget ("If only we had more money...") or technology ("The financial system just won't support that new feature..."), the real truth is that many corporate information systems don't have an underlying architecture that will allow change or responsiveness. Many systems are designed around a series of "point solutions" in response to customer need or complaint. If this process carries on long enough, the architecture looks like the famous Winchester Mystery House in San Jose, California. I call it the "topsy" architecture—it just grew up. This type of reactive approach leads to the inevitable consequences of 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 various forms of customer control. Occasionally these departments are successful because of their corporate cultures or their particular business model. Often, however, their customers are plotting their overthrow or you can detect leakage of applications around the ends of IT control. Customers are creative, you'll often find "pirate" applications and departmentally oriented "computer undergrounds" springing up around the rigidity of the formal processes.
On the other hand, compliant CIOs who pile one application on top of another soon find they have a mess. I suggest that you build a standards-based architecture organized around the requirements of the enterprise model. I'll make these buzzwords clear as I move through the process in the following sections.