ICT Architectures 5 Enterprise Architecture Bas Kruiswijk Leiden

ICT Architectures 5 – Enterprise Architecture Bas Kruiswijk | Leiden February 28, 2017 1

Contents 1. Definition of Enterprise Architecture 2. Methods and Frameworks • IEEE 1471 • Zachman Framework • TOGAF • DYA 3. Language for Enterprise Architecture • UML? • Architectural domains 4. Examples and cases 2

Roadmap Architecture Alignment Strategy • Strategic alignment • Information management • Enterprise architecture • Software architecture • Service oriented architecture • Business strategy • ICT Strategy 3

Three ‘types’ of ICT architectures Enterprise architecture Software architecture Service oriented architecture Conceptual foundations Enterprise scope Individual ICT system scope Focus on strategy and communication Focus on specification, design and realisation 4

Enterprise architecture • Architecture - The art and science of designing complex structures • Enterprise architecture - Coherent whole of principles, methods and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems and infrastructure • Architectural models, views, presentations and analysis help to bridge the ‘communication gap’ between architects and stakeholders • Enterprise architecture is an instrument in controlling the complexity of the enterprise and its processes and systems 5

Methods and frameworks • Frameworks structure architecture descriptions techniques by - Identifying and relating different architectural viewpoints - Associated modelling techniques • Methods assist architects through the phases of the lifecycle of an enterprise architecture - Phases of an architectural lifecycle - Deliverables 6

Methods and frameworks • IEEE 1471 • Zachman Framework • TOGAF • DYA 7

Definition of architecture IEEE 1471 • The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and development - Fundamental organization of a complex system - Its constituting components - Their relationship to eachother and to the environment - And principles and guidelines for design and development IEEE 1471: Recommended Practice for Architectural Descriptions of Software-intensive Systems IEEE: Institute of Electrical and Electronics Engineers • a non-profit, technical professional association • a leading authority in technical areas ranging from computer engineering, biomedical technology and telecommunications, to electric power, aerospace and consumer electronics 8

IEEE 1471 Conceptual model See fig. 2. 3 9

Views and viewpoints Policy maker View point Builder View point User Consistent model of the entire system 10

Views and viewpoints • Architecture cannot be described in a one-dimensional way • No single view can represent the whole architecture • To address the concerns of different stakeholders you need different views that focus on these concerns • View - A representation of a system from the perspective of a set of related concerns • Viewpoint - A specification of the conventions for constructing and using a view - a pattern or template from which to develop individual views by establishing the purpose and audience for a view and the techniques for its creation and analysis • A viewpoint is a way of looking at a system, and the view is what you see when looking from a chosen viewpoint 11

Methods and frameworks • IEEE 1471 • Zachman Framework • TOGAF • DYA 12

Zachman framework A framework for information systems architecture • Published in IBM Systems Journal, 1987 • Based on the concepts in classical architecture • Application of views and viewpoints ‘avant la lettre’ - A generic set of architectural descriptions - Different views for each of the stakeholders - As another dimension, a set of different aspects - The architectural representations differ in nature, independent of the level of detail 13

Based on concepts in classical architecture Building a house Representation Nature / purpose Bubble charts Basic concepts for building Architect/owner mutual understanding Gross sizing, shape, spatial relationships Initiate project Final building as seen by the owner Architect/owner agreement on building Floor plans, cutaways, pictures Establish contract Final building as seen by the designer Detailed drawings – 16 categories Translation of an owner’s view of a product Basis for negotiation with general contractor Final building as seen by the builder “How to build it” description Architect’s plans constrained by laws of nature and available technology Directs construction activities Subcontracter’s design of a part/section Specification of what is to be constructed Architect’s drawing Architect’s plans Contractor’s plans Shop plans Detailed stand-alone model Pattern Building Physical building 14

Observations • Three fundamental architectural representations, one for each “player in the game” - Owner: A product that will serve some purpose - Designer: A design of a physical product - Builder: A producable product • Preliminary actions: Establish the ball park where all of the ensuing architectural activities take place • Subsequent actions: Detailed, out-of-context representations • These architectural representations differ in nature, independent of the level of detail 15

Zachman framework The different views, for each of the stakeholders • Scope (contextual) – Ballpark / Planner view - Definition of the scope: the enterprise’s direction, business purpose and goals: the context for the entire architecture • Enterprise model (conceptual) - Owner’s view - Model of the organisation: structure, functions and organisation • System model (logical) – Designer’s view - Model and description of the requirements in more rigorous information terms • Technology model (physical) – Builder’s view - Translation into technological solutions; how technology may be used to address the information processing needs • Detailed representations (out of context) – Subcontracter’s view - Detailed specifications and program code etc. • Functioning system – User’s view 16

Zachman framework Different aspects • Data (What) • Function (How) • Network (Where) • People (Who) • Time (When) • Motivation (Why) 17

18

Zachman framework (2) 19

Zachman framework Design artefacts aspects Model View Stakeholder See fig. 2. 4 20

21

22

Concluding remarks on the Zachman framework • First and best known architecture framework • Easy to understand • Addresses the enterprise as a whole – Enterprise Architecture ‘avant la lettre’ • Independent of tools or methodologies • Drawbacks - Large number of cells (architectural artefacts) – not practical - Relations between the cells are not well specified Evolution of the Zachman Framework 23

Methods and frameworks • IEEE 1471 • Zachman Framework • TOGAF • DYA 24

TOGAF The Open Group Architecture Framework • TOGAF is a framework as well as a method • Architecture Content Framework - Considers an overall enterprise architecture as composed of four closely interrelated architectures: Business, Data, Application and Technology Architecture • Architecture Development Method (ADM) - An iterative sequence of steps to develop an enterprise-wide architecture Besides that, also • The Architecture Capability Framework - Addresses the organisation, processes, skills, roles, and responsabilities required to establish and operate an architecture function within an enterprise • The Enterprise Continuum - During application of the ADM, assets are created or drawn from existing assets, used, modified and returned to the virtual repositorythat is the Enterprise Continuum 25

TOGAF Architecture Content Framework • Business architecture - Defining the business strategy, governance, organization, and key business processes of the organization • Applications architecture - Providing a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization • Data architecture - Describing the structure of an organization's logical and physical data assets and the associated data management resources • Technology architecture - Describing the software infrastructure intended to support the deployment of core, mission-critical applications 26

TOGAF Architecture Development Method (ADM) 27

Methods and frameworks • IEEE 1471 • Zachman Framework • TOGAF • DYA 28

DYA Dynamic architecture – the DYA-model • Sogeti’s vision on how to work with enterprise architecture • DYA is a method, a process in the first place 29

DYA The DYA framework of architectural views Architecture objects Levels of abstraction 30

DYA The 10 main principles 1. Architecture is strategic if IT is strategic 2. Architecture must facilitate pace of change 3. Communication between business and IT management is crucial 4. Business objectives govern the development of architecture 5. The level of architecture will be continually raised if architecture is aligned to important business changes 6. Architecture must be developed “just enough, just in time” 7. Working within architecture is supported by a theoretical and working model 8. Transparent relationships must be defined 9. Several development strategies are distinguished 10. Architectural principles and processes must be an integral part of the organization 31

Language for Enterprise Architecture • UML – Unified Modelling Language - Software modelling - Static (structure) and Dynamic (behaviour) aspects - 13 sublanguages / diagrams • Language for Enterprise Architecture - UML is the industry standard for modelling applications and technology - No industry standard for organization and business processes etc. - Bottleneck: relationships between architectural domains 32

Integrating architectural domains See fig. 3. 1 33

The architectural domains within an Enterprise Architecture Business Architecture Relationship Information Architecture Relationship Application Architecture Relationship Technical Architecture 34

The architectural domains within an Enterprise Architecture Business processes are supported by Functionality provided by Applications running on Hardware Business Architecture Relationship Information Architecture Relationship Application Architecture Models + Principles Relationship Technical Architecture 35

The architectural domains within an Enterprise Architecture Business Architecture • Business processes • Products and services • Organizational structure Relationship • Functional components • Logical data objects Relationship Application Architecture • Applications and interfaces • Common infrastructural facilities • Physical data objects - Databases Models & Principles Information Architecture Relationship Technical Architecture • Hardware • Network • Physical locations 36

ICT Architectures 5 – Enterprise Architecture 37