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

Five Styles of Architecture

by Jon Blunt: Info|Ed

© Info|Ed 1995

While many organizations fund information architecture projects they have many different goals for them. Often an architecture team is a small group providing consulting and advice to IS management, but in some organizations the architects are a key development group. Though "Developing an Information Architecture" is regularly cited as one of the top concerns of IS managers, it appears that there are many different conceptions of what that means.

The following are how some architects describe their roles:

"Targets for architecture are to develop process models, develop data models to support those processes, then overlay an architecture on that to simplify and consolidate. The first area to be tackled is relational databases." [The organization believes it is supporting some 29 different configuration of hardware, operating system and database.]

"Recently there has been an increased interest in UNIX and IP. This has led over 18 months to the development of a statement of direction, then checklists, and then, based upon experiences gained, a set of standards." [Standards in this organization are approved by an architecture oversight committee drawn from all the businesses and are then monitored by Internal Audit.]

At a recent meeting of information architects, this feeling of diversity was reinforced as they listened to each other describe their roles.

What they shared was the same underlying motivation, that somehow their companies were failing to manage the integration of different information systems to effectively support key business processes. Some companies were focusing on unacceptably high costs in developing and maintaining systems, and others were looking more at being unable to take advantage of future opportunities. But, each in their own way was looking at significant changes to the IS processes, skills and cultures.

The second unifying feature was that all the architecture groups had the responsibility for publishing templates for solutions. These deliverables ranged from data models to technology white papers, to approved vendor and systems lists.

As a means of providing some structure to understand this diversity, a framework, in the jargon of architecture, the group developed five archetypes of architects: Professor, Creator, Extender, Building Inspector, and City Planner.

Professor

A gatekeeper for new ideas, responsible for identifying trends, simplifying and finding core concepts and technology that can be used across the organization. A professor may not be a practitioner. His or her models and plans are often ideals that are not intended to be realized. Rather, they set standards, in the sense of goals, and modify the discussion of design and information management in the organization.

Effective architects in the professor role actively engage in communication and education to give their ideas and models visibility throughout the I/S community in their organization. Professors may be supported by an architecture board that defines architecture standards for the enterprise (see Building Inspectors).

Creator

The creator role requires the architect to solve novel problems in ways that provide generally usable solutions. Where architects are given this role there is an assumption that adequate solutions are not readily available. The architects work with development teams inside the organization and external consultants on key projects, delivering infrastructure elements or developing methodologies and practices.

In this model the architects are accountable for the integrity and usability of the products. This accountability is usually to the total enterprise while the immediate client for the project may be a single business or function. While the architects are setting the boundaries and goals of the project, project management responsibility may lie elsewhere.

Extender

Unlike the creator, the extender works with known technologies to create effective solutions. The analogy is with an architecture practice that designs homes in a small town. The materials are well defined and building codes exist to ensure they are used safely. There is continual innovation and introduction of new technologies. The partners in the firm make professional assessments for their clients about how well proven these are and the technical advantages compared to more traditional methods. There is continuing professional development to stay on top of new ideas, but it is not expected that the work of this practice will be used in architecture courses.

This model is appropriate where an organization judges there is a body of knowledge and practices that can be applied directly. Requirements are that IA be recognized as a profession and that relevant knowledge can be codified and applied to the needs of the organization.

Groups with the extender role seem to rapidly take on the attributes of an architect/consulting engineer. Their contribution to projects is clearly defined and mostly comprised of technical designs. They may have a continuing role in signing off on specific work products and giving task direction to project teams in those areas that fall within their competencies. Data architects/modellers and security officers are groups where the discipline has evolved to the point that a clear role is often identified and laid down.

Building Inspector

The building inspector role has the same tasks as the extender, but with the emphasis reversed. The extender is involved in developing system designs and structure models with a follow-on oversight of the result. The building inspector has less involvement in the design, but direct accountability for conformance to code.

The code in IA is a set of guidelines and practices that have been accepted by the organization as architecture standards. These may cover all aspects of the system from methodology to approved vendor lists. Usually a key element is the protocols and standards that are needed to ensure system interoperability. These codes may be enforced with varying degrees of rigor through budget control, sign-off requirements, and support policies. The enforcement mechanisms may be devolved to internal audit or the purchasing group, but the information architects are the group that coordinate the process for developing and introducing them.

In a pure building inspector role the design task is handled entirely within the project teams, and whatever is not specifically disallowed is allowed. In practice for key decisions the architects usually have considerable discretion and project teams are advised to consult early with the architects and to listen to their advice.

As was stated above where the architects are expected to be more proactive, the building inspector function is often vetted with an oversight committee. This helps ensure that the standards are accepted by all the group s affected and takes the architects out of the role of colleague and dictator.

City Planner

The last archetype is the city planner. This role concentrates on the disposition of information technology across the organization and its integration. Like the building inspectors city planners do not get directly involved in systems projects. Rather their interest is the organization of those systems: where should particular functionality be located; where can common communication services be exploited; what mechanism should be used for overall management and control of resources?

These questions are intimately connected with the development of an information infrastructure. Just as every resident of a town or city benefits from the phone, electricity, and water systems they share, so each component of the enterprise can gain from shared ownership of an information infrastructure. This concept is propelled by the possibilities of client-server and object technologies and the reality of convergence of networks into shared common services.

This onrushing reinvention of IT places all organizations under strain as they' try to adapt and migrate their existing investment into this new model. The city planners primary concern is to identify what that future may look like and the steps necessary to get there. In the process they set out the ground rules for interoperability and shared services. Typical concerns are: defining the scope of the information infrastructure, identifying what services will be provided centrally; identifying key technology standards for interoperability; enterprise modeling of common business objects or their data attributes.

Commentary

The archetype that most resonates with information architects is the city planner role; every group felt they owned this label, often along with some others. The problems the city planner role addresses match up best with the design choices that will shape the next generation of information systems. However, information in organizations is a completely abstract creation. There is no true analogy with either building architecture or city plans. These deal with concrete objects that have been part of our lives ever since man stopped being nomadic and settled in villages and towns. The role of the architect is to take the best designs and practices, apply them to novel situations, extend them and integrate them with new technology.

In information architecture there are no indigenous systems or natural information structures. Everything is constructed out of the organization of work which itself is a response to market structure, technology, culture and host of other factors. Since the 1950s, the evolution of organizational process has been paced by a race between technology advances and the capability of individuals and organizations to manage change. Computers first revolutionized financial control, then operations, and now service delivery, and with each change a generation of existing systems has been made obsolete. Very quickly these ceased to be state-of-the-art solutions and became bet-the-career problems. In each case redesigning the organization has required change in which the technology issues have only been a small part.

The risk in the city planner role is that it ignores this history and emphasizes managing the technology over managing change. Just defining what has to be is not enough to make it happen. Other processes are also needed to enable the organization to transition to the new model.