Architecture Governance: Management Structure for Creating Architecture

Governance is broadly defined as the processes and systems by which an enterprise operates. How are decisions made? What are the roles and responsibilities? How does an enterprise create the logical relationship between process and IT, the architecture of the enterprise?

ARCHITECTURE GOVERNANCE
The first stage of a development project is the creation of a fundamental structure, a to-be architecture. Completion of this stage marks a major milestone. At that time, a project’s purpose, cost, performance, schedule, and risk have been approximately defined. Prior to the milestone, these issues are malleable; there is no logical optimum, but choices. So who chooses?

Classical architecture teaches that three roles are important during development projects: The executive (often the architect) is responsible for overall performance, the technician is responsible for design and operations, and the client is responsible for value choices.

These three roles have equal importance. Distortion of these roles leads to conflicts of interest and organizational dysfunctions.

EXAMPLE: NASA
For decades, the Space Shuttle was viewed as operational as opposed to a development program. Project managers (executives) dominated, engineers (technicians) were pushed aside, and clients were weak, but they launched on schedule. The result was the Challenger and Columbia accidents. Since Columbia, NASA strengthened the engineer role by instituting a “Technical Authority.” The new NASA administrator has the personal skill to function as a competent client– e.g., to resolve disputes between the project mangers and the engineers–to decide how much risk is acceptable. Role balance has been restored at NASA.

THE CLIENT’S ROLE
The client’s responsibility is value judgments. Only the client can decide purpose, scope, and boundaries. The client judges the balance between cost, performance, schedule, and risk. Since honest disputes between the project manager and the engineer can and should occur, it is the client’s responsibility to resolve these disputes.

Now that the client’s responsibilities have been defined, it is important to talk about the client’s role. The client’s role changes as the project evolves. Early stages can be characterized as a spiral process with the client playing an active fundamental role. The client, interacting with the architect and engineer, expresses preferences, makes choices, and clarifies strategic vision. During early strategic stages, the problem is under-constrained; there is more than one feasible solution. Early stage decisions are often judgments, strategic value choices, and not logical deductions. Therefore, it is a conflict of interest for the executive or technician to make these choices.

Client choice (of a concept or architecture) marks a major milestone. The project transitions from the architectural stage to an operations stage. Purpose is now clear; cost, performance, schedule, and risk have been defined to first order. Technicians have an unambiguous specification and can proceed to optimize the product. The client’s role shifts to that of monitoring–dealing with disputes and value choices associated with the inevitable unexpected disruptions. The link between client and technician is weaker than it was during early strategic stages, and the governance model can now be expressed (with caution) as a hierarchy.

EXAMPLE: DEPARTMENT OF DEFENSE ACQUISITION
DoDI 5000.2 starts with milestone A, the concept (architecture). The government is the executive; the contractor, the technician. The client is multidimensional: the Acquisition Executive, DAB, MDA, the Service, OSD . . . One weakness with this policy is that the client is remote and formal, uninvolved in daily operations. When a project stumbles, the dispute is resolved through alternative dispute resolution or legal means, often too late to recover the project. Another weakness is that the project manager (PM) and engineer can collude to hijack the client role. While the governance model is the operations hierarchy, a more involved client would be useful on occasion.

SURROGATE CLIENT MODELS
As suggested above, the ultimate client is uninvolved (e.g., corporate shareholders, Congress). A common solution is to construct a surrogate to satisfy the client role. The best approach is context specific. For example:

• NASA’s mission (purpose) reflects the aspirations of the American people. The president, with the advice and consent of Congress, decides that a mission will be to put a man on Mars. The president appoints an administrator, who serves as the “involved” client. The president decides purpose; the administrator clarifies vision and judges the relative balance of cost, performance, schedule, and risk.
• Commercial companies creating new products often need surrogate clients to provide feedback. For commercial products, the marketing department may construct focus groups.
• Contractors, preparing a proposal, usually construct a “Red Team” to play the role of client in evaluating proposal drafts. Red Team comments feed back directly into proposed architecture.
• In the corporate arena, a board of directors serves as the client representing shareholder interests. The board picks the CEO, approves corporate strategy, and monitors progress.
• Local politicians sensing the needs of their constituents will initiate civil works projects. Planning is led by an agency with collaboration of other agencies. Public meetings provide local feedback. A civil commission is often constructed to make the final choice.

A common theme is a context-appropriate governance board that serves as the involved client, interacting with the executive and technician to make choices.

EXAMPLE: ENTERPRISE ARCHITECTURE

EA is defined here as the architecture of the enterprise, not information technology architecture aligned to business goals. The client consists of senior management and key stakeholders in the form of a governance board. The client decides on the mission (purpose) that in turn defines the scope and boundaries of the enterprise.

The technician has two main hats: the business architect and the IT architect. The business architect creates operations models. There is more than one alternative, and each is defined in enough detail to distinguish between structures. The IT architect creates high-level logical structure and data models. Again, there is more than one alternative, and each is defined in enough detail to distinguish between structures.

The executive is the enterprise architect. She or he is confronted with several combinations of feasible business architectures and technology architectures. Using mission, vision, constraints, and judgment, the enterprise architect reduces the set to a limited number of fundamentally unique alternatives. It takes a strong executive to keep focused on simple, clear structure and avoid introducing too much detail too soon.

The client chooses the to-be architecture. A clear, stable vision enables detailed objectives and goals and provides a solid basis for capital planning and transition plans.

Alex Pavlak (PhD, ME, PE) is an engineer and independent consultant on creating architecture and under-constrained problem solving. He has led several successful projects that involved creating major systems architecture. He can be reached at  thales@comcast.net . A more detailed bio and significant publications can be found online at http://mywebpages.comcast.net/thales/