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

Interoperability and BTR

Developed with
QA
play-arrow
Start course
Overview
DifficultyBeginner
Duration32m
Students2
Ratings
5/5
starstarstarstarstar

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

- The next set of guidelines and techniques we'll be looking at are interoperability and business transformation readiness, so what are they? First, let's look at interoperability. Fundamentally, interoperability is about how information and services are shared between systems, specifically when sharing across processes, information and services. From an IT perspective, interoperability exists when user interfaces, business data, application functionality, and technology services are shared. Interoperability is most important throughout phases A to F of the ADM. It affects each phase differently. In phase A, the nature and security considerations of the information and service exchanges are first revealed as the business scenarios develop. You'll begin to see where the different parts of the enterprise intersect from a high level. In phase B, the information and surface exchanges are further defined in business terms. As the business architecture is developed, you'll begin to see where information flows. In phase C, the content of the information exchanges are detailed, using the corporate data and information exchange models. The way that the various applications need to share the information and services is specified, and as you develop the information systems architecture, you'll see what information flows. In phase D, the appropriate technical mechanisms to permit the information and service exchanges are specified. Here, the technology architecture is developed to show you how information flows. In phase A, the actual solutions, such as commercial off-the-shelf packages are selected. The opportunities have presented themselves and you'll be designing the solutions. And finally, in phase F, the interoperability solution is logically implemented, and that's it on interoperability. Next, let's look at the business transformation readiness technique. This technique built on work done by the Canadian government, called the Business Transformation Enablement Program or BTEP. It's used to evaluate the enterprise's readiness to undergo change. Its main purpose is to uncover the main challenges that may need to be faced when engaged in significant architecture change. The technique is initiated in phase A, developed further in phases B to D and then used in order to create an implementation and migration plan in phases E and F. There are five recommended activities that will help you assess how ready you offer business transformation. The first activity is to determine the readiness factors that will impact the organization. Here you need to find what the baseline is, and what will be impacted when you migrate to your target architecture. The second, is to present the readiness factors using maturity models. Once your factors are determined, you'll want to be able to present them to stakeholders and other participants in the architecture development. This should be done in a way that shows the maximum value that can be delivered. Third, is to assess their readiness factors, including the readiness factor ratings. Fourth, is to assess the risks for each readiness factor, and identify improvement actions to mitigate the risk, and fifth, finally, you'll need to work these actions into phase E and F implementation and migration plan. And that's it for this video. Next, we'll be looking at risk management and capability-based planning.

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.