Cloud Academy
  1. Home
  2. Training Library
  3. Module 4: How to manage the Architecting Process

Principles

Developed with
QA
play-arrow
Principles
Overview
DifficultyBeginner
Duration32m
Students1

Description

Course Description 

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. 

Learning Objectives

This module will cover:  

  • Architecture Governance  
  • Architecture Principles
  • Business Scenarios  
  • Gap Analysis  
  • Interoperability  
  • Business Transformation Readiness 
  • Risk Management  

 Intended Audience  

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.  

Feedback 

We welcome all feedback and suggestions - please contact us at qa.elearningadmin@qa.com to let us know what you think. 

Transcript

- Designing and implementing an architecture can often involve multiple people, groups, or departments. Everyone is going to have their own input, way of working, or interest in a particular output. You're aiming for the organization to come to a rational decision that everyone accepts. So managing the different people and perspectives is crucial to the success of the architecture development. The TOGAF framework suggest using principles to manage this. So, how do you use principles in enterprise architecture? Let's start by defining what we mean by principles. They're enduring rules that enable decision making and help to inform the organization on how to fulfill its mission. Principles should be generated by the chief or most senior architect. You'll also want to make sure that senior stakeholders are included in the process of creating them as they're likely to have useful input about the organizational context. You'll also want your architecture board involved. And check to see if the enterprise has any existing principles that will need to be adopted, such as employment, quality, or financial principles. Fortunately, you don't have to generate all of these principles from scratch. TOGAF dos have some ready to go ones that you can use or build on to meet the context of the enterprise. They're broken into four areas, business, data, application, and technology. When generating the principles, it's useful to put them into a standard format. A useful template for recording them would include a name, which should be memorable and express the essence of the rule, a succinct and unambiguous statement that communicates the fundamental rule, a rational or reason for the principle, with particular emphasis on the business benefits of adhering to it, and the implications, or impact, of abiding by the principle. You'll also want the principles to be consistent by making sure they're easily understood, everyone in the organization gets the principle and it can be implemented and applied easily. Robust, they can stand for a period of time without interference. Complete, they don't require any explanation or additional work to implement. And stable, they stand by themselves and don't require support. Principles can be used to establish the fitness for purpose of the architecture as well as its functionality, and lead to the successful implementation of strategic architecture. They can also be used to good effect in connection with architecture compliance assessments to make sure people are following the rules. Finally, it's worth noting that it's common for enterprise architects to orientate their entire approach to architecting around particular styles, two in particular, are highlighted in the TOGAF framework. Risk insecurity, now a fundamental parallel aspect to enterprise architecting. Service-oriented architecting, which is getting every more important as service-centric systems are developed, especially on the cloud. Crucially, to deal with these effectively, the style must be considered throughout the ADM. And that's it for this video. Next, we'll be looking at business scenarios and the DAP analysis techniques.

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.