Day 3
Supporting Guidelines and Techniques
The Purpose of Architecture Principles
Architecture Principles should address the following purposes:
- Enabling decision-making
- Aligning the enterprise
- Ensuring Governance
- Understanding Values and culture
The Purpose of Architecture Principles
- Enabling decision-making - it is important to set precedence during trade-off discussions and authority of “tie-breaking” if it must occur.
- Aligning the enterprise - principles take subjectivity and bias out of the equation and drive critical conversations that are objective and aligned to the enterprise’s values.
- Ensuring Governance - how will the enterprise ensure that the right decisions are surfaced at the right time and with the right decision-makers, and, moreover, how to monitor the decisions and approach taken to arrive at the decision?
- Understanding Values and culture - provide a better understanding about the enterprise’s culture and values; provide an approach and insight into how well the enterprise reacts to change.
Existing Architecture Principles
If Architecture Principles exist from a prior EA Capability effort, they can be used to provide a context of the previous efforts to establish an Enterprise Architecture Capability
- they inform how the Enterprise Architecture Capability was viewed, viewed itself, and what purpose it was explicitly, or implicitly, supporting.
Developing Architecture Principles
- They are typically developed by Enterprise Architects
- In conjunction with key stakeholders:
- The Enterprise ClO
- Architecture Board
- Business Stakeholders
- Approved by the Architecture Board
- Architecture Principles will be informed by principles at the enterprise level, if they exist.
- Architecture Principles must be clearly traceable and clearly articulated to guide decision-making.
Architecture Principles Template
Name
- Should represent the essence of the rule, and be memorable
- Should not mention specific technology platforms
- Should avoid ambiguous words
Statement
- Should succinctly and unambiguously communicate the fundamental rule
Rationale
- Should highlight the business benefits of adhering to the principle, using business terminology
- Should describe the relationship to other principles
Implications
- Should highlight the requirements for the business and for IT for carrying out the principle
- Should state the business impact and consequences of adopting the principle
Examples
Qualities of Architecture Principles
- Understandable
- Robust
- Complete
- Consistent
- Stable
Five Qualities of Architecture Principles
- Understandable: the underlying tenets can be quickly grasped and understood by individuals throughout the organization. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
- Robust: enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations.
- Complete: every potentially important principle governing the management of information and technology for the organization is defined - the principles cover every situation perceived.
- Consistent: strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.
- Stable: principles should be enduring, yet able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.
What is a Business Scenario?
- A method used to help identify and understand the business requirements that an architecture must address.
- A representation of a significant business need or problem and enables vendors to understand the value of a solution to the customer.
What does a Business Scenario describe?
A business scenario describes:
- Real business problems
- The business and technology environment in which those problems occur
- Value streams enabled by capabilities
- The desired outcome(s) of proper execution
- The human and computing components (the “actors”) who provide the capabilities
Gap Analysis
- The purpose of gap analysis is to document the difference between the baseline and the target architectures
- It identifies components (building blocks) of the architecture that are added, deleted, and/or changed
Interoperability
Definition: “the ability to share information and services”.
Interoperability Categories
- Operational or Business Interoperability defines how business processes are to be shared
- Information Interoperability defines how information is to be shared
- Technical Interoperability defines how technical services are to be shared or at least connect to one another
How Interoperability is Used in ADM Phases A and B
- Architecture Vision: the nature and security considerations of the information and service exchanges are found using business scenarios.
- Business Architecture: the information and service exchanges are further defined in business terms.
- Data Architecture: the content of the information exchanges is detailed using the corporate data and/or information exchange model.
- Application Architecture: the way that the various applications are to share the information and services is specified.
- Technology Architecture: the appropriate technical mechanisms to permit the information and service exchanges are specified.
- Opportunities & Solutions: actual solutions are selected; e.g., Commercial Off-The-Shelf (COTS) packages.
- Migration Planning: interoperability is logically implemented.
Business Transformation Readiness Assessment
- Enterprise Architecture often involves considerable change.
- There are many dimensions to change, but by far the most important is the human element.
- Understanding the readiness of the organization to accept change, identifying the issues, and then dealing with them in the Implementation and Migration Plan is key to successful architecture transformation in Phases E and F.
- This is a joint effort between corporate (especially human resources) staff, lines of business, and IT planners.
Recommended Activities
- Determine the readiness factors that will impact the organization
- Present the readiness factors using maturity models
- Assess the readiness factors, including determination of readiness factor ratings
- Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
- Work these actions into Phase E and F Implementation and Migration Plan
Risk Management
- The ISO 31000 definition of risk management is “coordinated activities to direct and control an organization with regard to risk”
- ADM Techniques, Risk Management describes it as a technique to mitigate risk when implementing an architecture project
Risk Management in the ADM
- Risks are identified in Phase A as part of the initial Business Transformation Readiness Assessment.
- The risk identification and mitigation assessment worksheets are maintained as governance artifacts and are kept up-to-date in Phase G (Implementation Governance) where risk monitoring is conducted.
- Implementation governance can identify critical risks that are not being mitigated and might require another full or partial ADM cycle.
How to Apply the TOGAF® Standard
Iteration Within an ADM Cycle (Architecture Development Iteration)
- Projects may operate multiple ADM phases concurrently.
- Projects may cycle between ADM phases, in planned cycles covering multiple phases.
- Projects may update work products with new information.
Iteration to Develop a Comprehensive Architecture Landscape
- Projects will exercise through the entire ADM cycle, commencing with Phase A. Each cycle of the ADM will be bound by a Request for Architecture Work.
- The architecture output will populate the Architecture Landscape, either extending the landscape described, or changing the landscape where required.
- Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects.
- One project may trigger the initiation of another project.
Architecture Landscape
Definition: “The architectural representation of assets in use, or planned, by the enterprise at particular points in time.”
Architecture Levels
- Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
- Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective Architecture Roadmaps at a program or portfolio level.
- Capability Architecture provides an organizing framework for change activity and the development of effective Architecture Roadmaps realizing capability increments.
Architecture Partition
Definition: “A subset of architecture resulting from dividing that architecture to facilitate its development and management.”
Partitions
- Partitions are used to simplify the development and management of the Enterprise Architecture.
- Partitions lie at the foundation of Architecture Governance.
- Partitions are distinct from levels and the organizing concepts of the Architecture Continuum.
Reasons for Partitioning the Architecture
- Organizational unit architectures conflict with one another.
- Different teams need to work on different elements of architecture at the same time; partitions allow for specific groups of architects to own and develop specific elements of the architecture.
- Effective architecture re-use requires modular architecture segments that can be taken and incorporated into broader architectures and solutions.
Purposes of Enterprise Architecture
Four Purposes to Frame Architecture Projects
- Enterprise Architecture to Support Strategy: Deliver Enterprise Architecture to provide an end-to-end Target Architecture, and develop roadmaps of change over a three to ten-year period.
- Enterprise Architecture to Support Portfolio: Deliver Enterprise Architecture to support cross-functional, multi-phase, and multi-project change initiatives.
- Enterprise Architecture to Support Project: Deliver Enterprise Architecture to support the enterprise’s project delivery method.
- Enterprise Architecture to Support Solution Delivery: Deliver Enterprise Architecture that is used to support the solution deployment.
Four Purposes to Frame Architecture Projects
- Enterprise Architecture to Support Strategy: An architecture for this purpose will typically span many change programs or portfolios. In this context, architecture is used to identify change initiatives and supporting portfolio and programs. Set terms of reference, identify synergies, and govern the execution of strategy via portfolio and programs.
- Enterprise Architecture to Support Portfolio: An architecture for this purpose will typically span a single portfolio. In this context, architecture is used to identify projects, and set their terms of reference, align their approaches, identify synergies, and govern their execution of projects.
- Enterprise Architecture to Support Project: An architecture for this purpose will typically span a single project. In this context, the architecture is used to clarify the purpose and value of the project, identify requirements to address synergy and future dependency, assure compliance with architectural governance, and to support integration and alignment between projects.
- Enterprise Architecture to Support Solution Delivery: An architecture for this purpose will typically be a single project or a significant part of it. In this context, the architecture is used to define how the change will be designed and delivered, identify constraints, controls, and Architecture Requirements to the design, and, finally, act as a governance framework for change.
The Digital Enterprise and Enterprise Architecture
- The need for companies to evolve into digital enterprises can be linked to a variety of drivers, not least the rapid change in technologies driving new ways of working, socializing, and entertaining.
- Enterprise Architecture supports and enables the Agile environment in delivering and enhancing digital products and services quicker and easier by providing insight into various areas.
Enterprise Architecture Supporting and Enabling the Agile Environment
- Reactively managing technical debt as the result of sprints in a cohesive and connected fashion
-
Proactively managing technical debt and anticipating Agile development needs by:
- Identifying standards and re-usable standard components that support shortened Agile development cycles
- Appropriate governance or guardrails to oversee the re-use of components
-
Managing matured digital products and delivering operational excellence by:
- Simplifying complexity in the digital ecosystem using the TOGAF ADM
- Establishing an Enterprise Architecture Capability that drives operational excellence in the management of digital products and services
Governance
- ISO/IEC 38500:2015 defines governance as: “a system that directs and controls the current and future state”.
- Governance is a decision-making process with a defined structure of relationships to direct and control the enterprise to achieve stated goals.
What Do We Mean by Governance?
The way in which decisions are made:
- Who is responsible?
- Who is involved?
- Who is accountable?
Introduction to Architecture Governance
The practice by which Enterprise Architectures are managed and controlled. This includes:
- Controls the creation and monitoring of components and activities - ensuring introduction, implementation, and evolution of architectures
- Ensuring compliance with internal and external standards and regulatory obligations
- Supporting the management of the above
- Ensuring accountability to external and internal stakeholders
Architecture Governance
Architecture Governance typically operates within a hierarchy of governance structures which can include all of the following as distinct domains with their own disciplines and processes:
- Corporate Governance
- Technology Governance
- IT Governance
- Architecture Governance
Each of these domains of governance may exist at multiple geographic levels - global, regional, and local - within the overall enterprise.
Benefits of Architecture Governance
- Discipline - All involved parties will have a commitment to adhere to procedures, processes, and authority structures established by the organization.
- Transparency - All actions implemented and their decision support will be available for inspection by authorized organization and provider parties.
- Independence - All processes, decision-making, and mechanisms used will be established so as to minimize or avoid potential conflicts of interest.
- Accountability - Identifiable groups within the organization - e.g., governance boards who take actions or make decisions - are authorized and accountable for their actions.
- Responsibility - Each contracted party is required to act responsibly to the organization and its stakeholders.
- Fairness - All decisions taken, processes used, and their implementation will not be allowed to create unfair advantage to any one particular party.
Architecture Board Role
- The Architecture Board oversees implementation of the governance strategy.
- It should be representative of all the key stakeholders in the architecture.
Common Failure Pattern
- A common failure pattern is to establish an Architecture board that believes it maintains decision rights about the target architecture, change to the architecture, relief, and enforcement.
- Decision rights about the target architecture, relief, and enforcement are always vested in the architecture’s stakeholders.
- An Architecture Board owns process, and a recommendation regarding completeness and confidence in the work that led to the Target Architecture.
Architecture Board Responsibilities
- Providing the basis for all decision-making with regard to the architectures
- Consistency between sub-architectures
- Establishing targets for re-use of components
- Enforcement of Architecture Compliance
- Supporting a visible escalation capability for out-of-bounds decisions
Responsibilities from an Operational Perspective
- All aspects of monitoring and control of the Architecture Contract
- Meeting on a regular basis
- Ensuring the effective and consistent management and implementation of the architectures
- Resolving ambiguities, issues, or conflicts that have been escalated
- Providing advice, guidance, and information
- Ensuring compliance with the architectures, and granting dispensations that are in keeping with the technology strategy and objectives
Responsibilities from a Governance Perspective
- The production of usable governance material and activities
- Providing a mechanism for the formal acceptance and approval of architecture through consensus and authorized publication
- Providing a fundamental control mechanism for ensuring the effective implementation of the architecture
- Identifying divergence from the architecture and planning activities for realignment through dispensations or policy updates
Architecture Contracts
Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture
A Governed Approach to Architecture Contracts Ensures
- A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities
- Adherence to the principles, standards, and requirements of the existing or developing architectures
- Identification of risks in all aspects of the architecture(s)
- A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
Architecture Contracts and the ADM
- The Statement of Architecture Work in Phase A is effectively an Architecture Contract.
- Architecture Domains may be contracted out.
- The implementation of the EA may be contracted out at the end of Phase F/beginning of Phase G.
Architecture Compliance
Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of Architecture Governance.
There are usually two complementary processes:
- The Architecture function will be required to prepare a series of Project Architectures; i…, project-specific views of the Enterprise Architecture that illustrate how the Enterprise Architecture impacts on the major projects within the organization (see ADM Phases A to F)
- The Enterprise and IT Governance functions will define a formal Architecture Compliance review for reviewing the compliance of all projects to the Enterprise Architecture
The Need for Architecture Compliance Reviews
- Catch errors in the project architecture early
- Ensure the application of best practices to architecture work
- Provide an overview of the compliance to mandated standards
- Identify where the standards themselves may require modification
- Identify services that are currently application-specific but might be provided as part of the enterprise infrastructure
- Communicate to management the status of readiness of the project
- Identify and communicate significant architectural gaps to product and service providers
Concepts and Definitions
- Stakeholder
- Concern
- Architecture View
- Architecture Viewpoint
Stakeholders
Stakeholders are individuals, teams, organizations, or classes thereof, having an interest in a system. They are people who have key roles in, or concerns about, the system; for example, users, developers, etc.
Concerns
Concerns are interests in a system relevant to one or more of its stakeholders. They may pertain to any aspect of the system’s functioning, development, or operation, including performance, reliability, security, distribution, and evolvability, and may determine acceptability of the system
Architecture View
An Architecture View is a representation of a system from the perspective of a related set of concerns.
- An architect creates architecture models. An architecture view consists of parts of these, chosen to show stakeholders that their concerns are being met.
Architecture Viewpoint
- An Architecture Viewpoint defines the perspective from which an architecture view is taken.
- It defines how to construct and use an architecture view, the information needed, the modeling techniques for expressing and analyzing it, and a rationale for these choices (e.g., by describing the purpose and intended audience of the view).
Building Block Characteristics
- A package of functionality defined to meet the business needs across an organization.
- Normally has a type that corresponds to the metamodel (such as actor, business service, application, or data entity).
- Has a defined boundary and is generally recognizable as “a thing” by domain experts.
- May interoperate with other, inter-dependent building blocks.
Building Blocks
Systems are built from collections of building blocks.
They can be defined at many levels of detail:
- Groupings at the fundamental functional level capturing architecture requirements are known as Architecture Building Blocks (ABBs)
- Real products that can be procured or specific custom developments are known as Solution Building Blocks (SBBs)
Building Blocks and the ADM: Phase A
- The specification of building blocks using the ADM is an evolutionary and iterative process.
- In Phase A we start with abstract entities
Building Blocks and the ADM: Phases B, C, D
Building blocks within the Business, Data, Applications and Technology Architectures are evolved to a common pattern of steps
Phases B, C, D — Step 3: Develop Target Architecture Description
- Develop view of required building blocks through the creation of catalogs, matrices, and diagrams of the architecture
- Fully document each building block
- Document rationale for building block decisions in architecture document
- Identify the impacted building blocks, checking against a library of building blocks within the Architecture Repository and re-using where appropriate
- Where necessary, define new building blocks
- Select standards for each building block, re-using as much as possible from reference models selected from the Architecture Continuum
- Document final mapping of the building blocks to the Architecture Landscape
- From selected building blocks, identify those that might be re-used, and publish as standards or reference models via the Architecture Repository
Phases B, C, D - Step 4: Perform Gap Analysis
- Identify building blocks carried over
- Identify eliminated building blocks
- Identify new building blocks
- Identify gaps and determine realization approach (e.g., to be developed or to be procured)
Building Blocks and the ADM: Phase E
Associate building blocks with work packages that will address the gaps
The Role of Architecture Deliverables
- Architectural deliverables are the contractual or formal work products of an Architecture Project.
- The definition of deliverable provided by the TOGAF Standard is a baseline.
- It is thus a starting point for tailoring.
Architecture Deliverables
- Architecture Building Blocks
- Architecture Contract
- Architecture Definition Document
- Architecture Principles
- Architecture Repository
- Architecture Requirements
- Architecture Roadmap
- Architecture Vision
- Business Principles, Business Goals, and Business Drivers
- Capability Assessment
- Change Request
- Communications Plan
- Compliance Assessment
- Implementation and Migration Plan
- Implementation Governance Model
- Organizational Model for Enterprise Architecture
- Request for Architecture Work
- Requirements Impact Assessment
- Solution Building Blocks
- Statement of Architecture Work
- Tailored Architecture Framework
Request for Architecture Work
- Sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle
- Created as an output of the Preliminary Phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning
Statement of Architecture Work
- A deliverable output from Phase A
- A response to the Request for Architecture Work
- A plan for the architecture work defining the scope and approach to complete an architecture development cycle
Architecture Vision
- The Architecture Vision is created early on in the ADM cycle.
- It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.
- Providing an Architecture Vision supports stakeholder communication by providing a summary version of the full Architecture Definition.
Communications Plan
- Enterprise Architectures contain large volumes of complex and inter-dependent information.
- Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture.
- Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.
Business Principles, Business Goals, and Business Drivers
Business Principles, Business Goals, and Business Drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise.
Capability Assessment
Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise.
This Capability Assessment can be examined on several levels:
- What is the capability level of the enterprise as a whole?
- Where does the enterprise wish to increase or optimize capability?
- What are the architectural focus areas that will support the desired development of the enterprise?
- What is the capability or maturity level of the IT function within the enterprise?
- What is the capability and maturity of the architecture function within the enterprise?
Architecture Definition Document
- The deliverable container for the core architectural artifacts created during a project and for important related information
- Spans all architecture domains (Business, Data, Application, and Technology) and also examines all relevant states of the architecture (Baseline, Transition, and Target)
Architecture Requirements Specification
- Provides a set of quantitative statements that outline what an Implementation Project must do in order to comply with the architecture
- Will typically form a major component of an implementation contract or contract for more detailed Architecture Definition
Requirements Impact Assessment
- Throughout the ADM, new information is collected relating to an architecture; new facts may come to light that invalidate existing aspects of the architecture.
- A Requirements Impact Assessment assesses the current Architecture Requirements and specification to identify changes that should be made and the implications of those changes.
Architecture Roadmap
- Lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture
- Incrementally developed throughout Phases E and F, and informed by readily identifiable roadmap components from Phase B, C, and D within the ADM
Implementation and Migration Plan
- The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture.
- The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs.
- The Implementation and Migration Strategy identifying the approach to change is a key element of the Implementation and Migration Plan.
Implementation Governance Model
The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance.
Change Request
- In some circumstances, it is necessary for Implementation Projects to either deviate from the suggested architectural approach or to request scope extensions.
- Additionally, external factors - such as market factors, changes in business strategy, and new technology opportunities - may open up opportunities to extend and refine the architecture.
- In these circumstances, a Change Request may be submitted in order to kick-start a further cycle of architecture work.