TOGAF 9.2 Foundation
This module looks at the supporting guidelines and techniques of the Architecture Development Method, as well as governing the architecting process. This module is supported by videos and a PDF, and is followed by a quiz to help support your understanding.
This module will cover:
- Architecture Governance
- Architecture Principles
- Business Scenarios
- Gap Analysis
- Business Transformation Readiness
- Risk Management
This course is intended for anyone looking to understand Enterprise Architecture. It is helpful however to have several years' experience in IT in a variety of roles, or to have an understanding of Enterprise or IT Architecture.
Prerequisites of the Certifications
There are no formal pre-requisites for this course.
We welcome all feedback and suggestions - please contact us at firstname.lastname@example.org to let us know what you think.
- A crucial aspect of the architect's role is to be aware of all the concerns held by all stakeholders. A stakeholder is someone interested in your architecture or system, and concerns can be used to articulate the nature of the stakeholder's interests. So what do these concerns look like and how are they addressed? Concerns may be connected to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability, and may determine the acceptability of the system. For instance, the security stakeholder may be concerned with the way the system is to be protected. An architecture viewpoint is used to capture, or frame, information about the concerns held by the stakeholder, including any associated conventions. For instance, the security stakeholder may be interested in network domains and the way firewalls are placed between them. A further stipulation may be that both internal and external network domains must be addressed, an example of a convention. The architecture view is a representation of how the system has addressed the concerns expressed in the viewpoint. For instance, if the architect created a diagram to capture the necessary information, then it could be published in some form of document. Think of the diagram as an architecture model and the document as the means by which the architecture view is presented to the stakeholder. The viewpoint governs the view and relies on a one-to-one relationship between them. In this context, the relationship is one of dependency. A viewpoint without a view means the stakeholder would not be able to see how the system responded to their concern. And a view without a viewpoint simply means the view is pointless. All of these definitions derive from the International Standard ISO/IEC/IEEE 42010:2011 Systems and Software Engineering Architecture Description. And that's it for this video and this module. Make sure you complete the knowledge check and check out the PDF with all of the diagrams from this module.
About the Author
In a varied career that began in 1974, John Coleshaw has trodden a relatively unusual path whereby his roles have split evenly between Business and IT. In the early 80s he was the Credit Manager for a multi-national electronics company, and at the same time built a computerised financial and credit analysis tool using the original version of the IBM PC. In the mid-80s, whilst performing the role of senior underwriter in the Credit Insurance industry, he managed the IT system, as well as developed an innovative risk analysis tool. At the start of the 90s, as a manager in a financial information company, he developed an early form of expert system whose purpose was to predict corporate failure.
His current career as an IT trainer began in 1998, specialising at the time in Object Oriented programming languages. In 2002 he started developing and delivering IT Architecture training and has now had the opportunity to meet and discuss architecture matters with over a thousand architects. The courses he trains now span both The Open Group (TOGAF and ArchiMate), and BCS.
He has a book to his name, one written in the late 80s on Credit Risk Analysis.