[ About Info|Ed ] [ TiAC ] [ What's new at Info|Ed and TiAC ] [ TiAC White Paper Repository ] [ Information Architecure Resources ] [ White Paper Request ]

TOP-DOWN OR BOTTOM-UP?

Jon Blunt

© Jon Blunt 1994,1995

Background

This paper was inspired by a discussion at TiAC in May 1994 of the merits of top-down and bottom-up approaches to architecture. This working paper summarizes the discussion and proposes some approaches. It does not attempt to be definitive, and comments are invited.

Architecture as Integrator

Most companies seem to have embraced architecture as a means of managing complexity and chaos. Complexity means that most companies have a history of failed planning processes based upon sequential decision making and point solutions. This leads to chaos, as increasing effort is expended on integrating the incompatible.

Architecture embraces a philosophy of planning and order which emphasizes making decisions within an agreed framework. Depending upon the architecture methodology adopted, the framework is usually based upon either principles or standards. Either way, at some point there is a transition from theory to action when the company begins to follow the rules laid down in the architecture. Now the framework is not a fuzzy document, but a set of discrete decisions about products, application design, operations procedures and the rest.

Open standards are famous for being open enough to have a truck driven through them. As rules of everyday life, the standards that are developed from the architecture have to be specific. The tolerance for ambiguity is much lower when building a specific infrastructure than when describing approaches to building infrastructures in general.

Architecture as practiced in an organization, therefore, goes through a process of refinement and extension where general rules are interpreted as needed to resolve ambiguity. So even if the initial view of architecture is that it is about general rules of practice and conduct, the principle-based approach, over time it acquires many of the characteristics of a standards and procedures rule book.

Architecture as Straight Jacket

This is the alternative view best articulated by Tom Davenport.1 It highlights the difficulty of successful single option solutions working in practice. Technology changes rapidly, and the whole profession is swiftly moving up learning curves of both the use and development of information systems. In this environment architecture is inevitably on a collision course with business decisions. Indeed, information architecture is itself fatally flawed because it limits experimentation and, therefore, learning. Chaos in this model is the price, or indeed the mark, of success. Because the philosophy of architecture is based upon a false premise of order and tidiness, it misleads and diverts energy into fighting battles over policies that are only holding the organization back.

Davenport suggests that this sterile process appeals to IS professionals because it gives them the comfort of the appearance of control. The alternative philosophy that he calls ecology would have more appeal to anthropologists and others with a background in the social sciences.

Architecture Redux

The preceding is the extreme case against architecture, but it cannot be dismissed out of hand. Most companies report disappointment with their attempts at IA, and architects acknowledge the truth of some of the comments. Yet, it is not clear that architecture has nothing to offer. Some companies report considerable success with architecture, and it can be argued that every organization does have an architecture, even if it is not planned. Also, the stakes are very high. CIOs are paid to create systems for managing information for the benefit of the organization. At the most general, an architecture is a statement that the company has a philosophy, a goal, and, it is hoped, a plan for getting there. To the extent that senior management demand to know what the CIO is doing to get the enterprise's systems into shape, architecture is a mechanism for communicating the desires and directions of senior management. Our research at Info|Ed shows that the perception of the peers of most information architects is that IA is top-down and theoretical.2. This is not healthy, and, if an organization is making architecture a priority, it must be addressed.

Diagnosis

How to address this issue depends upon the cause. We have identified three reasons for skepticism in organizations about architecture:

1. There is no tie-in to day-to-day decision making

Davenport specifically criticizes the IBM BSP model and its derivatives for this reason. These methodologies emphasize collecting data and developing architectural solutions in areas such as data networks and applications. I choose the word solution over model because there is a direct linkage between design and the creation of systems.

The Zachman Architecture Model describes a refinement process by which a high level design is successively refined and brought down to a level that is useful for systems designers and implementors. The art in these approaches is to only define at the higher level what is essential. But the rational-engineer philosophy dominates the whole process. Data is collected to identify the best fit model, or best solution. There is often a focus on defining the enterprise in all its uniqueness, and there is pressure to start developing. As a result, by the time the exercise is complete there are numerous hostages of fortune. For example, the architecture defines a corporate data model, but a package that is strategic to some business unit does not comply to this model.

As traditionally used, these methodologies have worked better for organizations that have built rather than bought applications, have a centralized IT function, and are in a single line of business or operate within a stable business environment. The prime reaction to a failure in these methods is to perceive them as top-down.

3. Creeping rigidity

The process of IA success that was described initially, evolution of concept to system, contains the seeds of its own destruction. However malleable the original frameworks, progress implies investment and commitment. As principles are interpreted to standards and embedded in systems, the cost of changing those standards rises. Over time the architecture develops its own rationale that has to be supported in the light of conflicting evidence. The architecture is therefore a paradigm for an organization and, like scientific paradigms, tends to be defended by the establishment until radical change is adopted.

Approaches to Minimizing Adverse Perceptions

The thrust of the preceding discussion is that negative responses to IA are often built into the process. They are not the result of mistakes but, rather, of the architecture doing what it is meant to do, limit choice. The goal should be to use the scale of these reactions as a measure of the effectiveness of communication of and about architecture.

Some ideas for managing these reactions are:

Solve problems incrementally and collaboratively.

Architects often tackle all phases of problem solution from diagnosis to identification of remedies. Instead, reserve the responsibility for diagnosis and development of broad directions. Then, work on developing solutions for specific problems collaboratively with key stakeholders. These solutions should be revisited and reassessed over time. The architect has a continuing role in this process for understanding the actual implementation, providing technical knowledge, and solving specific problems or conflicts.

This helps to move the development forward, but the larger purpose is for the architects to be at the appropriate distance from the work to generalize from specific examples to general solutions. If the architects are directly involved in the work, they can easily become too immersed in details to recognize opportunities to build on solutions. Yet if the architects are completely distanced, they get no feedback on the practical issues that the implementers face.

Focus on Process, not Product

One method of avoiding these issues is to emphasize the process, not the specific deliverables. Legitimately, an architecture can be seen not as a single goal but as a continuous search for best practices. [This of course is a hopelessly idealistic position; very few individuals have the luxury of being measured on process rather than results.]

At each iteration a small number of artifacts - principles, models, templates - are true standards for developers and others. In addition, there are a larger number of "speculations", ideas to be tested. The prime role of the architect in this model is to ensure that there is maximum organizational learning and that good practices are shared and built upon.

Minimum Critical Specifications

A third guiding principle could be that of minimum critical specifications-only centralize and standardize that which is essential to achieve the goals. Adopting this approach assumes that IS in a large organization is best represented as a federal system with decision making devolved to the lowest level appropriate. In government a federal system is expected to allow local flexibility and innovation within a framework of laws and regulation that promotes interstate trade and commerce. The critics of federalism focus on cumbersome decision making and adoption of the lowest common denominator standards. But it is probably a better model for IS than the Ancien Régime.

Notes

1. Davenport, Thomas H., "Saving IT's Soul: Human-Centered Information Management." Harvard Business Review, March-April 1994, pp. 119-131.