Chapter 8 ADM Guidelines and Techniques
A good business scenario represents a significant business need or problem and enables vendors to understand the value of a solution to the customer. A good business scenario is also “SMART”:
- Specific, by defining what needs to be done
- Measurable, through clear metrics for success
- Actionable, by clearly segmenting the problem and providing the basis for a solution
- Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints
- Time-bound, in that there is a clear statement of when the opportunity expires.
- Gap Analysis: A key step in validating an architecture is to consider what may have been forgotten. The architecture must support all the essential information processing needs of the organization. The most critical source of gaps that should be considered is stakeholder concerns that have not been addressed in prior architectural work.
The determination of interoperability occurs throughout the ADM:
- In Phase A: Architecture Vision, the nature and security considerations of information and service exchanges are found using business scenarios.
- In Phase B: Business Architecture, information and service exchanges are defined in business terms.
- In Phase C: Data Architecture, the content of information exchanges is detailed using the corporate data and/or information exchange model.
- In Phase C: Application Architecture, the ways that applications are to share information and services are specified.
- In Phase D: Technology Architecture, appropriate technical mechanisms to permit information and service exchanges are specified.
- In Phase E: Opportunities & Solutions, actual solutions are selected.
- In Phase F: Migration Planning, interoperability is implemented logically.
Business Transformation Readiness Assessment: The recommended activities are:
- Determine the readiness factors that will impact the organization
- Present the readiness factors using maturity models
- Assess the readiness factors, and determine the readiness factor ratings
- Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
- Document the findings into the Capability Assessment and later incorporate the actions into the Implementation and Migration Plan in Phases E and F
Risk Management: is a technique used to mitigate risk when implementing an architecture project. There are two levels of risk that should be considered:
- Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions. Residual Level of Risk: Risk categorization after implementation of mitigating actions.
The recommended process for managing risk consists of the following activities:
- Risk classification
- Risk identification
- Initial risk assessment
- Risk mitigation and residual risk assessment
- Risk monitoring
- Capability-Based Planning: Capability-Based Planning is a business planning technique that focuses on business outcomes. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. It accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities. Often the need for these capabilities is discovered and refined using business scenarios.
Chapter 9 Architecture Governance
Architecture Governance includes the following:
- Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
- Implementing a system to ensure compliance with internal and external standards and regulatory obligations
- Establishing processes that support effective management of the above processes within agreed parameters
- Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization
What is Governance? Governance is about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about effective usage of resources to ensure sustainability of an organization’s strategic objectives. The following characteristics, adapted from Corporate Governance (Naidoo, 2002), are used in the TOGAF standard to highlight both the value and necessity for governance as an approach to be adopted within organizations and their dealings with all involved parties:
- 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 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 party.
Architecture Governance covers the management and control of all aspects of the development and evolution of architectures. It needs to be supported by an Architecture Governance Framework which assists in identifying effective processes so that the business responsibilities associated with Architecture Governance can be elucidated, communicated, and managed effectively.
Key Architecture Governance Processes The following are the key processes:
- 1. Policy Management and Take-On
- 2. Compliance
- 3. Dispensation
- 4. Monitoring and Reporting
- 5. Business Control
- 6. Environment Management
Architecture Governance is beneficial because it:
- Links IT processes, resources, and information to organizational strategies and objectives
- Integrates and institutionalizes IT best practices
- Aligns with industry frameworks such as COBIT (planning and organizing, acquiring and implementing, delivering and supporting, and monitoring IT performance)
- Enables the organization to take full advantage of its information, infrastructure, and hardware/software assets
- Protects the underlying digital assets of the organization
- Supports regulatory and best practice requirements such as auditability, security, responsibility, and accountability
What are the Key Success Factors when establishing Architecture Governance? It is important to consider the following to ensure a successful approach to Architecture Governance, and effective management of the Architecture Contract:
- Establishment and operation of best practices for submission, adoption, re-use, reporting, and retirement of architecture policies, procedures, roles, skills, organizational structures, and support services
- Establishment of correct organizational responsibilities and structures to support Architecture Governance processes and reporting requirements
- Integration of tools and processes to facilitate take-up of processes (both procedural and cultural)
- Management of criteria for control of Architecture Governance processes, dispensations, compliance assessments, Service Level Agreements (SLAs), and Operational Level Agreements (OLAs)
- Meeting internal and external requirements for effectiveness, efficiency, confidentiality, integrity, availability, compliance, and reliability of Architecture Governance-related information, services, and processes
The Architecture Board is typically made responsible, and accountable, for achieving some or all the following goals:
- Providing the basis for all decision-making about changes to the architectures
- Consistency between sub-architectures
- Establishing targets for re-use of components
- Flexibility of enterprise architecture; to meet business needs and utilize new technologies
- Enforcement of Architecture Compliance
- Improving the maturity level of architecture discipline within the organization
- Ensuring that the discipline of architecture-based development is adopted
- Supporting a visible escalation capability for out-of-bounds decisions
The Meaning of Architecture Compliance:
Chapter 10 Views, Viewpoints, and Stakeholders
Chapter 3: Core Concepts
- What is the Enterprise Continuum?
The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.
The Enterprise Continuum and the Architecture Repository The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. [Source: TOGAF 9 Part V: Enterprise Continuum and Tools]
- What is the Architecture Repository?
Architecture Repository is used to store different classes of architectural output at different levels of abstraction
The major components within an Architecture Repository are as follows:
- The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
- The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
- The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives
- The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
- The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged to accelerate the creation of new architectures for the enterprise.
- The Governance Log provides a record of governance activity across the enterprise. abstraction to suit different architecture objectives
How to establish and operate an enterprise architecture capability?
The benefits of Architecture Governance include:
- Increased transparency of accountability, and informed delegation of authority
- Controlled risk management
- Protection of the existing asset base through maximizing re-use of existing architectural components
- Proactive control, monitoring, and management mechanisms
- Process, concept, and component re-use across all organizational business units
- Value creation through monitoring, measuring, evaluation, and feedback
- Increased visibility supporting internal processes and external parties’ requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
- Greater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise – studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
Integrates with existing processes and methodologies and complements functionality by adding control capabilities
- How to use the TOGAF framework with other frameworks?
Why is the TOGAF standard becoming so popular in the industry? One key reason is that architects can use the TOGAF ADM in conjunction with any of the popular frameworks. The TOGAF ADM is framework-agnostic and helps IT architects fill in the framework they might already have in use.
Chapter 4: Key Terminology
Architecture: Architecture has two meanings depending upon its contextual usage:
- A formal description of a system, or a detailed plan of the system at component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
- Architecture Principles: A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
- Architecture Vision: A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.
Baseline: A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.