Chapter 8 ADM Guidelines and Techniques

• Architecture Principles: are a set of general rules and guidelines for the architecture being developed. They are intended to be enduring and seldom amended and inform and support the way in which an organization sets about fulfilling its mission. Often, they are one element of a structured set of ideas that collectively define and guide the organization, from values through to actions and results.
• Enterprise principles provide a basis for decision-making throughout an enterprise and dictate how the organization fulfills its mission. Such principles are commonly used as a means of harmonizing decision-making. They are a key element in a successful Architecture Governance strategy. Within the broad domain of enterprise principles, it is common to have subsidiary principles within a business or organizational unit; for example, IT, HR, domestic operations, or overseas operations.
• Architecture principles are a set of principles that relate to architecture work. They reflect consensus across the enterprise, and embody the spirit of the enterprise architecture. Architecture principles govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture.
• The TOGAF Template for Defining Architecture Principles:
  • Name
  • Statement
  • Rationale
  • Implications
• What Makes a Good Architecture Principle?
  • Understandability
  • Robustness
  • Completeness
  • Consistency
  • Stability
• Business Scenarios
  • What is a Business Scenario? Business scenarios are a technique used to help identify and understand the business requirements that an architecture must address. A business scenario describes:
    • A business process, application, or set of applications
    • The business and technology environment
    • The people and computing components (“actors”) who execute the scenario
    • The desired outcome of proper execution
  • The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture. The generic business scenario process is as follows:
    • Identify, document, and rank the problem that is driving the project
    • Document, as high-level architecture models, the business and technical environments where the problem situation is occurring
    • Identify and document desired objectives; the results of handling the problems successfully.
    • Identify human actors and their place in the business model, the human participants, and their roles.
    • Identify computer actors and their place in the technology model, the computing elements, and their roles
    • Identify and document roles, responsibilities, and measures of success per actor, the required scripts per actor, and the desired results of handling the situation properly.
    • Check for fitness-for-purpose of inspiring subsequent architecture work and refine only if necessary.

      

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

• A system is a collection of components organized to accomplish a specific function or set of functions. “The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest
• Stakeholders are people who have key roles in, or concerns about, the system; for example, users, developers, etc. Stakeholders can be individuals, teams, organizations, etc.
• Concerns are key interests that are crucially important to stakeholders and determine the acceptability of the system.
• A view is a representation of a system from the perspective of a related set of concerns. A view is what you see (or what a stakeholder sees). An architect creates architecture models. A view consists of parts of these, chosen to show stakeholders that their concerns are being met.
• A viewpoint defines the perspective from which a view is taken. It defines how to construct and use a 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). The relationship between viewpoint and view is analogous to that of a template and an instance of the completed template. In constructing an enterprise architecture, an architect first selects the viewpoints (templates), then constructs a set of corresponding views (instances).
• 
• The architect has a responsibility for ensuring:
  • The completeness of the architecture: — Does it address all the concerns of its stakeholders?
  • The integrity of the architecture: — Can the views be connected to each other? — Can the conflicting concerns be reconciled? — What trade-offs have been made (e.g., between security and performance)?
• Recommended Steps: The following are the recommended steps to create the required views for a architecture:
  • 1. Refer to any existing libraries of viewpoints (note that TOGAF 9 includes a set of architecture viewpoints).
  • 2. Select key stakeholders.
  • 3. Analyze their concerns and document them.
  • 4. Select appropriate viewpoints (based on the stakeholders and their concerns).
  • 5. Generate views of the system using the selected viewpoints as templates.