Download (direct link):
For another example nearer to home, the developers of the Convergent Architecture have taken volumes of generalized methodologies such as the Object-Oriented Process Environment and Notation (OPEN 1997) and the Rational Unified Process (RUP 1998) and filtered out the best set of specific practices for its style of design. It tightly integrates these specific practices and defines exactly how they fit together. The designer no longer has to deal with a sack full of alternatives and options. Instead, more specific roles, procedures, and techniques are applied using tools designed to support these specific features. The definition of specific techniques and procedures is clearly a prerequisite to defining high-productivity tools to support specific techniques.
Specific guidelines reduce ambiguity—a major source of error, risk, and cost. Without specific guidelines, it becomes next to impossible to build things to be compatible. Consider, for example, a scenario where several groups are given the
Chapter 1: IT-Architectural Styel
task of building something as simple as a chair. If instructions are not given as to the height, size, and basic structure of the chair, every group will produce something different. However, since everyone knows from experience what a chair looks like, all the chairs probably will work. Now extrapolate this situation to something as complex as an automobile and as invisible as an IT system. It is clear that every bit of specific information, together with the quality of the tools, will help avoid frustrating problems, particularly when diverse groups build pieces of systems that should work together.
Specificity is not limited to low-level detail. It pays off at every level of abstraction. A high level of clarity and effective communication can begin just by naming the particular IT-architectural style. Compare this, for example, with the specification of cultural cooking preferences used by most of us quite frequently. A whole lot is communicated simply by specifying a French restaurant, in contrast to a Chinese or fast-food restaurant. Once the style of cooking has been named, many details are automatically clear to all parties involved.
Specificity, when done properly, is not synonymous with aggravating constraints. To the contrary, it means highlighting the best path to success in a complex constellation of alternatives. This is not something that happens as a by-product of day-to-day development projects. It is only achievable through a concerted effort by people who have enough experience and an ample portion of constructive foresight—the owner (or owners) of the IT-architectural style.
The Force of Entropy
Even in the field of software design, some laws of physics or, more precisely, laws of thermodynamics apply. To make progress, any engineer must recognize the fundamental laws of physics and act accordingly. Otherwise, bridges fall and software systems fail dramatically—sooner or later. Virtually all software systems today suffer to an unnecessary degree from the force of entropy. The larger the system or set of systems, the worse the problem tends to be. An IT-architectural style is the best place to counter this trend.
Simply put, the force of entropy means that uniform disorder is the only thing that happens automatically and by itself. In other words, if you want to create a completely ad hoc IT architecture, you do not have to lift a finger. It will happen automatically as a result of day-to-day IT activity. Everybody has seen entropy at work. Most of us have worked hard cleaning out the attic or the garage. Who worked on creating the mess? Nobody, the mess happened by itself. The only way to prevent it is to work against it up front, by installing shelves, for example, or otherwise investing energy to better organize the attic or garage. In large software systems, the word architecture is synonymous with work invested at the proper level to organize the system. IT architecture defines the organization of a system. However, most IT architectures today are done within single projects or small groups of projects. This is like letting one person define the order and shelving in one portion of the garage and allowing others to determine it in other parts of the garage without thinking about the organization of the entire garage first. In this case, the entropy simply takes its toll at another level, namely, in between the projects and systems, which is not much better than no architecture at all. This is precisely the reason many companies have started addressing Enterprise Application Integration (EAI). EAI devotes itself to the problems caused by the lack of a holistic, overall architectural strategy. Unfortunately, EAI usually only deals with the symptoms of entropy, not the source. It only patches the problems
Chapter 1: IT-Architectural Styel
caused by entropy. If EAI is not applied in the context of an overall IT-architectural strategy, it itself becomes subject to the force of entropy. This means that, over time, EAI becomes part of the very problem it is attempting to solve. The holistic approach taken by an IT-architectural style handles this problem at the proper level, across any number of projects and systems comprising an overall IT landscape, that is, across the whole attic or garage. It curbs the force of entropy not only within projects, but also across projects. This sounds like a lot of work, and it is, both for the owner of the IT-architectural style and for the chief architect in a large organization. However, the payoffs more than remunerate for the effort.