Following are unprocessed notes from a recently taken 4 day long TOGAF training. I’ll clean the notes in a near future, so until then, please ignore errors and formatting. However even as it stands, someone may still find it useful, as it’s a collection of the most important course highlights.
TOGAF 9.1 – Training Notes
Reasons for TOGAF? Togaf is a capability framework. It describes what capability you have to fulfill a business vision. It’s a dynamic system made of ongoing activities – a constantly moving target. It defines the process of describing and closing gaps between business vision and business capabilities. Requires capabilities implemented in business, architects with certain skill level and certain things put in place (enterprise architect council, etc). Aligns business and IT objectives (must be a two way communication). What is the business vision? What are your market drivers? Once you understand What?, you can design How!
TOGAF – high level layout:
- Architecture: requirements
- Solution: specifications
- Product: physical
The ADM (The Architecture Development Method) is the core of TOGAF. ADM describes what deliverables will be created. Also at what point will each deliverable be of interest. ADM is a method of developing and managing life-cycle of Enterprise Architecture. It helps to meet the business and IT needs of an organization. Cycle of ADM can be applied to any segment (strategic, business, data, application and technology architecture), when scoping the architecture.
The ADM provisions 3 types of iterations, namely:
- comprehensive architecture landscape (waterfall fashion)
- architecture development iteration (what are the gaps) – non-sequential fashion
- architecture capability iteration – redefined after visiting steps – we do what we can do.
A – Architecture Vision – create architecture vision, get approvals, define the scope. How many people do you have, how much time do you have? How will the brave new world look like? What are the cost benefits? What’s the value of implementing? (make more money? get rid of competition?). Define dependencies (albeit this is not in architectural control). Develop a high level aspirational vision of what you are trying to achieve and then obtain approvals. Get reference materials, non-architectural inputs (business principles, goals, drivers) and architectural inputs (model for enterprise architecture, etc.). Identify stakeholders, confirm goals, constraints, evaluate capabilities, define scopes, assess transformation (is business ready?), create documents to communicating on all levels, identify risks and mitigation activities, develop statement of architecture work, secure approvals. Outputs: this would be your blueprint. Output will be: Approved statement of architectural work. Refined principles, goals, drivers. Problem definition, summary views, draft architecture.
B – Business Architecture
C – Information Systems Architectures
D – Technology Architecture
Following is common for B, C & D phases.
Once I know how the future will look like, based on architecture vision, then I can start development of a business architecture. What needs to change in business. How it looks now and what it needs to look like? Then start identifying and closing the gaps between baseline (typically a previous target) and a new target. Identify candidate roadmap components. Input: reference materials, what we have, what we need, communication plan, enterprise continuum (what structures do we already have), repository, vision. This is basically a data. How can we close the gaps? Steps: select reference models, develop target description, perform analysis, define roadmap components, resolve impacts across the architectural landscape. Outputs: refined and updated versions of the Architecture vision phase deliverable draft definition document…
E – Opportunities and Solutions – What are opportunities to close these gaps in B, C & D? Initial plan based on logic. Identify major implementation projects. Can we do everything at once, or define in how many steps we get to closing a gap (implementing a solution). Initial implementation plan. Determine whether an incremental approach is required. Generate initial complete version of the architecture roadmap.Steps: confirm key corporate change attributes, determine constrains (people attitude towards change), review gap analyses, refine and validate dependencies, confirm readiness, formulate implementation strategy, identify transition architecture, create the initial architecture roadmap. Outputs: vision, draft
F – Migration Planning – Risk management. What is the risk? Are the resources available (money, vendors, etc.). Also making sure that new project doesn’t break existing functionality and projects. What is the chance the cost would be higher than benefits provided by implementation. Finalize the roadmap and the supporting implementation and migration plan. Ensure the business value and cost of work. Steps: what is our framework for implementation and migration? How do we hand it over to implementation? Estimate resource requirements, project timing, availability. Confirm roadmap, finalize the blueprint of architecture definition document. Generate the implementation and migration plan. Complete the ADM and document the lessons learned. Outputs: detailed implementation and migration plan, finalized definition document, finalized requirements, finalized architecture roadmap, reusable building blocks, implementation governance model.
G – Implementation Governance – it’s an architectural oversight. Architect needs to ensure that when architecture is handed to developers, architect still needs to be involved. Architect is leading, making sure that blueprint is being followed. Architect is reviewing body, can be member, leader of the team or just overview from time to time the progress. If we find out that blueprint is not working, in this phase we would submit the change request for the next iteration to trigger assessments, etc. Identify resources and skills, perform compliance reviews. Outputs: sign off architecture contract by stakeholders, compliance assessments, populated repository, architecture-compliant system, SLAs.
H – Architecture Change Management – assessments to close gaps in vision and above ADM points. This includes monitoring on architectural level. Get input on how is environment changing and what needs to be changed in your architecture. Ensure we have architecture life-cycle. How much have we implemented, how successful was it? Making sure that we govern implemented solution, so it doesn’t deviate from blueprint. Also making sure we have skills on the team for new technologies, etc. Steps: deploy monitoring tools, manage risks, provide analyses (how can we fix things?), manage governance process.
TOGAF – various unsorted notes:
Enterprise – common goals, communication, coordination, integrate – not work against each other. Enterprise is typically the highest level of description. Not everything needs to be pushed to enterprise level. Trade off, how do we know? Principals should be re-usable. Only works if you document things.
Architecture – components that create value, templates. Identifying what are the key components and how they relate. Architecture links components together and facilitates the value.
Design – what fulfills requirements?
Togaf creates repository that lists all components, everything business does. That way business doesn’t have to reinvent the wheel. Reduces the risk, enables sharing and reuse of components. Gives business a better return on investment. TOGAF is there also to introduce a common language.
Business – matrices, catalogues, diagrams
Continuum – system for cataloging all business repositories. Enables entering and searching.
ArchiMate – tool for architects,… sort of a programming language to make work of architects easier. However, not yet implemented into Togaf. They also offer ArchiMate certification.
Implementers: IBM, HP, Department of Defense. It’s almost mandatory in all large companies. They are typically also contributing members of Togaf.
Preliminary Phase – preparation and initiation activities. Get and set objectives, inputs, steps and outputs. Build a team.
Requirement Management – place to check requirements – central point where we manage requirements
Version numbering should be used to illustrate the evolution of deliverables.
Building blog is the most elementary part, however few of them together could also be called building block. Artifacts describe building blocks. Artifacts create deliverables. Deliverables are reviewed, agreed and signed off by stakeholders.
Architecture Repository: Vanila description would be: the architecture metamodel includes architecture landscape, reference library and standard information base, plus best practices. Architecture Capability part describes documentation, parameters, structures, processes. Reference library items can later become standards. Governance log is date and description for tracing decisions in the past. Architecture Landscape is an actual architecture, plus metamodel for architecture content.Everything in Togaf can be found in the repository created in a very organized way. Nothing is stored in emails or outside of the repository. Togaf repository should also be a library of information assets.
Architecture Continuum: provides view on architecture repository. High level, medium level and detailed level organization of architecture. Sort of a funnel for foundation, common systems, industry architecture, organization specific architecture and their guides and supports.
Solutions Continuum: provides view on solutions repository•
Capability planning includes Business Planning and Enterprise Architecture. Business planning at the strategy level provides initial direction to Enterprise Architecture.
Enterprise Architecture creates and provides structure for all corporate initiatives. It supports solution development by providing architectural governance.
Steps: Identify deliverables (vision, blocks, roadmap, assessments, definition documents, change requests, etc.
Input & Output – also called Deliverables in Togaf documentation.
What is the key difference between TOGAF 9.1 and TOGAF 9? It is mostly that 9.1 has been reduced in size by about 80 pages. Confusing parts were left off. As per our training, not much new has been added. It was mostly about cleaning original vs 9.
Prince2 – European version of PMI.
COBIT – framework for governance
Cataloging of principals is done in preliminary phase (all metadata), but actually putting them into catalog is in Architecture Vision.
Stakeholder power grid – stakeholder management approach. Another approach is to user stakeholder template.
View (blueprint) is a graphical representation for stakeholders. View is created based on viewpoints. Viewpoints addresses concerns.
Risk identification and mitigation assessment worksheet – risk mitigation process, consisting of identifying, planning and conducting actions to reduce risk.
Security architecture is a cross layer principle – crosses all domains in BADT model (Business, Application, Data, Technology).
III-RM (integrated information infrastructure) – model of the application components and services.
SOA (service oriented architecture) – architecture style that supports service orientation –
Treasury board of Canada – has info on business transformation readiness assessments•
Voucher is valid for 1 year. There is no waiting period if you fail, you can schedule the next one•
60 minutes for level 1. It’s a combined exam. So when 60 minutes up, it flows to level 2 time, which is 90 minutes.
Level 1 is questions and answers. 5 choices, 4 wrong, one good.
Level 2 is 8 questions of multiple answers, scenario based. 4 possible answers, all give credits except one answer. One of them gives most credits.
Level 1 passing grade 55%, 22 out of 40 need to be correctly answered to pass Level 1.
Level 2 has 60% passing grade.