Developing EA Blueprints Overview of Concepts EA Methodology

Developing EA Blueprints Overview of Concepts EA Methodology Vs Framework Current & Future EA Development In-depth Concepts of above

Understanding the Relationships between EA Methodology & Framework Remember this lecture 1 slide? An EA Methodology defines: • The work breakdown steps to manage & execute EA work, for example TOGAF An EA Framework classifies the types of EA documents produced in the course of executing EA work. Also note that EA 3 calls the: • Classification types of EA documents as “EA components”. The EA 3 diagram we frequently use shows the classification taxonomy (structure) of how Bernard views classifying the types of EA documents. • Actual documented specs “EA artefacts”. Because they are classified by EA components, they are also tagged appropriately when stored in the EA repository to aid easy retrieval.

EA Methodology Guidelines for Current & Future EA Development Remember this lecture 1 slide? An EA Methodology defines: • The work breakdown steps to manage & execute EA work, for example TOGAF An EA Framework classifies the types of EA documents produced in the course of executing EA work. An EA methodology will also involves modelling the current and future blueprints of EA, to provide a snapshot of: 1. How today’s (ie current) strategic, business and ICT services integrate to profile the organisation’s service capabilities and marketable products; 2. How future strategic, business and ICT services integrate to profile the organisation’s service capabilities and marketable products, relating to a selected future or a series of future scenarios.

EA Methodology Guidelines for Current & Future EA Development Remember this lecture 1 slide? An EA Methodology defines: • The work breakdown steps to manage & execute EA work, for example TOGAF An EA Framework classifies the types of EA documents produced in the course of executing EA work. Once the current and future EA blueprints are defined (ie all the artefacts are documented to profile the organisation’s current and future EA views, the EA team has to work out how to change/transform the current EA blueprint to the desired future one or mix of future EA scenarios. An EA methodology will continue to describe the steps in preparing and executing an EA transition plan to realise the desired future EA scenario.

Summary of Current & Future EA Dev Concepts 1. What EA artefacts to produced based on the classification taxonomy specified in an EA framework? 2. How to develop current & future EA blueprints? 3. How to prepare & execute a transition plan that describes how to change a EA blueprint to realise a desired future EA blueprint or a series of future EA scenarios Past tut slide Methodology Tut 2: Lay Language: is an industry wide or an open system community agreement of a standard Tut 2: Sometimes they are the same Framework Tut 2: Lay Language: is a level of quality attainment that is used as measure, norm or model in comparison evaluations

Developing EA Blueprints Learning Deeper Concepts discussed in lecture 5

Varying EA Frameworks & Visual Interpretations Lecture Slide – EA 3 Framework BE WARE THAT: 1. Different EA Standards recommend different “analysis and design” documentation frameworks Zachman EA Framework 2. Even within a Standard, academic and practitioners can visualise the same standard’s documentation framework differently, however still agreeing the same EA classification taxonomy concepts. Therefore, as a proficient architect, you should check that a given EA framework diagram carries the same semantics as the intended original EA framework, before using it.

How EA 3 Framework structures the classification of EA documentation Business Env Strategic Operational ICT Env Strategic Operational Classified by EA Component See it as: EA Doc Template applies Template Section Breakdown KPI uses Performance Measures Instantiated in EA Artefacts Links Applied by Modelled by EA Modelling Method Eg UML Methods Structured Methods etc Simply put, view • An EA 3 component describes & structures the elements of an org’s business & ICT environments (aka EA doc content-descriptors) • An EA 3 artefact is a type of EA documentation that contain information about EA components (aka EA doc content-instances)

How EA 3 Framework structures the classification of EA documentation Business Env Classified by Strategic Operational EA Component See it as: ICT Env Strategic Operational EA Doc Template applies Template Section Breakdown KPI uses Performance Measures Instantiated in If you want to further understand where EA artefacts are stored, depending on what EA documentation software tools are used EA Repository stores Links Sources from EA Sware Tool’s DB EA Artefacts populates EA Sware Tool Applied by Modelled by EA Modelling Method enables Enabled by

Strategic (Goals & Initiatives) Level EA 3 Component-Artefact Examples Data & Information Level Product/Service Level No example given System & Application Level Network & Infrastructure Level

Zooming deeper into an example of Component & Artefact Relationship Strategic Plan as a “component” formats what is in an actual strategy plan Vision Statement Mission Statement Strategic Directions Description • • Using a number of software tools Includes a number of KPI and performance measures info SWOT Analysis Findings Concept of Operations Current Scenario Future Scenario 1 Future Scenario 2…. Future Scenario N Concept of Operations Visual Diagram Competitive Strategy Sub-Plan Strategic Positioning Goals Strategic Org Projects Breakdown KPI & Measures Content populated strategy plan artefact containing vision stmt, mission stmt………. .

Purpose of Management Graphic Views of EA Artefacts EA 3 component structure enables: All management stakeholders – strategy, business & ICT managers cam hold interest in EA program less risks to EA program management:

An EA Methodology also involves Current & Future EA Blueprints development Current EA Best Case Scenario of Future EA Blueprint Development: Documented EA modelling of current business & ICT environments Several Future Business & ICT scenarios formulated & evaluated involves Blueprint Development: Documented EA modelling of selected future scenario of business & ICT environments

An EA Methodology also involves Current & Future EA Blueprints development Identify the ICT resources linked to supporting current strategy & business work & products Current EA Blueprint Development: Documented EA modelling of current business & ICT environments Identify the ICT resources linked to supporting future scenarios of strategy & business work & products Future EA Blueprint Development: Documented EA modelling of selected future scenario of business & ICT environments Range of Analysis & Design / Modelling Methods IDEF Activity Modelling Lecture shows many Swim Lane Modelling graphic diagrams of Business Process Flow Modelling outcomes Project Management methods Business case development methods Data & information modelling methods eg ER, DFD, ontology modelling So. A Modelling methods……. . etc

An EA Methodology also involves Current & Future EA Blueprints development Step 1: Develop Current & Future EA blueprints Current EA Blueprint Step 2: Develop the Arch Management Plan Documented EA modelling of current business & ICT environments Transition Plan Development: Future EA Blueprint Development: Documented EA modelling of selected future scenario of business & ICT environments

Tutorial Tasks

MCQ 10 – Special Focus Discission Which one of the following is most Incorrect? The management view of EA artefacts helps to increase: a) Communicating the high level management-friendly view of EA b) Gaining and maintaining the support from EA executive sponsors and other stakeholders c) Showing the scope boundary of the organisation’s EA documentation d) Combining EA and other IRM artefacts into actionable information for managing and decision-making purposes Which is the correct answer & why?

Section 2 Questions 1. What is the purpose of current views of EA components? 2. How do artifacts relate to EA components? 3. Provide some examples of artifacts at the Goals & Initiatives level of the EA³ Cube Framework. 4. What is IDEF-0 modelling and how can it be used to document EA components at the Products & Services level of EA³ Cube Framework? 5. What are the differences between traditional (ERD and DFD) data modelling techniques and object oriented data modelling techniques (UML)? 6. Provide some examples of artifacts at the Applications & Services level of the EA³ framework 7. Is vendor-supplied documentation on software and hardware products important to retain as EA artifacts? Why? 8. What are some of the EA artifacts that would be desired at the Network & Infrastructure level of the EA³ Cube Framework?

Section 2 Questions 9. Find a public or private sector enterprises and identify the following current EA components/artefacts at each level of the EA³ Cube Framework: a. Identify current strategic goals, initiatives, and outcome measures. b. Identify current LOBs, business services, and associated activity/flow diagrams. c. Identify current information flows and data documentation in each LOB. d. Identify the current IT systems and applications that support information flows for each LOB. e. Identify the current IT infrastructure and networks that host IT systems and applications. 2 ways of handling this: (a) A Simple one is to link to the Danforth case study (scene 4) to identify the possible artefacts under each of the EA 3 levels by using the EA 3. 2 list of artefacts – the answer is pretty straight forward if you read the book - – this can shape an answer that you would expected in the example (b) A real life case study – which an example will be given in next week – this is NOT an answer you would expected in the example, but more appropriate for an assignment

Case Study Scene 4 – Explaining the EA 3 Methodology “Thank you for coming to today’s meeting of the Enterprise Architecture Working Group” said Sam. We are going to talk about the method for developing current and future views of the two segments of the company’s enterprise architecture we are developing. These segments cover manufacturing and production, which are the lines of business identified by Kate and Jim that require more IT support. At the last meeting we developed the detailed implementation methodology that will guide our efforts and reduce the risk that we will not be successful. Vince Albright, our Chief Architect, will describe the documentation of current and future views. ” “In accordance with our implementation methodology, we will be using the EA framework to organize and guide the documentation of current and future views of these segments of the DMC architecture. Following the framework’s structure, we will gather existing artefacts of information on the lines of business in the following order: strategic goals and initiatives, business services, information flows and data elements, systems and support services, and the network infrastructure. These documentation artefacts come in many forms including reports, policy memos, manuals, spreadsheets, briefing slides, diagrams, and video files. By organizing these artefacts in the online EA repository into categories that match the levels and areas of the framework, we can establish links between the information to produce robust new views of the lines of business. This also establishes a baseline of EA information for future planning and decisionmaking. Architect Vince The Albright As for documenting the future views, we will start by establishing several future operating scenarios with Jim, Kate and their staff members. These scenarios are short stories about possible future activities in a variety of friendly and hostile business climates. The scenarios help us to identify important planning assumptions about their future line of business activities, depending on the environment. Once the most probable scenario is selected, we will use the planning assumptions to guide discussions in our Working Group, and decisions by Jim and Kate on what they want to invest in to best position themselves for success in the future. Finally, we will identify how these decisions cause changes to the current EA at each level of the framework, and will document those changes in new artefacts that are saved in the EA repository in a separate future EA section