TOGAF Notes

Key Points

1. The Integrated Information Infrastructure Model was created to address issue of Boundryless information flow.

   • The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM - in particular, the business applications and infrastructure applications parts - in order to provide help in addressing one of the key challenges facing the enterprise architect today: the need to design an integrated information infrastructure to enable Boundaryless Information Flow.
   • The Boundaryless Information Flow problem space is one that is shared by many customer members of The Open Group, and by many similar organizations worldwide. It is essentially the problem of getting information to the right people at the right time in a secure, reliable manner, in order to support the operations that are core to the extended enterprise.

   There are two levels of risk

   • Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions
   • Residual Level of Risk: Risk categorization after implementation of mitigating actions (if any)

2. Organizations today recognize that they need not abandon functional or departmental organization altogether. They can enable the right people to come together in cross-functional teams so that all the skills, knowledge, and expertise can be brought to bear on any specific problem or business opportunity.

3. The TOGAF TRM is an example of a Foundation/Fundamental Architecture. It is a fundamental architecture upon which other, more specific architectures can be based.

4. A Foundation Architecture consists of generic components, inter-relationships, principles, and guidelines that provide a foundation on which more specific architectures can be built. The TOGAF ADM is a process that would support specialization of such Foundation Architectures in order to create organization-specific models.

5. Business Transformation Readiness Assessment, used for evaluating and quantifying an organization's readiness to undergo change.

6. Practitioner and implementer are directed, and both are controlled by the stakeholder.

7. Phaes G ensures that implementation projects conform to the defined architecture.

8. The Requirements Management Phase stores requirements and manage their flow to relevant ADM Phases.

9. One of the objective of the preliminary phase is to define the framework and methodologies to be used.

10. According to TOGAF, when creating views for a particular architecture, the recommended step is to refer to the existing libraries for viewpoints, to identify for re-use.

11. Architecture Vision document contains a high-level description of the baseline and target architectures.

12. Enterprise Continuum is used to structure re-usable architecture and solution assets.

13. Request of Architecture Work is sent from the sponsoring organization to the architecture organization to trigger the start of an ADM cycle in phase A.

14. Architecture Governance is a practice by which enterprise architectures are controlled at an enterprise-wide level.

15. Reference Library is the component within the Architecture Repository holds best practice or template materials that can be used to construct architectures.

16. Compliance Assessment is used to govern the architecture throughout its implementation process,

17. A key objective of the Technology Architecture Phase is to define technology components into a set of technology platforms.

18. ADM should be adapted to suit the specific needs of the enterprise.

19. In Phase E of the TOGAF ADM are Gap Analysis results from earlier phases (B, C and D) consolidated.

20. Purpose of a business scenario is to help identify and understand the business requirements that an architecture must address.

21. When multiple server systems are being consolidated to a single system can be considered as Simplificaiton Change

22. One of the Purpose of Enterprise Architecture is optimise an enterprise into an environment that is responsive to business needs.

23. Architecture Principles are used to guide decision making within the enterprise.

24. Building Blocks become more implementation-specific in Phase E.

25. One of the objective of Phase A is to secure formal approval to proceed.

26. TOGAF defines an enterprise as any collection of organizations that has a common set of goals.

27. Rationale talks about the business benefits of an principle.

28. As per TOGAF, view is the representation of a system from the perspective of a related set of concerns.

29. TOGAF Architecture Governance Framework includes a model for governance including process, content and context.

30. Foundation, Common Systems, Industry, Organization-Specific (FCIO) is the right order

31. One of the purpose of Phase E is to define the initial implementation plans.

32. A building block's boundary and specification should be loosely coupled to its implementation; i.e., it should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.

33. An initial assessment of business transformation readiness occur in Phase A

34. If the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work.

35. Business Transformation Readiness Assessment is used for evaluating the status of an organization to undergo change?

36. The Architecture Development Method produces content to be stored in the Repository, which is classified according to the Enterprise Continuum.

37. Incremental change in phase H : A change driven by a requirement to derive additional value from the existing investment

38. A viewpoint is used as a template to create a view.

39. Application Architecture and Data Architecture may be developed in either sequence.

40. The Architecture Repository is used to store different classes of architectural output created by the ADM

41. Preliminary Phase of the ADM establishes a set of Principles.

42. Business scenarios figure most prominently in the phase A (Architecture Vision), when they are used to define relevant business requirements, and to build consensus with business management and other stakeholders.

43. Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract.

44. The Requiremetns Management phase manages the flow of requirements, storing them, and feeding them in and out of the relevant ADM phases.

45. Implicatons highlight the requirements for carrying out the principle

46. Select reference models, viewpoints and tools are the steps in Phases B, C, and D which occur before development of the baseline or target architectures.

47. In phase H, we conduct Enterprise Architecture performance reviews with service management Assess Change Requests and reporting to ensure that the expected value realization and Service-Level Agreement (SLA) expectations of the customers are met.

48. The Solutions Continuum represents the detailed specification and construction of the architectures at the corresponding levels of the Architecture Continuum. At each level, the Solutions Continuum is a population of the architecture with reference building blocks - either purchased products or built components - that represent a solution to the enterprise's business need expressed at that level.

49. Architecture Principle provides a foundation for making architecture and planning decisions, framing policies, procedures, and standards, and supporting resolution of contradictory situations.

50. Purpose of the Architecture Roadmap is to show progression of change from the Baseline Architecture to the Target Architecture.

51. Capability based planning focuses on achieving business outcomes rather than just technical deliverables.

52. In Phase E, the building blocks become implementation-specific.

53. Preparing architecture review reports is NOT done by Arch board, but by an Arch

54. Part IV: Architecture Content Framework contains a structured metamodel for architectural artifacts.

55. Foundation Architecture contains building blocks and their corresponding standards.

56. Statement of Architecture Work defines the scope and approach to complete an architecture project.

57. One of the goals of the Preliminary phase is to select and implement supporting tools and other infrastructure to support the architecture activity.

58. The TOGAF Integrated Information Infrastructure Reference Model (III-RM) — is a reference model that supports describing Common Systems Architecture in the Application

59. Re-architecting change is the change driven by a requirement to increase investment in order to create new value for exploitation.

60. One of the objective of Phase F is to ensure that the Implementation and Migration Plan is co-ordinated with the various management frameworks in use within the enterprise.

61. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository.

62. Implications: Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?"

63. The Technology Architecture that depicts the architecture practice's infrastructure requirements and deployment in support of the architecture applications and Enterprise Continuum.

64. The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.

65. Qualities of Principles (SURCC)

    • Understandable: the underlying tenets can be quickly grasped and understood by individuals throughout the organization
    • Robust: enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created
    • Complete: the principles cover every situation perceived
    • Consistent: strict adherence to one principle may require a loose interpretation of another principle
    • Stable: principles should be enduring, yet able to accommodate changes

66. An "architecture view" is a representation of a system from the perspective of a related set of concerns. It consists of one or more architecture models of the system.

67. The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must conform. Establishment of a Standards Information Base provides an unambiguous basis for Architecture Governance because:

    • The standards are easily accessible to projects and therefore the obligations of the project can be understood and planned for
    • Standards are stated in a clear and unambiguous manner, so that compliance can be objectively assessed

68. Patterns offer the promise of helping the architect to identify combinations of Architecture and/or Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past, and may provide the basis for effective solutions in the future.

69. “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 interrelationships, and the principles and guidelines governing their design

70. Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

71. The objectives of Phase A are to:

    • Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture.
    • Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.

72. The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture has two main elements:

    • Technical Reference Model (TRM) which provides a model and taxonomy of generic platform services
    • Standards Information Base (SIB) which provides a database of standards that can be used to define the particular services and other components of an organization-specific architecture that is derived from the TOGAF Foundation Architecture.

    About SIB

    The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must conform.

73. Change types:

    • Simplification change- reduce investment
    • Incremental change - additional value from existing investment
    • Re-architecting change - create new value for exploitation

74. Steps for phase B, C and D are

    • Select Reference Models, Viewpoints, and Tools
    • Develop Baseline Business Architecture Description
    • Develop Target Business Architecture Description
    • Perform Gap Analysis
    • Define Candidate Roadmap Components
    • Resolve Impacts Across the Architecture Landscape
    • Conduct Formal Stakeholder Review
    • Finalize the Business Architecture
    • Create the Architecture Definition Document

75. Architecture Governance Framework is the approach to ensure the effectiveness of an organization's architectures.

76. The technique known as gap analysis is widely used in the TOGAF Architecture Development Method (ADM) to validate an architecture that is being developed. The basic premise is to highlight a shortfall between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately omitted, accidentally left out, or not yet defined.

77. The goal of an architecture change management process is to ensure that the architecture achieves its original target business value.

78. ADM is the step-by-step approach to developing an Enterprise Architecture.

79. Architecture is a formal description of a system, or a detailed plan of the system at component level to guide its implementation

80. Rationale: Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.

81. Version 1.0 indicates a formally reviewed, detailed architecture

82. Capability-based planning: business planning technique that focuses on business outcomes.

83. View: A representation of a system from the perspective of a related set of concerns.

84. The Architecture Content Framework uses the following 3 categories to describe the type of architectural work product within the context of use:

    1. A deliverable
    2. An artifact
    3. A a building block

85. Implications: Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?". It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

86. Purpose of Architecture Compliance Review is to Identify key criteria for procurement activities (e.g., for inclusion in Commercial Off-The-Shelf (COTS) product RFI/RFP documents).

87. The Architecture Board is typically made responsible, and accountable, for achieving some or all of the following goals:

    • Providing the basis for all decision-making with regard to the architectures
    • Consistency between sub-architectures
    • Establishing targets for re-use of components
    • Flexibility of the Enterprise Architecture:
    • To meet changing business needs
    • To leverage 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

88. Version 0.1 indicates that a high-level outline of the architecture is in place.

89. Architecture Capability Framework: This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

90. An architecture view is a representation of a system from the perspective of a related set of concerns.

91. In Phase A the earliest building block definitions start as relatively abstract entities within the Architecture Vision.

92. The goals of an Architecture Compliance review include some or all of the following:

    • First and foremost, catch errors in the project architecture early, and thereby reduce the cost and risk of changes required later in the lifecycle. This in turn means that the overall project time is shortened, and that the business gets the bottom-line benefit of the architecture development faster.
    • Ensure the application of best practices to architecture work.
    • Provide an overview of the compliance of an architecture to mandated enterprise standards.
    • Identify where the standards themselves may require modification.

93. Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability.

94. The major information areas managed by a governance repository should contain the following types of information:

    • Reference Data (collateral from the organization's own repositories/Enterprise Continuum, including external data; e.g., COBIT, the IT4IT Reference Architecture): used for guidance and instruction during project implementation

    • This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves.

    • Process Status: all information regarding the state of any governance processes will be managed

    • Examples of this include outstanding compliance requests, dispensation requests, and compliance assessments investigations.

    • Audit Information: this will record all completed governance process actions and will be used to support:

    • Key decisions and responsible personnel for any architecture project that has been sanctioned by the governance process

    • A reference for future architectural and supporting process developments, guidance, and precedence

95. Foundation Architecture = Generic Building Blocks

96. Business Architecture is done before data, application and techology as it provides prerequisite knowledge for undertaking architecture work in the other domains.

97. The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.

    TOGAF Document Categorization Model

    TOGAF document categorization model exists to structure the release management of the TOGAF specification. It is NOT intended to serve as an implementation guide for practitioners. Within the model, the content of the TOGAF document is categorized according to the following 4 categories:

    • TOGAF Core consists of the fundamental concepts that form the essence of TOGAF.

    • TOGAF Mandated consists of the normative parts of the TOGAF specification. These elements of TOGAF are central to its usage and without them the framework would not be recognizably TOGAF. Strong consideration must be given to these elements when applying TOGAF.

    • TOGAF Recommended consists of a pool of resources that are specifically referenced in TOGAF as ways in which the TOGAF Core and Mandated processes can be accomplished (e.g., the SEI Architecture Trade-Off Analysis Method or business scenarios).

    • TOGAF Supporting consists of additional resources that are not referenced in the other three TOGAF categories itself but provide valuable assistance.

98. The business imperatives behind the Enterprise Architecture work drive the requirements and performance metrics for the architecture work.

99. Developing Arch Capability: Establishing a sustainable architecture practice within an organization can be achieved by adhering to the same approach that is used to establish any other capability - such as a business process management capability - within an organization. The ADM is an ideal method to be used to architect and govern the implementation of such a capability. Applying the ADM with the specific Architecture Vision to establish an architecture practice within the organization would achieve this objective. This shouldn't be seen as a phase of an architecture project, or a one-off project, but rather as an ongoing practice that provides the context, environment, and resources to govern and enable architecture delivery to the organization.

100. The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.

101. III-RM is fundamentally an Application Architecture reference model

102. The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.

103. Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract.

104. Requirements for Architecture Work: The business imperatives behind the enterprise architecture work drive the requirements and performance metrics for the architecture work. They should be sufficiently clear so that this phase may scope the business outcomes and resource requirements, and define the outline enterprise business information requirements and associated strategies of the enterprise architecture work to be done. For example, these may include:

     • Business requirements
     • Cultural aspirations
     • Organization intents
     • Strategic intent
     • Forecast financial requirements

105. Risk is pervasive in any Enterprise Architecture activity and is present in all phases within the Architecture Development Method (ADM)

106. Capability-based Planning: a business planning technique that focuses on business outcomes.

107. Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an architectural vision (in Phase A) that responds to those requirements.

108. Ensuring the compliance of individual projects with the enterprise architecture is an essential aspect of architecture governance.

109. One of the purpose of an Architecture Compliance Review is to communicate the technical readiness of the project.

110. Consider 3 classes of building blocks:

     • Re-usable building blocks, such as legacy items
     • Building blocks to be the subject of development, such as new applications
     • Building blocks to be the subject of purchase; i.e., Commercial Off-The-Shelf (COTS) applications

111. Deliverables are specified as contractual outputs from a project, whereas artifacts are not.

112. TOGAF must be adapted to satisfy organization specific requirements.

113. The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services; this includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

114. An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

115. In phase F the Transition Architectures is finalized.

116. The normal approach to Target Architecture development is top-down. In the Baseline Description, however, the analysis of the current state often has to be done bottom-up.

117. Phase E is the first phase which is directly concerned with the structure of how the Target Architecture will be implemented.

118. Actions arising from the Business Transformation Readiness Assessment technique should be incorporated in the Implementation and Migration Plan

119. Objective of Phase E is to generate the initial complete version of the Architecture Roadmap.

120. Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.

121. The objectives of Phase G are to:

     1. Ensure conformance with the Target Architecture by implementation projects
     2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests.

122. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things).

123. Value streams provide valuable stakeholder context into why the organization needs business capabilities.

124. The objectives of the Preliminary Phase are to:

     • Determine the Architecture Capability desired by the organization:
     • Review the organizational context for conducting Enterprise Architecture
     • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
     • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
     • Establish Capability Maturity target
     • Establish the Architecture Capability:
     • Define and establish the Organizational Model for Enterprise Architecture
     • Define and establish the detailed process and resources for Architecture Governance
     • Select and implement tools that support the Architecture Capability
     • Define the Architecture Principles.

125. The TOGAF Library is a reference library containing guidelines, templates, patterns, and other forms of reference material to accelerate the creation of new architectures for the enterprise. Library resources are organized into 4 sections:

     • Foundation Documents
     • Generic Guidance and Techniques
     • Industry-Specific Guidance and Techniques
     • Organization-Specific Guidance and Techniques

126. The business capability map found or developed in the Architecture Vision phase provides a self-contained view of the business that is independent of the current organizational structure, business processes, information systems and applications.

127. Mapping in business
     • Capability Map exposes what a business does
     • Value stream Map exposes how it delivers value to specific stakeholders
     • Organization Map identities the business units or third parties that possess or use those capabilities and which participate in the value streams.
128. Check classes of arch engagement here
129. Arch Development approaches

Dev approached for Architecture

2 approaches can be adopted within the ADM for the development of architectures:

• Baseline First: in this style, an assessment of the baseline landscape is used to identify problem areas and improvement opportunities. This process is most suitable when the baseline is complex, not clearly understood, or agreed upon. This approach is common where organizational units have had a high degree of autonomy.

• Target First: in this style, the target solution is elaborated in detail and then mapped back to the baseline, in order to identify change activity. This process is suitable when a target state is agreed at a high level and where the enterprise wishes to effectively transition to the target model.

1. The Business Value Assessment is used to identify the benefits, costs, and risks of executing the architecture project, which will help in determining if the proposed architecture can produce sufficient value to warrant the attendant risks. This is directly addressing the concerns raised by the senior management.
2. The business scenario technique is a method for deriving business requirements that address business concerns and issues. It involves understanding and documenting the business context, events triggering the scenario, and the desired outcomes. This approach would help to identify and address the concerns of the stakeholders, and to clarify the requirements for the new system.

Shortcuts

• SSC: Stragegy, Segment and Capability arch (in Arch Landscape)
• FICO: Foundation, Industry, Common Systems, and Org-specific arch (in Reference Arch)
• BDAT: Business, Data, Application and Technology Phase (For ADM)
• BDAT: Breadth, Depth, Architecture Domain, Time Period (For scope of architecture)
• SIR: Simplification change, Incremental change, Re-architecting change (in change manamgement)
• NSIR: Name, Statement, Implication, Rationale (for Architecture Principle)
• ACF: Architecture Capability Framework and Architecture Content Framework
• SURCC: Stable, Understandable, Robust, Complete, Consistent (5 criterias of principles)
• BTRA: Business Transformation Readiness Assessment

---

Was this page helpful?

Yes No