A Brief Introduction to Architecture Development Process and Its Adoption

A typical architecture practice within a business supports three very distinct architecture capabilities namely enterprise architecture management, solution architecture management, and technical architecture management, collectively they provide various architecture services to the business and IT organizations.

For every service provided under these architecture capabilities there are associated business processes to deliver the services. One of the key and well-known of the services, of course, is the service for developing architecture (models and model-views) for various stakeholders. Just so it is clear, enterprise architecture models are not the same as solution architecture models and they are not the same as technical architecture models. Each level of models individually serves very different purpose and is intended to be consumed by different business an IT stakeholder with very diverse interests.

The article - Enterprise Architecture for Operating Model – A Deeper Dive, provides the details about the conceptual, logical, and physical level architecture views of the enterprise at different scales through the design of operating models that serve interests of various business and IT stakeholders with varying level of details covering certain depth and breadth.

Each of the architecture development processes under the three architecture capabilities have their own separate lifecycles. People playing one of these three types of architect roles produce relevant architecture deliverables under the given type of architecture as per the needs of the stakeholders using appropriate architecture tools. What deliverables and artifacts typically get produced under these three architecture capabilities will be the topic for a future article. In this article, however I would like to provide a brief introduction to an architecture development process and show how this process aligns with the overall strategic planning cycle.?

See the article The Strategic Planning Cycle for details on strategic planning cycle.

From the process standpoint each of the three types of architecture development work is performed at different stages of the strategic planning cycle. During the Plan and Develop stages most of the work towards the conceptual architecture i.e., the Enterprise Architecture is completed and during the Develop and Implement stages the logical architecture work is completed, and the final Physical or Technical architecture work is completed during the latter part of the Implement stage of the cycle.

As described in the article - Holistic Architecture - Architecture Domains and Crosscutting Concerns, an architecture regardless of whether it is at the Conceptual, Logical, or physical level, should provide different perspectives based on the main architecture domains, namely, business, application, data, and infrastructure that are described through the lens of the crosscutting concerns namely, security, integration, performance, availability, scalability, reliability, and cost.

All architecture development processes for the three types of architecture share the following common steps.

1. Define the scope and vision of the architecture work for the given architecture cycle,
2. Develop ‘just enough’ domain architectures considering applicable crosscutting concerns
3. Create the deliverable’s breakdown with the help of an implementation plan for the architecture
4. Provide implementation governance and assurance to ensure the implementation adheres to the design
5. Identify deviations for remediation as future change requests to be considered under the next architecture cycle.

These stages of architecture development process follow a common pattern which is very similar to what is suggested in TOGAF. The TOGAF Framework provides guidance on architecture development process under the section Architecture Development Method (ADM).

TOGAF ADM

Here is the famous ‘crop circle’ diagram depicting the ADM cycle (courtesy, The Open Group) with a quick overview of its phases.?

• Preliminary: this is an optional phase, a one-time activity, required only at the start of establishing a new architecture practice. It involves the preparation and initiation activities required to meet the business directives for a formation of a new Architecture practice including the adoption of some Organization-Specific Architecture framework and creation of principles.
• Phase A – Architecture Vision: this is the initial phase of the ADM. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals for the given architecture project and creating a formal or informal charter.
• Phase B – Business Architecture: This phase involves the development of a Business Architecture to support an agreed Architecture Vision.
• Phase C – Information Systems Architecture: this phase involves the Information Systems architectures for architecture project, in other words, it involves development of Data and Application architectures.
• Phase D – Technology Architecture: this phase involves the development of a Technology Architecture for architecture project. The diagram also shows more detailed steps involved within this phase.
• Phase E – Opportunities and Solutions: This phase involves the process of identifying delivery vehicles (projects, programs, and portfolios, or themes, epics, and backlogs) that effectively deliver the Target Architectures identified in the previous phases.
• Phase F – Migration Plan: This phase describes how to move from the baseline to the target Architectures by finalizing a detailed implementation and migration plan.
• Phase G – Implementation Governance: This phase provides an oversight and assurance during the implementation of the architecture.
• Phase H – Architecture Change Management: this phase looks at establishing procedures for managing change to the new architecture.
• Requirements Management: of ADM is a continuous phase, that is, it is managed throughout the ADM cycle; the requirements can evolve and change during any stages of the cycle and must be taken into considerations during each of the phases.

The above ADM process can be adopted and customized to suit development of any one of the three types of architectures, namely enterprise, solutions, and technical.

The following diagram (courtesy, The Open Group) gives another perspective on how the conceptual, logical, and physical level architectures, i.e., enterprise, solution, and technical architectures are interrelated.

The large strategic impact at the enterprise level is assessed and target architectures of the enterprise are developed at the conceptual level under enterprise architecture development process which describes the impact on the enterprise in terms of target operating model changes at various levels within the organization. A group of related capabilities that are identified under a target operating model impact and design details of the target operating models are flushed out in terms of solution design for integrated business processes and technology solution building blocks and implemented in manageable chunks (epics/projects) under the logical segment architecture process. And finally design of the individual capability (people, process, and technology) impacted is further flushed out at the capability level or physical level with the finest details at this level’s architecture development process.

Implementation of enterprise architecture results in the delivery of solution architecture. Implementation of solutions architecture results in the delivery of technical architecture. And implementation of technical architecture results in a viable product or service delivered to the end-user.

The following diagram shows how the ADM can be adopted for development of all levels of architectures (courtesy, The Open Group). It shows how the three architecture development processes for enterprise, solution, and technical architecture are related. As it should also be clear from the diagram that for every enterprise architecture there can be one or more solution architectures and for every solution architecture there can be one or more technical architectures. The lifecycle of the next level development process cycle begins at the Migration planning phase (F) of the higher-level ADM cycle. In a way ADM can be recursive.

Adopting Scalable Agile Framework

The operating model of the architecture practice may work within either traditional linear (or waterfall) development framework or it is specifically developed to support agile frameworks.

As described in the article - Scalable Agile Frameworks, any one of the scalable agile frameworks may be adopted to support the operating models for the essential capabilities required for strategic planning cycle, including of course, the architecture practice.

ADM is a process for architecture development. It is complementary to and integrates with management processes associated with other essential capabilities (Agile delivery, change management, release management, etc.).

The following diagram shows how SAFe agile framework can be adopted to support architecture development using agile processes to develop architectures at all three levels – enterprise, solutions, and technical. (Courtesy, SAFe).

Enterprise architecture is developed at the enterprise level using its own agile development cycle where a portfolio backlog of architecture enablers along with epics is created. Which is then is flushed out further under the solution delivery release train by the solution architects using its own agile architecture development process as the solution delivery or program backlog consisting of architecture specific enablers and solution user stories. And finally, the individual agile teams (scrum/Kanban) develop the team backlog of user stories that also include the technical architecture enablers and deliver them using its own agile architecture development process.

All the three levels of architecture development may adopt ADM process to deliver ‘just enough’ architecture in form of enabler backlog items for the next iteration.

ADM Mapping to Strategic Planning Cycle

The following diagram shows how the strategic planning stages namely Plan, develop, and Implement stages map with various ADM Phases of the Conceptual architecture development. The mapping with the ADM phases for Logical and Physical architecture development are not shown in the diagram below for the sake of simplicity.

The Plan stage of the strategic planning cycle coincide with the Phase A of the top-level conceptual architecture development process, at this stage the goals and objectives which are the outcomes of the Plan stage are fed into the Develop stage to develop the vision and target operating models consisting of impacted business capabilities.

The Develop Stage is where the details of the target operating models and their respective business capabilities are flushed out in terms of the right required roles and responsibilities of people, and their org structures, who will be performing routine activities using specific business processes exchanging information and applying specific technologies to deliver business services.?The conceptual business and technology architectures are created at the Develop stage and these activities map to the Phases B, C, and D of the top-level conceptual architecture development process using ADM cycle.

At the Develop stage, larger and complex capabilities may also be further broken down into manageable chunks of increments and logical transitional architectures are created for these increments. These architecture activities are mapped to the Phase E and F of the top-level conceptual architecture development process using the ADM cycle.

At the Implement stage the details of the capabilities are even further broken down where the technical architecture for individual building blocks is created.

Finally, although not shown in the diagram above, the phases G and H of the conceptual architecture development process using ADM map to the Monitor stage of the strategic planning cycle. This is where any exceptions and deviations from the enterprise architecture are identified and planned to be remediated in the next round of the strategic planning (or ADM) cycle.

Author: Sunil Rananavare, IT Strategy Planning and Architecture (CIO Advisory)

Follow me on LinkedIn to stay informed.

The views in the article are author’s own and not necessarily of his employer.?