EA Modelling & Communications Tutorial 5

Your EA Learning Journey So Far  Week 1 Introduction Concepts WHAT IS  Week 2 EA Theories WHAT IS  Week 3 EA Value & Risks Mgt WHY & a bit of how from risk mgt perspective  Week 4 EA Methodology (step by step procedural guide for doing EA program mgt & “analysis & design” modelling work)  Week 5 Current & Future Scenario modelling ( in “analysis & design” EA work ) Week 6 Communicating EA outcomes Week 6 Communicating EA outcomes Week 7 Knowing modelling, analysis & alignment guidelines Week 8 EA Software Tools Week 9 EA Patterns & Clustering Week 10 EA Investment Planning, project mgt, security & privacy req. Week 11 Agile 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 modelling 2.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 Management activities eg: Integration management Scope management Time management Quality management Human resource management Communications management Risk management Procurement management Stakeholders management (PMI, 2014)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? 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? 1 Eg 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 views Report EA by different views Each view will make sense to the target users EA viewpoints 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 practical perspective of the issues involved in the communication of enterprise architectures 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)comm sequence 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 & BPMN Language UML & BPMN Language Archimate Language Archimate Language 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 Concepts EA 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 Views Some are “as are” in current scenaro or required in future scenario/s Or are extended viewpoints

Extended Views Archimate 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: Archisurance Examples of Archimate modelling EA artefacts ( )

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 Qs 1.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 Guides California EA Plan case example “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