ARCHITECTURE IN PRACTICE
Preparing for architecture
The current level of architecture maturity determines the type and scope of work that can be undertaken, and the preparation needed before starting work. Typical items to be assessed include:
• governance: funding, reporting relationships, organisational authority, primary stakeholders, performance metrics, etc.
• principles: applicable guidelines, policies, priorities, etc.
• standards: applicable laws, regulations, external and internal standards, etc.
• scope: primary focus of work, aligned to maturity level – e.g. technology infrastructure, information systems, business integration – and core business goals and business drivers, etc.
• frameworks: applicable taxonomies, ontologies, reference models, etc.
• methods: architecture development, solution development, implementation, project management, change management, administrative procedures, etc.
• tools: capture, edit, scenario development, presentation, communication, etc.
Each of these items will need regular review as the maturity of the practice develops.
The TOGAF 9 specification provides a proven detailed description54 of the preparation needed for mid-maturity architecture centred on IT. Some amendments will be required to adapt that description for use in later-maturity architecture, and to broaden its scope beyond IT, but its general principles remain sound at all maturity levels.
The architecture cycle
Architecture development is iterative, a continual process of assessment, design and implementation. For best return on effort, iterations need to be brief, that resembles an Agile55 software-development cycle, each iteration linked to a specific business purpose and demonstrable business value.
Despite some amendments in its Version 9, the TOGAF-ADM cycle is still in essence a Waterfall style of development: it is iterative, but iterations tend to last months, if not years. The architecture method summarised here56 extends the ADM to work with any business level or scope and align with Agile governance principles. It can be used
54 Chapter 6 ‘Preliminary Phase’ and Part VII ‘Architecture Capability Framework’ in TOGAF™ Version 9, Van Haren, 2009.
56 For details, see the ‘Methodology’ chapters in Tom Graves, Bridging the Silos, Tetradian, 2008.
The method also maps well with PRINCE2 and similar programmes or project management methods and governance. Each phase ends with a formal stakeholder review, and the key governance documents or ‘products’ also mark the boundaries between the architecture cycle phases.
Architecture projects and their iterations are managed in accordance with the rules defined in the preparatory Preliminary Phase, whose tasks include:
• Establish the enterprise architecture capability
• Identify ‘Architecture Principles’
• Identify applicable business policy, legislation and regulations
• Identify applicable Standards
• Identify core business goals and business drivers
• Identify enterprise architecture scope
• Identify constraints
• Identify stakeholders and concerns, business requirements, and overall architecture Vision
• Identify content for high-level models.
The final step is a stakeholder review to secure formal approval for the Architecture Charter and other governance definitions.
The assessment phases of the cycle deliver architecture models, design requirements and the like. The focus of governance is more on the architecture itself than on programme management, though the latter should be informed and engaged throughout the assessment process.
Phase A – establish iteration scope
This phase is the starting point of a regular architectural-services cycle to identify the purpose, scope and context for the current iteration. Typical steps include:
• Establish the business purpose and scope of the cycle
• Review applicable Architecture Principles, policies, etc.
• Identify business goals and strategic drivers
• Establish the architecture-framework scope of the cycle57
• Identify additional stakeholders, concerns and requirements
• Identify additional constraints.
The stakeholders review the results, documenting formal approval to proceed in a Statement of Architecture Work.
Phase B – assess current context
This phase establishes the current ‘as-is’ architectural context for the scope specified in Phase A. Typical steps include the following:
• Develop Baseline Architecture for ‘as-is’ context
• Select reference models, views and viewpoints
• Create and update ‘as-is’ architecture models
• Review ‘as-is’ architecture against qualitative criteria
• Finalise building-blocks for the architectural scope.
The stakeholders review the results of the assessment, and confirm the ‘as-is’ definition.
Phase C – assess future context
This phase establishes the probable or intended future context for the scope and each future time horizon specified in Phase A. The steps are almost identical to those in the ‘as-is’ assessment: the only difference should be that the architecture developed would apply to the respective time
• Develop Baseline Architecture for ‘to-be’ context
• Select reference models, views and viewpoints
• Create and update ‘to-be’ architecture models
• Review ‘to-be’ architecture against qualitative criteria
• Finalise building-blocks for the architectural scope.
On completion of assessments for all required time horizons, the stakeholders review and compare the results, and confirm the definition of the required ‘to-be’ for each time horizon.
Phase D – derive change requirements
This phase establishes the gap between the ‘as-is’ and ‘to-be’ for the scope and each time horizon specified in Phase A, and identifies the resultant requirements for change. All steps should be repeated for each time horizon in scope.
• Construct and validate matrix of ‘as-is’ to ‘to-be’ architectures
• Derive change requirements from validated matrix
• Review requirements against existing dispensations
• Review requirements against qualitative criteria.
On completion of gap analyses for all required time horizons, the stakeholders review and compare the results, and confirm the change requirements definitions for each context.
In the solution phases, the focus of governance moves to project and programme management, with enterprise architecture called upon mainly to provide architectural guidance and arbitration between projects, . and maintain high-level consistency as the architecture changes over time.
Note that the design and implementation phases (E to G) may not always be required. Not every assessment will lead to requirements for change; and of those that do, many of the requirements may be operational or cultural rather than technical. In particular, it should be understood that architectural assessments do not lead automatically to requirements for IT-based ‘solutions’.
Phase E – design solutions
During this phase, the architecture unit will provide technical and other support to assist the sponsor in selecting appropriate options to resolve the respective change requirements. In this phase, solution designs will usually be at a high-level only. Note that the key responsibility for decisions on solution designs rests with the sponsor, not the architecture unit. Typical steps include:
• Review gap analysis and requirements from Phase D
• Identify business drivers and constraints for implementation
• Brainstorm technical requirements from functional perspective
• Brainstorm co-existence and interoperability requirements
• Perform architecture reassessment and gap analysis
• Develop preliminary solution designs
• Identify major work packages or projects.
At the end of the assessment, stakeholders will review and sign off any solution designs.
Phase F – plan migration
During this stage, the architecture unit assists the sponsor and programme management in developing detailed solutions and plans to implement the proposed solutions. The key responsibility for decisions rests with the sponsor and the programme-management body, not the architecture unit. Enterprise architecture has more of a ‘watching brief’ than an active role in this phase. Dependent on detail-level governance for project, programme and change management, typical steps would include:
• Prioritise projects
• Estimate resource requirements and availability
• Perform cost/benefit assessment of the various migration projects
• Perform risk assessment
• Generate time-lined implementation roadmap
• Document the Migration Plan.
On completion, the sponsor and other stakeholders will review and signoff the final solution designs and project or migration plans.
Phase G – guide implementation
During this phase, the architecture unit supports designers, developers, programme management and others to sustain architecture compliance during implementation of the solutions and plans from the previous phases. Overall governance belongs to project or programme management. The architecture unit should assess architecture issues arising from each ‘gateway’ in the project plan; typical steps at each gateway would include:
• Review Architecture Compliance Statement from developers
• Assess impact on overall architecture
• Provide architecture advice in an Architecture Response Statement.
At the end of each project in the migration plan, stakeholders will carry out a review of any architecture issues arising from the implementation.
Phase H – review lessons learned
During this phase, the architecture unit reviews the results of the iteration in terms of benefits achieved for the business, as well a simplications and impact on overall future architecture. This will often result in updates or additions to the set of primitives, models, meta-models, patterns, and other content in the architecture repository; to requirements, standards and other decisions; to the content of the shared glossary and thesaurus; and entries in the issues and risks registers.
In a ‘traditional’ Waterfall approach, such as in the TOGAF model, only one architecture cycle is in process at any time, hence the lessons-learned review takes place at the end of the cycle. However, in an Agile-type context, and as architecture maturity develops, many cycles may be running in parallel, with differing scopes and at different rates, all interleaving with each other. In that method it makes more sense to conduct these reviews on a regular basis – weekly or monthly – rather than at the end of each cycle. In either case, typical review steps include:
• Assess results from the architecture cycle
• Monitor changes in business and technology environment
• Assess potential changes to framework, methodology, etc.
• Assess requirements and options for architecture change.
On completion, architecture stakeholders re-evaluate the results of the architecture work, and sign off on any proposed architecture cycles and other changes arising from the review.
A mature enterprise architecture capability can also take a ‘hands-off’ approach, allowing some aspects of the architecture to emerge in their own way from the complexity of the context.58 Note that use of such a strategy should only be attempted where the implications and trade-offs are fully understood and addressed: it is not suitable solely as a cost-cutting exercise. A key
Hands-off architecture relies on the existence of a well understood ‘city plan’ for the architecture of the enterprise. For projects and change programmes, governance depends on two key documents: the Architecture Description Statement, and Architecture Position Statement.
The project management cycle should include one or more ‘notify’ gateways at which the architecture unit is notified about the architecture implications of a proposed development. At each Notify gateway, the developers present an Architecture Description Statement to programme management, summarising the architecture of their solution and its usage of, and compliance to, the respective reference frameworks in the ‘city plan’. (This is equivalent to the assessments developed in the ‘assessment’ phases of the main architecture cycle, but prepared by the developers rather than the architects.) The architecture unit has the option to respond via an Architecture Position Statement, outlining any recommended changes. The programme management unit acts as the final arbiter.
The architecture unit also maintains a watch on all projects passing through programme management, to identify potential for project synergies, and emerging developments that might suggest revisions to the overall architecture and ‘city plan’.
At the end of the project cycle is an ‘As-built’ gateway in which the developers create a simplified Architecture Description Statement to notify the architecture unit about the architecture of the final ‘as-built’ solution. This again allows the architecture unit to watch for emergent innovations, and also to plan remedial action if required.
No matter how good the architecture development is, it will only have real value for the enterprise if it is applied and put to practical use. The key requirement for this is some form of feedback and engagement of stakeholders, not only in the initial development of architecture, but also its dissemination, review and reuse.
For publishing, all of the purpose-built architecture toolsets will autogenerate content for an intranet or website. Some toolsets include facilities to control access to, and visibility of, architecture models and other content; some also include wikis and other mechanisms to permit feedback and discussion via the architecture website.
Enterprise architecture is a discipline that enhances enterprise effectiveness by helping people create structures that best support the required business values. It manages a body of knowledge about enterprise structure and purpose, but that information has no inherent value in itself: instead, its value arises from how it is used, across every domain of the enterprise.
It is essential for architects to measure the business value of their work by any means available. These include:
• Measurable operations – cost savings from reduced redundancy and duplication
• Measurable development – cost savings from reduced duplication of effort and from identifying synergies between projects
• Measurable gains in reduced time to market, time to project completion, etc.
• Measurable or identifiable gains from simplifying system integrations after merger or acquisition
• Creation of, or direct support for, identifiable business opportunities and innovations
• Business improvements implied by improved performance against a verifiable architecture-maturity metric.59
Maturity models are important because much of the business value gained, especially in later-maturity architecture, arises from interactions across the whole of the enterprise. It cannot be tracked by any single metric: it can only be measured in terms of the performance of the whole.
Ultimately, the real business value of enterprise architecture lies not so much in the models and designs and other artefacts, but more in engaging everyone in an enterprise-wide dialogue on architecture – in creating and maintaining an
59 Sogeti Maturity Matrix: http://eng.dya.info/Home/services/architecture_maturity_model.jsp