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

Architecture To Solutions

Jon Blunt

© Info|Ed 1995

Abstract
Many Information Services (I/S) organizations have launched an Information Architecture projects with the goals of reducing the long-term cost of information technology (IT) and improving the effectiveness of its use. Unfortunately the `conversion rate', taking the architecture and implementing systems based upon it, is not very high. Using examples from successful information architectures, this paper identifies the ways to make sure that information architecture programs succeed.

Almost every major company and many small ones have launched Total Quality Management (TQM) programs in the last few years. High hopes are invested in them, great things are said about them, yet the research shows that most of them fizzle out with no lasting results. In a quieter way the same thing is happening with Information Architecture. Many Information Services (I/S) organizations have launched an Information Architecture project in the last five years with the goals of reducing the long-term cost of information technology (IT) and improving the effectiveness of its use. Unfortunately the `conversion rate', taking the architecture and implementing systems based upon it, is not very high. If you are engaged in or about to undertake an Information Architecture program what can you do to make sure it succeeds?

First, is implementation important? As one speaker at a seminar on information architecture said “Well, it really doesn't matter, Information Architecture is only planning. If you get a plan wrong you can always do another one”. If that is what you believe, be very careful how you sell the IA exercise; an organization can only take so many of these planning exercises. What is more, starting from the view that architecture is a plan that can be divorced from implementation only increases the chance it will be.

How do you manage the risk that the architecture is not appropriate for the organization? Set up processes which ensure a rapid testing and validation of design. Accept the inevitability of mistakes. Discard them and focus on the best ideas. It is the absence of this tight feedback process and reality testing that allows some architecture efforts to continue for several years without producing any measurable results.

Both the design work and the implementation have to be done well if Information Architecture is going deliver the benefits promised.

Critical Success Factors in Design

The following are the key points in creating a well structured architecture program that produces a viable, valuable, and realizable design.

Set the mission correctly. Most projects go off the rails at the beginning because the organization is not clear about the goals it is setting. In every worthwhile architecture project there is a discovery phase where the team is exploring new ideas and concepts. This is important, but boundaries have to be set on the duration, scope and target implementation of the work if this research effort is not going to dominate the project -- is the output of the project a plan for implementation starting in six months, one year, or three years from now?

The architects must be committed to proving the feasibility of carrying out their ideas. Very often an architecture team will generate a plan that is then thrown over the wall to the applications developers. When problems arise no one has ownership for solving them. At the least the architects should be held to developing a proof of concept. Often a prototype does not get at all the organizational issues that will come up in full scale implementation; the architect should have a continuing role. After designing the architecture the architect's role changes to that of trainer, coach and developer of those central elements that are not otherwise easily obtainable. The architects have become the midwives of their creation: not doing most of the work, but making it easy for those who undertake the labor.

This continuing role is most important in organizations that have largely decentralized I/S or have aligned the I/S structure to functional organizations. The key components that need centralized coordination are those that have high reusability. These fall into three categories:

Focusing on relevant issues. Before any architecture program is started there should be a thorough assessment of the needs of the organization. Many architectures define basic systems infrastructures, which are important to I/S but not directly to the business; the real pay off is in the information and data management processes that get into the hands of the business. These have to be the primary focus; the infrastructure is only the enabler.

Having a good understanding of what should be in the architecture. There is a balance to be struck between a list of concepts and a systems plan. Take too high a level and no one understands what it means in practice; get too detailed and it is rapidly overtaken by events. A robust, useful architecture specifies a framework that defines components that have two characteristics:

Today's legacy systems are ossified dinosaurs that are often organizational liabilities, not assets. The systems that spring from the architecture will eventually be the new legacy. The art of architecture is to identify a structure for these new systems that maximizes their value creation over time. Like most good design this requires defining a few common components that can be put together in many ways. It will be modular and layered, and it will include the specification of key standards that must be adopted universally if the architecture is to succeed. Also, if the architecture is to continue to have value, it must be based upon principles that articulate the policy choices of the organization.

Implementation Factors

These first points are the basis of many projects that result in focused relevant architectures. However, on their own they are not enough to carry the project through. As you are going through a successful prototype you should be asking another series of questions in preparation for rolling out the architecture.

Are the principles really stable? Look up principles in a dictionary of quotations and see the skepticism great thinkers hold for principle-based policy. “It is often easier to fight for principles than to live up to them.” Adlai Stevenson Or, “Amid the pressure of great events, a general principle gives no help.” Hegle In the battle between principles and interest we are seen to act more in our own interest than in line with our stated principles.

In my experience, companies often base their architecture designs upon a set of principles the consequence of which they have not thought through. The principles may represent a statement of how the organization ought to behave but conflict with how it actually behaves. Sometimes I find I/S groups identifying as principles courses of action that they have been unable to gain agreement for by other means. “I/S will approve all purchases of network-attached equipment,” is one such pseudo-principle. AT&T lost that battle many years ago and so probably will the I/S group.

Instead of relying upon adherence to principle to preserve the integrity of the architecture there has to be a process that aligns principles and interest. This means the reward system is part of the architecture as is the organizational culture.

Base decisions upon enhancing customer value. Who does this architecture serve? Who are the customers of this architecture? These questions should be answered right at the start of the project. Then the test of the architecture is that it be valued by those customers in enabling them to be successful. An architecture that is focused on the needs of application developers in I/S may not meet the needs of para-professionals working in the business units. Yet, increasingly, it is these groups who have the greatest impact on how the organization will benefit from its IT investment.

The architecture is not an adequate guide to developers. This is a continuing problem. If the architecture is successful in getting the buy-in from management and the users it is often too vague or ill defined to help developers build systems. For example, much energy may go into which communications standards have to be supported by distributed applications (macro architecture), but say nothing about the internal structure (micro architecture) of those same applications.

To release the potential value of information technology an organization must have both macro and micro level architectures. With the current technology it is too easy for the designer of a module or application to make inappropriate design choices that detract from the value of their output. This becomes more important as developers are asked to rely on code developed by different teams and over extended periods. If reuse of function on a large scale is a goal, it implies the adoption of rigorous design and quality processes.

Information Architecture and TQM

Indeed, there is more than a symbolic parallel between the fates of information architecture and of TQM programs in organizations. Both Information Architecture and TQM require a single-minded commitment if they are to succeed. Obtaining results so radically different from today's is dependent upon buying into the philosophies and practices underlying the specific technologies. The organizations that fail at TQM tend to be those that approach it light-heartedly, trying to do a little bit of TQM without making a commitment to follow through with all the consequent changes.

To succeed in taming IT you need both an information architecture and quality IT processes. Architecture is not a replacement for SEI process benchmarks or 6-sigma programs; it is their natural partner. The linkage between architecture and quality is the handbook of best practices, the builders guide. This specifies the internal standards and procedures the developers can use to meet the design goals of the architecture. The content of this manual represents the best wisdom of the organization on matching its expertise and resources to the available technology. As such it has to evolve over time.

In Juran's model of quality management [1] defining the architecture represents `breakthrough', the adoption of radically different production and process technologies, while the handbook codifies and communicates the results of learning through continuous improvement.

Information architecture is often positioned as a tool for getting the business managers' priorities and needs linked to the I/S plan. Organizations who turn to information architecture to find one-off, or broad-brush management solutions to their IT problems will only find themselves held back by any underlying weaknesses in their implementation processes. As Mies van der Rohe said about buildings, “God is in the details.”

Footnotes

[1] J.M. Juran, Managerial Breakthrough, McGraw-Hill 1964