Saturday, 30 January 2016

My TOGAF 9.1 Study notes

To anyone studying for their TOGAF 9 exams who happens to drop by, this page is just my collection of:
sites I found,
notes I made,
excerpts I copied,
abbreviations I made,
key text I highlighted,
acronyms I came up with
... anything to help me remember the sheer volume of (in my view - pointless) variances and nuances of "According To TOGAF " for the multi-choice Part 1 exam.

Part 2 - Scenarios are relatively easy in my view, because you are applying the process and principles but the Part One which has questions which for a couple I cannot find any DIRECT ANSWER (i.e. the answer is an extrapolation of knowledge) either in the TOGAF documentation or from Google searches ... that's an entirely different thing!  I got very frustrated trying to learn this stuff!

e.g. How do you arrive at answer D for this question?

Which of the following correctly defines the Organisation category in the Architecture Content Framework?

  • a) Organisation, Location and Capabilities
  • b) Actor, Location, Role and Capabilities
  • c) Requirements, Actor and Function
  • d) Location, Actor, Role, and Organisation
  • e) Actor, Location and Structure
Option D. See TOGAF: Content Metamodel. Organisation, Location, Actor and Role form the Organisation category.

... eventually ... knowing the answer ... I was able to find it buried in this diagram


... nor can I see anywhere that clearly describes: the reasons for establishing an Architecture Board
 i.e.
TOGAF states that establishing and operating an Architecture Board is more than offset by the savings accrued from preventing one off solutions and unconstrained development. Which of the following answers does TOGAF not state as a reason for establishing an Architecture Board?

  • a) Higher risk
  • b) High cost of operation and support
  • c) High costs of development
  • d) Lower quality
  • e) Better understanding of the business and their requirements
 Double negatives are also common:

Which of the following is incorrect when describing Architecture Deliverables?

  • a) Architecture Deliverables contain Artifacts correct
  • b) Artifacts within deliverables may include Catalogs, Matrices and Diagrams correct
  • c) An Architecture Definition Document is an architectural deliverable correct
  • d) Architecture Deliverables may be composed of more than one artifact correct
  • e) Deliverables cannot be used as building blocks ... cannot is incorrect so deliverables CAN be used as building blocks
Logically Option E. as options A-D are definitely valid.

Then there are subtle questions like:
2 - Which one of the following is not a characteristic of a building block?
Choose one of the following answers
You skim thru the question and they are ALL correct !
... until you realise B uses the word cannot not can

Anyhow ... on to my scruffy notes ... just in case they help anyone else with their TOGAF study

Sites

An absolutely EXCELLENT collection of many (most) of the likely questions for Part 1 all in the one location.
http://wiki.glitchdata.com/index.php?title=TOGAF9:_Part_1_-_Sample_Questions#Under_Preparation

Part 1 & 2 simulation exams
http://theopenarch.com/



Jottings/Notes

ADM

Revise Prelim phase outputs -
Revise phase A steps
Revise phase A outputs
Revise phase B steps B=Business of BDAT
  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
    • Target Business Architecture, Version 1.0 (detailed), including:
      • Organization structure - identifying business locations and relating them to organizational units
      • Business goals and objectives - for the enterprise and each organizational unit
      • Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
      • Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
      • Business processes, including measures and deliverables
      • Business roles, including development and modification of skills requirements
      • Business data model
      • Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Business Architecture requirements as:
    • Gap analysis results
    • Technical requirements - identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (for example, guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework)
    • Updated business requirements
  • Business Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
Revise phase C - Data steps - C=Cata a.k.a. Data of BDAT
Revise phase C - Data outputs
  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Data Architecture, Version 1.0, if appropriate
    • Target Data Architecture, Version 1.0
      • Business data model
      • Logical data model
      • Data management process models
      • Data Entity/Business Function matrix
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Data Architecture requirements as:
    • Gap analysis results
    • Data interoperability requirements
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture about to be designed
    • Updated business requirements, if appropriate
    • Updated application requirements, if appropriate
  • Data Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
Revise phase C - Application steps - C=CAta a.k.a. Application of BDAT
Revise phase C - Application outputs
  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Application Architecture, Version 1.0, if appropriate
    • Target Application Architecture, Version 1.0
      • Process systems model
      • Place systems model
      • Time systems model
      • People systems model
    • Views corresponding to the selected viewpoints, addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Application Architecture requirements as:
    • Gap analysis results
    • Applications interoperability requirements
    • Relevant technical requirements that will apply to this evolution of the architecture development cycle
    • Constraints on the Technology Architecture about to be designed
    • Updated business requirements, if appropriate
    • Updated data requirements, if appropriate
  • Application Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
Revise phase D steps - D=Digital Technology of BDAT
Revise phase D outputs
  • Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Target Technology Architecture, Version 1.0 (detailed), including:
      • Technology Components and their relationships to information systems
      • Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology "stack"
      • Environments and locations - a grouping of the required technology into computing environments (e.g., development, production)
      • Expected processing load and distribution of load across technology components
      • Physical (network) communications
      • Hardware and network specifications
    • Baseline Technology Architecture, Version 1.0 (detailed), if appropriate
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including such Technology Architecture requirements as:
    • Gap analysis results
    • Requirements output from Phases B and C
    • Updated technology requirements
  • Technology Architecture components of an Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
Revise phase E steps E=Establish (Opportuniteee to Creeeate/Deeetermine/Identeeefy/Reeeview/Reeefine/Readieeeness)
Revise phase E outputs
  • Refined and updated version of the Architecture Vision phase deliverables, where applicable, including:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 updated if necessary
    • Target Business Architecture, Version 1.0 updated if necessary
    • Baseline Data Architecture, Version 1.0 updated if necessary
    • Target Data Architecture, Version 1.0 updated if necessary
    • Baseline Application Architecture, Version 1.0 updated if necessary
    • Target Application Architecture, Version 1.0 updated if necessary
    • Baseline Technology Architecture, Version 1.0 updated if necessary
    • Target Technology Architecture, Version 1.0 updated if necessary
    • Transition Architecture, number and scope as necessary
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Consolidated Gaps, Solutions, and Dependencies Assessment
  • Capability Assessments, including:
    • Business Capability Assessment
    • IT Capability Assessment
  • Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap), including:
    • Work package portfolio:
      • Work package description (name, description, objectives)
      • Functional requirements
      • Dependencies
      • Relationship to opportunity
      • Relationship to Architecture Definition Document and Architecture Requirements Specification
      • Relationship to any capability increments
      • Business value
      • Implementation Factor Assessment and Deduction Matrix
      • Impact
    • Identification of Transition Architectures, if any, including:
      • Relationship to Architecture Definition Document
    • Implementation recommendations:
      • Criteria measures of effectiveness
      • Risks and issues
      • Solution Building Blocks (SBBs)
  • Implementation and Migration Plan, Version 0.1, including:
    • Implementation and Migration Strategy
Revise phase F steps F=Finalise (a.k.a. Assign/Complete/Confirm/Generate/Prioritise/Transition)
Revise phase F outputs
Revise phase G steps G=Govern
Revise phase G outputs
  • Architecture Contract (signed) (see Part VII, 49. Architecture Contracts)
  • Compliance Assessments (see Part IV, 36.2.13 Compliance Assessment)
  • Change Requests (see Part IV, 36.2.11 Change Request)
  • Architecture-compliant solutions deployed including:
    • The architecture-compliant implemented system
      Note:
      The implemented system is actually an output of the development process. However, given the importance of this output, it is stated here as an output of the ADM. The direct involvement of architecture staff in implementation will vary according to organizational policy, as described in Part VII, 50. Architecture Governance.
    • Populated Architecture Repository
    • Architecture compliance recommendations and dispensations
    • Recommendations on service delivery requirements
    • Recommendations on performance metrics
    • Service Level Agreements (SLAs)
    • Architecture Vision, updated post-implementation
    • Architecture Definition Document, updated post-implementation
    • Business and IT operating models for the implemented solution
Revise phase H steps

Various parts of TOGAF

Implementation Governance Model - how the Transition Architecture that implements the architecture will be governed through implementation. Typical contents of an Implementation Governance Model are:
  • Governance processes
  • Governance organization structure
  • Governance roles and responsibilities
  • Governance checkpoints and success/failure criteria
Architecture Repository - made up of:
  • Metamodel, Capability, Landscape, (Ref)Library, (Gov)Log, SIB  
    MetaCap     (pause) Lanscape,Library,Log n' SIB
TOGAF document categorisation model - CRMS - core, mandated, recommended, supporting 

Technology Architecture - scope

Parts/Structure of Architecture Governance - established in Prelim, fulfilled in G & H https://prezi.com/c_q8ow3nfuwo/togaf-architecture-governance/
PCRF or ProcConRepoFlow - Process, Content, Repository, process Flow control 
 
Concern vs Requirement - concern=key interests crucially important to stakeholders, determine acceptability of the system. requirement=statement of need that must be met by a particular architecture

What to ABB's "do" - 
  1. describe required capability of a single aspect of the overall model
  2. capture architecture requirements
Capability Assessment

TRM - what is it - provides a model and taxonomy of generic platform services
has two main components:
  1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an information system
  2. A TRM graphic, providing a visual representation of the taxonomy, to aid understanding
TRM services
    • Data Interchange
    • Data Management
    • Graphics and Imaging
    • International Operation
    • Location and Directory
    • Network 
    • Operating System
    • Software Engineering
    • Transaction Processing
    • User Interface
    • Security
    • System and Network Management 
  III-RM - what is it - a subset of the TRM in terms of overall scope, but expands certain parts of the TRM - in particular, the business applications and infrastructure applications parts to help in design of an Integrated Information Infrastructure to enable Boundaryless Information Flow.
The core components of the III-RM are:
  • Business Applications
    • Brokering 
    • Information Provider
    • Information Consumer 
  • Infrastructure Applications
    • Development Tools
    • Management Utilities 
  • Application Platform
  • Interfaces used between the components
  • Qualities the Application Software and Application Platform must adhere to

Value Chain - phase A - high-level view of an enterprise and how it interacts with the outside world, focuses on presentational impact so all participants understand the high-level functional and organizational context of the architecture engagement
Transition states

Architecture Contracts - Joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. 
Architecture Contracts may occur at various stages of the Architecture Development Method:
  • Statement of Architecture Work created in Phase A 
  • The development of one or more architecture domains (BDAT) will normally be governed by an Architecture Contract
  • At the beginning of Phase G between the architecture function and the function responsible for implementing the enterprise architecture (In larger-scale implementations, there may well be one Architecture Contract per implementation team)
  • At the end of Phase G between the architecting function and the business users who will be building and deploying application systems
They provide:
  • continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities
  • Adherence to principles, standards, and requirements of the existing or developing architectures
  • Identification of risks in all aspects of the development and implementation of the architecture(s)
  • accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
  • formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body
The 7 parts of TOGAF - I, A, GT, Cont - EC n' T, RM n' Cap - 1.Intro, 2.ADM, 3.AG&T, ACF(content), Ent Contin, RefMod, ACF(capability)  
(learn as a rhythm: IA (pause) GTcont (pause) EC'n'T (pause) RM'n'Cap)
ADM Guidelines and Techniques - Part III
  • Iteration - has 4 common sub-iterations CDTG
    1. Prelim~A & Prelim~H (Context/Capability)
    2. B~F and intra_B~D (Development)
    3. E~F (Transition)
    4. G~H (Governance)
  • Application - will occur
    •      at Strategic, Segment & Capability levels SSC/BDTR
    •      across Subject areas (Breadth), to varying Detail (Depth), for duration's (Time) dependent on Breadth & Depth of the described architecture. Accuracy has a bell-curve depending on Recency, where an architecture decreases in accuracy if not actively maintained.
  • Security
    • Often treated as a separate architecture domain within the EA while needing to be fully integrated in it.
    • has its own discrete methodology, views and viewpoints.
    • Security considerations have an impact on Phases A to H
  • Governing SOA's - Enterprise architecture provides frameworks, tools, and techniques to assist organizations with the development and maintenance of their SOAs
  • Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support.
    • Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission.
    • Architecture principles govern the architecture process
    • Structure
      • Name - represent the essence of the rule and be easy to remember
      • Statement - succinctly and unambiguously communicate the fundamental rule.
      • Rationale - highlight the business benefits of adhering to the principle
      • Implications - Should highlight both business and IT requirements for carrying out the principle - in terms of resources, costs, and activities/tasks
  • Stakeholder Management - Support from the more powerful stakeholders will help the engagement win more resource, thus making the architecture engagement more likely to succeed.
  • Patterns - Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
  • Business Scenarios - 
  • Gap Analysis
  • Migration Planning Techniques
  • Interoperability Requirements
  • Business Transformation Readiness Assessment
  • Risk Management
  • Capability-Based Planning
Content vs Capability frameworks - 
Techniques for Architecture Development
  • Architecture Principles
  • Stakeholder Management
  • Architecture Patterns
  • Business Scenarios
  • Gap Analysis
  • Migration Planning Techniques
  • Interoperability Requirements
  • Business Transformation Readiness Assessment
  • Risk Management
  • Capability-Based Planning
  • NO CHANGE MANAGEMENT !
 Boundaryless Information Flow - access to integrated information to support business process improvements - multiple sources of information securely delivered in the right context, when/where-ever needed
The key point of the ADM cycle is to focus on what creates value to the
enterprise, and to select horizontal and vertical scope
Incorrect reasons for limiting architecture scope
  • inflexibility of the baseline IT technical architecture
  •  
The relationship between the Architecture Continuum and
the Solutions Continuum is one of Guidance, direction and support GDS
Definition of the Organisation category in the AContF - LARO
Location Actor Role Organisation
Architecture Continuum consists of architecture types - FICO
Foundation, Industry, Common, Organisation


Compliance
  • Irrelevant - Implementation has no features in common with specification
  • Consistent - implementation has some features in common with the spec and they conform to the spec, BUT,
    • some parts of the spec are NOT implemented and
    • there are parts of the implementation NOT COVERED by the spec. (not all but also extras)
  • Compliant - some features of spec are implemented and conform to the spec BUT,
    • some parts of the spec are NOT implemented
    • nothing apart from the spec is implemented (Not all and nothing extra)
  • Conformant - all features of spec implemented in conformance BUT,
    • extra features don't conform
  • Fully conformant - everything implemented is in the spec and conforms to it
  • Non-conformant - any time a spec is implemented but does not conform to the spec
RISK - The Impact of a risk is not explicitly explained in TOGAF!
summarised as: Risk levels and Frequency make up Effect


Architecture Skills Framework categories
  • Generic Skills
  • Business Skills & Methods
  • Enterprise Architecture Skills
  • Program or Project Management Skills
  • IT General Knowledge Skills
  • Technical IT Skills
  • Legal Environment
 Business Transformation Readiness - BTR in phases AEF


Compliance -
  • Irrelevant
    • nothing from spec implemented
    • nothing implemented is in spec
  • Consistent
    • some spec'd not implemented
    • some impl'd not spec'd
    • some spec'd and impl'd
  • Compliant
    • Not all spec's impl'd
    • but nothing outside of spec is impl'd
  • Conformant
    • All spec'd are impl'd
    • even if some impl'd are not spec'd
  • Fully conformant
    • All spec'd and all impl'd

Posted by at
Labels: , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)