Steve Ornburn, Principal Consulting Architect
GBC-Group, Inc.
March 26, 2002
Many firms are creating an internal architecture practice to help translate IT strategy into action. As a first step, many companies recruit a practice leader who will organize and chair an architecture working group—a virtual team of application architects from across the firm. As a crucial part of his job, the practice leader will guide the working group in the use of best practices in developing architectural standards, recommending changes to existing architectures, and developing architectures for new projects.
The architecture practice leader will also develop a core team of full-time enterprise architects. Under his direction, sub-teams of enterprise and application architects will be responsible for consolidating architecture requirements. They will conduct detailed research and trade-off analyses, design shared services, and develop proof-of-concept prototypes. The architecture working group will interact with these sub-teams by reviewing recommendations, approving reference architectures, and enacting standards.
Governance for the architecture-working group is generally provided by an architecture steering committee composed of key stakeholders who are responsible for approving the working group’s charter, objectives, and strategy. The steering committee periodically reviews the working group’s progress, guiding the working group to (1) secure resources, (2) maintain alignment between organizational and architectural objectives, and (3) address constraints and challenges outside the working group’s sphere of influence.
With the emergence of Enterprise IT Architecture as a distinct discipline, IT is joining the ranks of a number of other engineering fields in using specialists to translate stakeholder and user needs into implemental designs. Generally, an architect works with stakeholders and users to develop requirements addressing expressed needs. The architect then works with developers to identify alternative design approaches to meeting those needs. Inevitably, any proposed solution will involve trade-offs—no one solution will meet all stakeholder’s needs. Thus, an architect often figures centrally in managing these trade-offs. Typically, the architect identifies the strengths and weaknesses of proposed designs and works with developers, users, and other stakeholders to find trade-offs that appropriately balance competing requirements. In many organizations, architects work with implementation teams, advising in matters of design and scope change, particularly those impacting key requirements. The architect may also be involved in verification and validation, to identify and address gaps where the as-built solution is at risk of failing to meet specifications.
Enterprise IT solutions must address the needs of many diverse communities. As a consequence, one of an architect’s chief functions is to ensure that important technical requirements—especially those not immediately evident to business-oriented stakeholders—are properly weighted in the design process. An IT solution must not only fulfill an immediate business need, it should also be flexible, readily adapted to changing business requirements. Furthermore, the solution should satisfy the requirements of developers, operations personnel, and maintenance teams. Important but often overlooked requirements address reliability, availability, serviceability, fault tolerance, and scalability. Also important are performance-related requirements such as capacity, response time, and turn-around time. Yet other important requirements are maintainability, extensibility, and interoperability.
The Federal Enterprise Architecture Initiative has constructed a model (reproduced below) illustrating the relationships among the key elements of a typical enterprise architecture initiative.
The main elements in this model are the as-is architecture, outlining the current state of information systems, and the targeted to-be architecture, showing the desired future state. The standards and transitional processes help shape the migration from the current to the target architecture. Designs for individual IT projects must, in general, conform to the standards. Transitional processes set intermediate milestones for the migration, maintain the master plan showing how individual projects contribute to the transition, and coordinate and monitor progress towards the target architecture.
The model also illustrates how the overall architecture initiative must be aligned with business conditions, emerging technologies, best practices for IT, and most importantly, with strategies for the business and its technical platforms.
In any complex enterprise IT environment, it is important that the architecture be segmented. To avoid analysis paralysis, enterprise architects should not make their first efforts comprehensive—if architects become too deeply mired in the morass of as-is architecture, for example, they may neglect the real work of optimizing architectural decisions to deliver business value. In bounding and managing the enterprise architect’s work, it is often useful to improve the architecture in segments on a prioritized basis, where each segment is a business area or group of related services.
The federal enterprise architecture model also highlights the importance of viewing the architecture from several perspectives. In the model shown, the four layers—business architecture, data architecture, application architecture, and technology architecture—correspond to four distinct views of the architecture. The business architecture outlines business processes, showing how IT services are provided to business users and are embedded in business processes. The application architecture describes the functionality provided by those services, and the data architecture characterizes the data produced and consumed by applications along with the pertinent business rules. The technical architecture outlines how applications are implemented, showing components, their interconnections, and their interactions. The most complicated of the perspectives, the technical architecture also shows how components are combined to form deployable units, where these units are deployed, and the environments needed to build, verify, operate, and maintain them.
In recent years the body of knowledge and best practices for enterprise architects has grown considerably. I have helped many of my clients select, adapt and adopt these practices to advantage. I anticipate that many architecture practice leaders will wish to incorporate these best practices as part of their own internal architecture practice. In these section, these practices are briefly described. The most important skill, trade-off analysis, is deferred to section 4, where it is discussed in greater detail.
Technical Probe: A technical probe characterizes the organizational context for the architecture initiative, identifying strengths and challenges relative to its current efforts to create and implement enterprise architecture. Through a series of interviews, documentation reviews, and direct observation of teams at work, the technical probe collects facts: observations and documents related to current architecture efforts. Recommendations from the facts gathered serve as the basis for developing action plans to help make an organization more capable of achieving success.
A detailed discussion of the technical probe process, along with sample questions, can be found in chapter 8 of Clement and Northrop, Product-line Architecture (2002).
Business case development:
Before committing to an architectural project, the architecture working group
and its sponsors must define the scope of the proposed project and understand
the level of investment required. As part of this analysis, the team must
complete a risk assessment to estimate the probability of realizing the benefits
of the proposed architecture or architectural improvements. Another important
aspect of the business case is architecture flexibility, with a number of
leading architects now including in the business case the economic value of real
options provided by architecture flexibility. The business case must be
periodically re-evaluated, particularly as part of project reviews with
sponsors, or whenever significant re-planning is required.
Project planning: Since enterprise architecture is a new discipline to many IT departments, established processes must be modified to reflect the increased role of architecture—both in the conduct of projects intended to improve the structure of current systems and in the use of shared standards, reference architectures, components, and other core assets. Many organizations approach this type of process improvement iteratively, improving standard processes and practices by drawing lessons from successful pilot projects. The pilot projects themselves are driven from project plans that have been developed by considering broader principles and industry best practices.
It
has been known for many years that the best systems development, particularly
where systems architecture is impacted, follows the spiral model, illustrated
below by Barry Boehm’s original diagram.
This spiral model can be used as a basis for or
ganizing the plan for the
architecture project. In the spiral model, the riskiest parts of the project are
addressed in early iterations. How the spiral model is instantiated for a
specific project depends on risk factors. In some projects, these early risks
are primarily conceptual and are addressed by creating requirements
specifications and design documents. In other projects, early iterations include
prototypes developed to prove that a technology is feasible, that some key
real-time performance requirement can be met, or that a team has the
capabilities to handle a certain type of work.
In recent years, the biggest risk for many has been in meeting delivery
commitments; thus, early focus is often placed on creating a capability for
meeting key requirements on time, with the team preparing for significant but
orderly re-planning and scope changes in subsequent iterations to ensure
achieving delivery commitments. In the end, risk management is about this
balancing of competing objectives. Enterprise architectures are proving to be
important enablers of these types of mid-course corrections and trade-offs.
Governance for the Enterprise Architecture Initiative: The spiral model, as often applied, takes a team through several iterations, corresponding to the project phases often termed project initiation, project definition, design and planning, and construction and implementation.
From the perspective of the architecture working group and its sponsors, at any point in time there will be a number of architecture projects in various phases. An important role of architectural governance is monitoring the progress of these various projects as they move though the pipeline from initiation to implementation. In a well-managed pipeline, many ideas do not make their way through the entire pipeline: they are stopped or redirected somewhere in the middle. Deciding not to follow through on an idea is not a sign of failure; it need merely mean that the organization has acquired new information suggesting resources should be redeployed. One early and widely reproduced model of this concept depicts the pipeline as a funnel. In the diagram below, the diameter of the funnel represents the range of innovative ideas under consideration in a particular phase. It should be noted that generating and sorting through ideas requires a relatively small investment of resources. The major investment in an architecture project occurs after Screen 2. It is in this third stage that software is coded and systems are integrated.
In the funnel, phase one of the project development represents concept development and idea generation for architecture improvement. In this stage, teams gather ideas from a variety of sources.
The first screen is a review by mid-level managers to determine what additional information is needed before a go/no-go decision can be made at the second screen. In practice, an idea may be reviewed at Screen 1 several times before it is mature enough to proceed into phase two. In phase two of the funnel, project scope is established and a more detailed analysis of the requirements, technical approach, business case, and project plan are undertaken.
The second screen, a true go/no-go decision, is conducted when the phase two analysis is substantially complete but while resource commitments are low, that is, before the major resource buildup for the project. This type of model can be used to manage the flow of constructive and effective ideas for re-factoring and improving the underlying architecture.
Architecture Risk Assessments: Architectural risk assessments are aimed at locating and analyzing trade-offs in system architecture. Risk assessments may be performed either to evaluate a newly proposed architecture or to assess an existing one. When evaluating a proposed architecture, assessment techniques help explore the design space for the first time, systematically evaluating different combinations of design ideas in search of acceptable solutions. It is also possible to assess the risks of using an existing architecture for a given purpose. Whether the subject is new or existing architecture, no combination of design approaches will ever be perfect; thus, risk assessments must focus on identifying and reviewing the trade-offs inherent in the design.
Experience has shown that trade-offs represent the areas of highest risk in an architecture: whenever one quality attribute is sacrificed in return for another, there is a risk of compromising system operation in some unacceptable way. Trade-offs among quality attributes, such as flexibility, extensibility, modifiability, availability, security, and performance, are common. An architectural assessment can help architects understand, for example, how flexibility and extensibility are being compromised to improve performance. It can also help them understand whether the loss of flexibility and extensibility and the associated increased cost of system ownership are acceptable in return for the improved performance.
Effective practices for conducting architecture risk assessments have been collected by the SEI. The SEI’s survey includes, among others, (1) practices from Lucent, (2) the SEI’s own Scenario-based Architecture Assessment Method (SAAM), and (3) David Weiss’ Active Reviews. The SEI’s recommended best practice, Architecture Trade-off Analysis Method (ATAM), combines features from these earlier methods. ATAM is meant to be a risk mitigation method, that is, a means of detecting areas of potential risk within the architecture of a complex software-intensive system. ATAM is intended to analyze an architecture with respect to trade-offs among quality attributes, where those attributes have been expressed in operational terms. By focusing on sensitivity points where quality attributes are affected by design decisions, ATAM can model the trade-offs and constraints architects face in developing or improving an architecture.
An ATAM assessment is often performed by an external team as a means of measuring and managing the risk in high profile projects. To realize full value from the techniques, however, these practices must become a routine part of how architectural approaches are developed and approved. Establishing architectural assessments as a routine part of systems development will require considerable learning on the parts of both the architects and the design community.
Architecture risk assessments can become a means of mentoring less-experienced architects and introducing best practices. With less experienced architects, work products from the initial evaluation are often uneven and incomplete. Much of the work to structure and organize architectural information must be done by reviewers during the review process. Once the reviewers have structured the analysis, the architect becomes responsible for following up by completing the analysis. As the architect gains experience, he prepares more sophisticated inputs to the review process. Also, as the organization becomes more sophisticated, architecture reviews are more easily integrated into the regular workflow. Thus, an architect builds skills through an apprenticeship, responding to feedback from more experienced architects.
Use
Cases and quality attributes: A use case, essentially a scenario or story
describing how the system will be used, is an important tool for expressing
system requirements. A use case can
specify functional behavior as well as quality attributes. To architects, use cases provide a means of describing
how actors will use the functions provided by applications.
By considering actors other than business users, use cases can provide
insight into operations and administrative functions.
Use cases can also be used to characterize work done by developers and
support and maintenance personnel. When
expanded in sufficient detail, use cases can provide considerable insight into
quality attributes such as performance, modifiability, availability, and
security. On the right is a figure
from an SEI report on the Architecture Trade-off Analysis Method (ATAM) that
illustrates some of the detail that can be developed about quality attributes by
considering use cases. The SEI has developed templates for the types of use
cases that they have found most helpful when understanding the quality
attributes a system should possess.
Use cases are helpful to enterprise architects in many ways. Not only can use cases be employed to specify behavior and quality attributes, they can be advantageous in other ways as well. For example, after analyzing the use cases, architects can identify system components, allocate requirements to those components, and develop sequence diagrams or other models of component interactions. In an iterative project, the architect assigns use cases to iterations, typically assigning those with the greatest risk or architectural impact to the earliest iterations. Furthermore, the architect employs use cases as input to interim architecture reviews and as the basis for the operational profiles used in system testing.
Documentation: Architecture documentation can serve as a means of education, a vehicle for communicating among stakeholders, and a basis for systems analysis. Documentation should be regarded as an early version of a system and as subject to careful review for correctness, feasibility, and completeness. Often, the architecture’s ability to achieve key quality attributes can be assessed on the basis of the documentation, allowing for considerable trade-off analysis before investing in the construction of working versions of the system.
One widely used approach to documenting enterprise architectures is based on the work of Zachman. A variation of Zachman’s approach that I have used successfully is illustrated below.
|
|
Inventory |
Principles |
Models |
Standards |
|
Business architecture |
|
|
|
|
|
Information architecture |
|
|
|
|
|
Application architecture |
|
|
|
|
|
Technical architecture |
|
|
|
|
The framework shown helps enterprise architects organize their work products. Typically, not all components of this framework are equally important. In many firms, enterprise architects are likely to find it useful to inventory business processes and to have at least simple models of the most important ones. Enterprise architects should also have a basic model of the information architecture—that is, they should understand the application domains, the entities about which information is kept, the relationships among those entities, and the types of business rules governing their use. Enterprise architects should also understand the application architecture, how IT systems support the business, knowing (1) the types of services provided, (2) how those services are embedded in the business processes, and (3) the major functional and non-functional requirements that those services must satisfy. The bulk of the enterprise architect’s effort is likely to be on the technical architecture. It is important to have accurate inventories of technologies, licenses, and software and infrastructure components. In the course of their work, enterprise architects can be expected to generate a number of models characterizing the technical architecture, outlining components, interconnections and interactions, physical deployment, and technical environments to build, verify, operate, and maintain systems.
Given the objectives set for enterprise architecture, standards will play a prominent role in an architect’s work—the architect will both develop enterprise IT standards and apply those standards in developing reference architectures
How much design documentation is enough? There is considerable discussion of this very point within the software community, with the Agile Development community advocating minimal design documentation (Agile Development Manifesto). The volume and kind of design documentation generated should depend on the circumstances and risks associated with the project.
In my experience, best practice is to allow a design team considerable flexibility in how it documents a design, as long as its approach is planned, not ad hoc, and meets the needs of the project.
Architecture reviews: To ensure the validity of an architecture standard, particularly of a reference architecture, the architecture team must be sure to involve stakeholders and technical peers in providing information and reviewing work products. Technical peers should review, validate, and, if necessary, extend the architect’s analysis. Also, key stakeholders should validate the assumptions, conclusions, and recommendations. Reviews by technical peers and stakeholders should be substantive, having a significant role in shaping the architecture.
Experience has shown that the review process may unfold in many different ways, depending on the maturity of the architects responsible for the work and the sophistication of the organization embedding this process. With less experienced architects, work products are often uneven and incomplete. Consequently, much of the work to structure and organize architectural information must be done by reviewers during the review process. Once the reviewers have structured the analysis, the architect is responsible for following up on action items and completing the work. As the architect gains experience, he will prepare more sophisticated inputs to the review process. Also, as the organization becomes more sophisticated about architecture, it may be possible to schedule more frequent, smaller-scale reviews, interleaving architectural analysis, document reviews, and technical and stakeholder reviews. In my work, I have found that architects build their skills through an apprenticeship, responding to feedback provided during reviews by more experienced architects and stakeholders. The vital guidance, coaching, and supervision during the apprenticeship are provided by the architecture practice leader.
Migration Planning: The architecture team should be concerned with both the current and future scope of services provided by the enterprise architecture. Out of this concern, the team should outline the migration path from current to future state.
Re-architecting an IT system and introducing components needed to support its evolution is a progressive, iterative process: each step re-factors a portion of the system using operations such as splitting components into smaller units, substituting one component design for another, augmenting an existing design by adding components, excluding components from the system, inverting a component by exporting previously hidden information, and porting a component to another system. By combining these operations, developers can simplify architecture, bring it into conformance with standards, or accommodate proposed enhancements.
A typical enterprise architecture initiative begins with a set of existing systems characterized by a large number of point solutions. Often these point solutions offer different solutions to similar problems. Many point solutions also incorporate different technologies for similar ends.
The
figure on the left illustrates the role of re-factoring in consolidating many point
solutions and establishing a healthy architecture. This model, one I developed a
number of years ago with some coauthors as part of a study of a product-line
architecture for a telecommunications system, shows the dangers of over- or
under-investing in an architecture. As
a consequence of under-investing, an architecture cannot support all of its
required features. To compensate, developers introduce a multiplicity of point
solutions. By contrast, over-investing can lead to a form of analysis paralysis,
where the base architecture is designed to support features that may never be
implemented—at the cost of failing to meet delivery commitments.
In a healthy architecture, the platform is designed to meet current
requirements and then is periodically re-factored to ensure it continues to
support new requirements as they emerge. Thus,
as part of maintaining a healthy architecture, enterprise architects must
interact with operations teams, developers, and business analysts responsible
for establishing high-level systems requirements. By combining information from
these various sources, enterprise architects can develop a migration plan to
progressively re-factor components, evolving the software from its current state
to the proposed architecture .
A reference architecture can be used to describe the design of a common service. A common service is one that may be implemented in a number of contexts in several business units. A reference architecture shows how the service can be implemented using reusable components and in compliance with enterprise architecture standards. Typically, the reference architecture will be adapted by application architects as part of applying it in a specific systems development project. As part of adapting the architecture, some components may be added, others excluded, and yet others partitioned or replaced. It is, therefore, important that the reference architecture be flexible enough to support these operations. Various design techniques which promote flexibility include the separation of concerns through layering, the use of well-defined connectors and middleware, and the use of design patterns such as contracts and facades.
In this section, several topics are considered, including an approach to incorporating architecture practices into established development processes, establishing the scope of a reference architecture, and developing the architecture itself. Trade-off analysis figures prominently in both scoping and developing the architecture.
The process of defining the scope of a reference architecture typically includes three steps: (1) identifying the features and attributes that will be common to most implementations of the architecture, (2) developing alternative operational concepts capable of meeting those common requirements, and (3) selecting the alternative that best meets organizational objectives.
In some firms, business units have already determined the features and services they need from enterprise IT systems. The architecture team should, therefore, analyze this information to understand the implications for establishing enterprise architecture standards and designing reference architectures for common services. In particular, the team should study the needs of various architecture segments and the features and attributes of existing services. A full list of functions and quality attributes would be quite long. Thus, for each service considered, the team should summarize their findings, identifying key functions and describing quality attributes related to capacity, performance, reliability and fault-tolerance, operations and serviceability, and support for future enhancements. In reviewing these summaries, the team should highlight those that apply broadly across segments. The key result from this scoping exercise is a matrix (shown below) of the features and attributes that should be addressed by the reference architecture.
From this matrix, architects can identify the features and attributes that would be common to most implementations of the reference architecture.
The second step will be to define alternative operational concepts that can meet these core requirements. In practice, as noted previously, trade-offs are inevitable. For any core requirement, there will usually be several distinct ways of addressing it. For example, suppose the requirement is to provide enterprise data to mobile users. These requirements could be addressed by (1) providing mobile users with wireless access to enterprise systems, (2) replicating enterprise data onto the mobile user’s laptop, periodically synchronizing the user’s data with the master copy maintained on enterprise systems, or (3) implementing mobile IP and local resource discovery on the network over which users roam. Each of these operational concepts has strengths and weaknesses. For each core requirement, we can brainstorm several ways it can be met. Often an operational concept, while meeting one requirement, will have a negative effect on others. Furthermore, some of the operational concepts will be incompatible and cannot be included in the same solution. Architects often find it useful to construct a correlation matrix that shows how operational concepts may effect multiple requirements or interact with each other. A portion of a template for the correlation matrix is illustrated below.
Information from the correlation matrix can be used during trade-off analysis to generate alternative solutions. Each proposed solution attempts to address critical requirements with a different combination of operational concepts. After several alternative solutions have been generated, a more formal decision process can be used to rank them. The figure below represents the process, including both the trade-off and decision analysis.
Once a solution concept has been generated, the design analysis can begin. Architects must generate a detailed description of how a technical architecture will implement the solution concept.
An enterprise architecture initiative often has, as one its stated goals, developing a production capability for a family of related IT services. To this end, a set of core assets should be developed and reused throughout the enterprise. Core assets can include requirements specifications, designs, components, tools and processes, documentation, and training. Core assets can also include real-time performance models, other architecture-evaluation results, test plans, and test cases.
Chief among these core assets is the reference architecture. The reference architecture describes the design elements shared by IT services within the family. The reference architecture also identifies the variation points required to support the spectrum of implementations within the family. In addition, the reference architecture specifies the standard configuration of components required for the service and provides interface specifications for the shared components and a composition model for generating various members of the product family.
As part of developing reference architecture, architects must consider system partitioning, isolating the variation points, and accommodating the full range of variation among likely applications of the reference architecture. As part of partitioning the system, architects must answer key questions. (1) What components should shared? (2) What behaviors have been assigned to them? (3) How will they work with each other to achieve system behavior? The specification of shared components should be relatively detailed, including mechanics and semantics of each of the component’s entry points. Interface mechanics should include syntax, protocols and conventions for exchanging information such as input parameters, computed values, authentication and authorization information, and error handling. Interface semantics include invariants and transformations characterizing inputs and outputs. Many components are stateful, in which case sequence diagrams or finite-state machines may be used to specify component behavior. Architects should also address design constraints and quality attributes such as capacity, performance under stress, and required accuracy, paying special attention to safety, liveness, and fairness properties, particularly with respect to timing and resource utilization.
In developing a reference architecture, it is rarely possible to meet all requirements for all intended uses. Inevitably, there must be trade-offs. Architects must explore a wide range of design ideas to achieve an appropriate balance among the trade-offs. Trade-off analysis provides a systematic approach for selecting one architecture over alternatives. It provides a rigorous discipline for developing rationale, explaining why design decisions were made, how quality attributes will be achieved, and why alternatives were rejected.
Trade-off analysis can be used to evaluate the candidate architecture against the qualities expressed in the utility tree (illustrated on page 7). Architects generate candidate architectures by combining design options from a catalog they have developed. As part of the evaluation, architects identify sensitivity points, that is, places in the candidate architecture where changes will affect the architecture’s ability to meet specified quality attributes. Often it is possible to improve a candidate architecture in a stepwise manner by carefully evaluating design alternatives for the most sensitive parts of the architecture.
In some cases, architects will find that a single design decision impacts several quality attributes. Changing the design at such a sensitivity point will enhance some quality attributes but diminish others, for example, improve performance but compromise security. These are the trade-offs. Much of an architect’s work is in identifying and optimizing trade-off points. As part of this work, architects often consult specialists for detailed information about alternative design approaches. Architects may also apply specialized analytical tools, as for estimating system reliability or modeling performance.
By far, the most successful approach to developing complex systems has been to use a combination of decomposition and composition. These so-called “middle-out approaches” begin with simple functionalities associated with specific scenarios derived from the system’s operational concept, that is, its use cases. A decomposition is proposed that works for these selected scenarios. Then, the set of functions supported by the design is progressively enlarged as more use cases are considered. As a rule of thumb, scenarios that reveal quality attributes such as performance, fault-tolerance, recoverability, scalability, and extensibility have the most profound impact on the architecture and entail the greatest project risk. Thus, these risky scenarios should be considered early, as part of developing the initial architecture.
A good architecture, as with any complex idea, requires input from many subject matter experts and stakeholders. The more the architect solicits and responds to diverse perspectives, the more interesting and relevant the architectural ideas; that is, the more ideas are discussed, the better they get. An organization needs to put some formality around some of these architectural discussions to ensure that all important topics are covered, that findings are not lost, that there is a repeatable process around the acceptance and approval of work, and that authorization to take next steps has been received.