EA Modelling & Communications

Tutorial 5

Your EA Learning Journey So Far

Week 1Introduction

ConceptsWHAT IS

Week 2EA Theories

WHAT IS

Week 3EA Value & Risks

MgtWHY & a bit of how

from risk mgt perspective

Week 4EA Methodology(step by step procedural

guide for doing EA program mgt & “analysis

& design” modelling work)

Week 5Current &

Future Scenario modelling

( in “analysis & design” EA work )

Week 6Communicating

EA outcomes

Week 7Knowing

modelling, analysis & alignment guidelines

Week 8EA Software

Tools

Week 9EA Patterns &

Clustering

Week 10EA Investment

Planning, project mgt, security &

privacy req.

Week 11Agile EA & Future

Trends

Recap Baseline Concepts

2 main (work) groups of EA activities

Strategic, business & ICT and their integration “analysis & design” modelling activities done in 2 stages:1. Current scenario or environment

modelling2. Future scenarios modelling

Note: The current to preferred future scenario change management or transition plan is part of EA program management under SCOPE management

EA Program Managementactivities eg:• Integration management • Scope management• Time management• Quality management• Human resource management• Communications management• Risk management• Procurement management• Stakeholders management(PMI, 2014)

Recap Baseline Concepts

EA workgroup activities do NOT equate to

EA Methodology (eg TOGAF) , which is a phased & step by step “how to” procedural guide for carrying out:

1. EA Program management activities

2. Analysis & design modelling activities

Enterprise

Architecture

EA workgroup activities

EA Communications

What?

COMMUNICATION Perspectives of EA

EA Communications means….

Here are the EA artefacts (specs docs).

Do you understand how to use or produce/change

them in your management or project

work?

Huh? What?

….ensuring EA users (and team members) understand EA artefacts & consequently know how to use or produce them in their strategy, business, ICT and integration management or project work

Communicate EA artefacts by presenting them in management or project views that targeted users can understand

How do you communicate the different views of EA artefacts?

1Eg EA3 Artefacts

Q: How do you present them that EA users can easily understand?

An EA Artefact can be viewed by 1. Target domain – which enterprise system it is for?2. Project domain – where it is used in or developed by which project (or

program or even portfolio)?3. Additional filtering views, by:

• Business or application or infrastructure?• Social, symbolical or physical modelling level?• Process, info, actors or technology component type?

2 Answer

Question

How do you communicate the different views of EA artefacts?

More filtering views of EA artefacts:

Making explicit EA knowledge

(explains how)

Is an optimisation strategy for communicating EA development & modelling outcomes

Still don’t get it – how can U communicate EA artefacts?

Eg EA3 Artefacts

Report EA by different viewsEach view will make sense to the target users

Reporting outcomes are called EA viewpoints

EA viewpoints are the transformed knowledge insights that people can easily share, understand, use or develop in their management or project work

Theoretical and a practicalperspective of the issues involved in the communication of

enterprisearchitectures

Lecture notes summarize, and the underpinning details are in Chapter 4

Lankhorst

Optimising the EA Communication Process:Using Conversation Strategies

Each discussion examines a number of EA artefacts, for specific knowledge purposes (goals) – slides below tell you more details about discussion conversations ……..

EA Program manager will determine the comm sequence (as part of program coms mgt work)

Self Test: Explain what happens in EA communications

Learning Reflection: Slide 5 to this slide 9 explains “how EA artefacts are communicated “ you should read further & describe to confirm your understanding & clear communications

Guidelines for the selection and definition of architecture description

approaches

Strategy Vs Techiques

Strategy = “careful plan or method to achieve goals”

Example previous slide

Techniques = step by step procedures to help achieve some work goals

See Overleaf

Communication Techniques

Techniques = step by step procedures to help achieve some work goals

To deepen your own learning, you should read further (from both text & research sources) to find out what these techniques are about

Summarizing the 2 optimising strategies mentioned for communicating EA dev & modelling outcomes

1) Making EA knowledge explicit

2) Using conservation strategies and techniques

Concepts of EA languages

Lecture notes summarize, most underpinning details in Chapter 5

EA Communication Languages

EA Communication also has many languages, each that is made up of visual and/or mathematical modelling methods

see lecture slide 15 onwards to end.

UML & BPMNLanguage

ArchimateLanguage

IBM Rational System

Language

Examples Illustrated

Value Add of EA Languages

Read Chapter 5 (Lankhorst) and figure out yourself the elaborated details:

1. Helps to explain the inter-domain relationships of strategy;

2. Gives a formal foundation, which ensures that models can be interpreted in an unambiguous way and that they are amenable to automated analysis;

3. Enables visualising the same model in different ways, tailored towards specific stakeholders with specificied information (documentation) requirements

EA Communication ConceptsEA Communication is still a communication process

General principles of communications also apply

Be mindful which SoA layer/s are U communicating about

Which EA dimensional views are you referring to?

Check your language syntax (grammar) & semantics (context)

…… etc

Example: Archimate Layer Concepts:Which concept/s are you referring to in your EA communications?

Examples of Archimate Modelling ViewsSome are “as are” in current scenaro or required in future scenario/s

Or are extended viewpoints

Extended ViewsArchimate has its own views of EA presentations.

It also allows customisation of viewpoints to correspond to in-house or best practice standards’ specifications of EA “analysis & design” modelling

For example

Case Study: ArchisuranceExamples of Archimate modelling EA artefacts

( http://www.slideshare.net/iverband/archisurance-case-study )

Both Lecture & Tutorial covered

1. Discuss communication perspective EAs

2. Understand the theoretical and practical perspective of the issues involved in the communication of EAs

3. Overview on optimal support on architecture development and modelling

4. Understand the practical guidelines on the selection and definition of architecture description approaches

5. Explain the value added of an enterprise modelling language

6. Understand the layer concepts of the ArchiMate enterprise modelling language

7. ArchiMate extension and ArchiSurance case

Class Discussion Qs1. How far into the future should the EA future views attempt to provide

documentation?

2. Why is the same documentation technique used in the current and What is the relationship between the enterprise’s Strategic Plan and EA future views?

3. How can the ongoing transition between current and future EA views be managed?

4. How can Business Process Improvement (BPI) and Business Process Reengineering (BPR) activities be reflected in future views at the Product & Services Level of the EA³ Cube Framework?

5. How can changes in information flows and data structures be reflected in future views at the Data & Information level of the EA³ Cube Framework?

6. How can changes in applications and functionality be reflected in future views at the Applications & Systems level of the EA³ Cube Framework?

7. How can changes in voice, data, and video networks be reflected in future views at the Networks & Infrastructure level of the EA³ Cube Framework?

8. Develop a future scenario for an enterprise that describes changes in processes, human factors, and technology. Identify the planning assumptions that underlie these changes.

Danforth Case Study

Clues & Resource GuidesCalifornia EA Plan case example - http://www.cio.ca.gov/Publications/pubs/Appendix_A.pdf

“Future State Architecture Views The future state architecture views represent the future state (or "to be built" state) of the enterprise within the context of the strategic direction and the operating model and consist of the following models:

• Future Business Architecture – it describes the future state business capabilities and the business process model

• Future Information Architecture – it describes the structure of an organization's logical and physical data assets and data management resources required to support the future state business process model

• Future Applications Architecture – it describes what application systems are necessary and relevant to the enterprise and how those multiple applications work together to support the future state business process model and manage the information

• Future Technology Architecture – it describes what logical software and hardware capabilities and what networks providing communication paths will be necessary and relevant to the enterprise to support the future state business process model, information, and application services”

Can you infer what levels of planning assumptions will be made in specifying a future EA scenario?

Danforth future scenario description guide

List planning assumptions, sorted by EA

levels clarity of strategy,

business & ICT assumptions

Describe/Write the strategic positioning, business & ICT

situations where these assumptions prevail. If your

writing structure is methodological, then it is

easier to spot each EA-level category of assumptions

EA Practice: Future scenario description is usually supported by visual diagrams

Carries same story & meanings

Current EA Artefacts

Future EA Artefacts

Same artefact types & reported views

Document the future EA Artefacts