Enterprise Architecture

Overview Part 2: Enterprise architecture Introduction to ICT architecture Enterprise architecture Why is enterprise architecture so important? Central concepts: views, viewpoints, stakeholders The classic framework for enterprise architecture: Zachman Other frameworks for enterprise architecture Software architecture

Enterprise architecture Software architecture Service oriented architecture Conceptual foundations Enterprise scope Focus on strategy and communication Individual ICT system scope Focus on specification, design and realisation

Enterprise architecture Why is it so important? (1) A lot of ICT projects fail The majority (50% - 70%) of technology implementations fail11 75% of all attempts to introduce automation to the workplace have failed1 There is always more than ICT alone Technology introduction requires (major) changes outside the technology domain, which the technology introduction does not ‘automatically’ bring about2 Looking at technology alone is insufficient for making technology ‘work’2 More stringent financial governance (usually) does not help There is no correlation between investment in IT and profitability, or other key measures of business success3 1. Rechting, E. – Systems Architecting of Organizations (2000) 2. Scott Morton, M.S. – The Corporation of the 1990s (1991) 3. Pisello, T., Strassmann, P. – IT Value Chain Management – Maximizing ROI from IT Investments Source: dr.ir. J.A.P. Hoogervorst

Enterprise architecture Why is it so important? (2) An integrated enterprise design focus is the key to increasing success of ICT implementations! Success of ICT implementation can be increased by an integrated design and implementation of business, organizational, informational and technological arrangements On an enterprise scale This ‘operationalizes’ business – IT alignment (the contribution of ICT to business goals and strategy)

Enterprise architecture What is it? Gives insight into, and an integrated overview of business processes information functionality information systems / applications, and underlying infrastructure in relationship to each other Also includes the relationships to the environment Besides models, the architecture consists of principles and rules that guide the design and evolution over time Defines the common IT platform, i.e. middleware etc. Justifies and protect long-term ICT investments (i.e. in generic facilities in the common IT platform) Guarantees a certain amount of flexibility and openness Serves as the most important means of communication

Definition of ICT-architectuur 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

Central concepts for Enterprise Architecture 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 Viewpoint A way of looking at a system View What you see when looking from the chosen viewpoint

Central concepts for Enterprise Architecture Views and viewpoints (2) Collection of models, representing the whole system, with respect to a set of related concerns A view belongs to a particular architectural description Viewpoint The rules for constructing and analyzing a particular kind of view including the choice for an ADL (architecture description language) A reusable template

Views and viewpoints Architecture View View View Stakeholder Viewpoint

Architectural frameworks Based on the concepts of views and viewpoints A particular choice for certain viewpoints, related tot certain concerns of stakeholders An architectural framework Defines a set of concrete viewpoints (architectures) Defines the aspects that are described and modeled in each of these architectures / viewpoints Defines the stakeholders (Sometimes) defines modeling conventions or language (Sometimes) defines the proces of creating an enterprise architecture (Sometimes) defines a set of tools to be used

The architectures within an Enterprise Architecture Business Architecture Relationship Information Architecture Relationship Application Architecture Relationship Technical Architecture

The architectures within an Enterprise Architecture Business Architecture Proposition and market Products and services Business processes Organization and governance Relationship Information Architecture Information-processing functionality Functional areas / objects Datamodel and data dictionary Rules – Standards – Principles - Guidelines Models Relationship Application Architecture Applications and interfaces Common infrastructural facilities Design principles and guidelines Data structure / databases Relationship Technical Architecture Hardware Network Physical locations Technical standards

Examples of architectural frameworks General frameworks Zachman Architecture Framework (the classical framework) TOGAF (The Open Group Architecture Framework) DYA (Sogeti) Practical examples Example UWV/Werkbedrijf NORA (Reference architecture for Dutch government and public organisations) Twynstra Gudde

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

Some quotes... “The increased scope of design and levels of complexity of information systems implementations are forcing the use of some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system.” “Since the technology permits ‘distributing’ large amounts of computing facilities in small packages to remote locations, some kind of structure (or architecture) is imperative because decentralization without structure is chaos.” “What, in fact, is information systems architecture?” ... the words’ information systems architecture’ are already losing their meaning. ”

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

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

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

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

TOGAF The Open Group1 Architecture Framework Architecture Development Method (ADM) An iterative sequence of steps to develop an enterprise-wide architecture The Enterprise Continuum During application of the ADM, assets are created or drawn from existing assets, used, modified and returned to the virtual repository that is the Enterprise Continuum Resource Base During application of the ADM, processes, templates, checklists and other items from the Resource Base are deployed as methods to develop the architecture 1) The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow™ will enable access to integrated information, within and among enterprises, based on open standards and global interoperability.

TOGAF Architectural views Business (or business process) 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

TOGAF ADM: Architecture Development Methodology

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

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

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

NORA (Dutch Government Reference Architecture) Architecture matrix

Example: Framework used by UWV/Werkbedrijf Informatie Applicatie Technische WAAROM Rapport business- architectuur Contextuele technische architectuur Contextuele applicatie- architectuur Contextueel SUWI-wet Gegevens- gebieden architectuur WAT BP2002 Basis bedrijfs- model Conceptuele applicatie- architectuur Conceptuele technische architectuur Conceptueel Architectuur van de bedrijfs ondersteuning HOE RWP (architectuur) Proces- model Logische applicatie- architectuur Informatie- systeem architectuur Logische technische architectuur Logisch WAARMEE CWI- werkprocessen Proces- simulatie Fysiek Infrastructuur

Example: Architecture framework Twynstra Gudde 4 architectural views Business, Information, Application, technical Relationships Aplications support business processes Business processes are supported by information and communication functionality Information and communication functionality is provided by applications Applications use / are deployed on the technical infrastructural 4 typical architectural issues Integration issues Functional issue Vision Migration

Examples of Enterprise Architectures in practice Twynstra Gudde enterprise architecture portfolio, published in ‘ICT Architectuur in beeld’ http://www.scribd.com/doc/2432437/Architectuurboek

Example of a business architecture

Financiële administratie Specifieke toepassingen Kantoor automa- tisering Kennis bank Medewerkers Relaties Objecten Projecten Kerngegevens Scenarioplanning Eindwaarde variant 2 Eindwaarde variant 3 Risicocalculatie Eindwaarde variant 1 Rekenmodel Planning & control Financiële administratie Specifieke toepassingen beheer Presentatie & Communicatielaag Internet Extranet Actuele documenten Post - registratie Document- flow Archief Intranet e-mail Gebouwen- exploitatie Administratie Plan- Grond- Erfpacht administratie Onroerend goed Uren Personeels Relatie Kartografie Representa- vormen object Project planning Example of an information architecture (1)

Example of an information architecture (2)

Example of an information architecture (3)

Relationship between business architecture and information architecture 289GROT1f Presentatie, kantoorautomatisering en communicatie Object/medewerker/relaties Projectadministratie Erfpacht adm. Grondexploitatie Onr. goed adm. Gewenste ondersteunende functies: Financiële administratie Planning en control PKL/RPE/271299 5.1 Uitvoeren economische projecten 5.2 ruimtelijke 6.1 Monitoren afgeronde ruimtelijke en 6.2 Beheren erfpacht- contracten 6.3 onroerend goed *2 Kansen ter verbetering van het woon/werk-, verblijf- en leefklimaat van de stad Rotterdam Tevreden gebruikers van de stad Rotterdam Goedgekeurde (definitief) Gerealiseerde 3.1 Vertalen programma’s naar projecten (i.s.m. partners) 3.2 Toetsen haalbaarheid: - financieel - politiek - mensen - middelen - maatschappelijk draagvlak - etc. 3.3 Voorstel ter politieke besluitvorming uitwerken 3.4 Go/No Go-besluit nemen 4.1 Fasering aanbrengen (i.s.m. partners) 4.2 Uitwerken project- beheersing: - tijd - geld - kwaliteit - informatie - organisatie 4.3 Voorstel ter politieke besluitvorming uitwerken 4.4 Go/No Go-besluit nemen 4.5 Partners en belang- hebbenden informeren over genomen besluit 5.2.1 Verwerven 5.2.2 Ontwikkelen en planbegeleiding 5.2.3 Tijdelijk beheren 5.2.4 Markt bewerken 5.2.5 Uitgeven/verhuren 5.2.6 Evalueren 5.2.7 Overdragen 5.1.1 Partners aanschakelen en binden 5.1.2 Draagvlak creëren 5.1.3 Verwerven & beheren middelen (geld, inspanning, ruimte, etc.) voor uitvoering 5.1.4 Markt bewerken 5.1.5 Uitvoeren geplande activiteiten 5.1.5 Evalueren 5.1.6 Overdragen 6.1.1 Nazorg verlenen 6.1.2 Account- management uitvoeren 6.2.1 Registreren 6.2.2 Factureren 6.2.3 Indexeren 6.2.4 Verwerken mutaties: - heroverwegingen - splitsing - wijzigen bestemmingen 6.3.1 Registreren 6.3.2 Factureren 6.2.4 Verwerken mutaties 1.1 Signaleren kansen (antennefunctie) 1.2 Vertalen kansen naar beleid (i.s.m. partners) 1.3 Toetsen aan gemeentelijke kaders (inclusief Rijks- en provinciale overheid) 1.3 Voorstel ter politieke besluitvorming (m.n. gemeenteraad) 1.4 Go/No Go 2.1 Vertalen beleid naar programma’s (i.s.m. partners) 2.2 Toetsen haalbaarheid: - mensen (capaciteit) - middelen (bijvoorbeeld grond gebouwen) 2.3 Uitwerken programma-beheersing: - tempo - haalbaarheid - efficiency - flexibiliteit - doelgerichtheid 2.4 Voorstel ter politieke besluitvorming uitwerken 2.5 Go/No Go-besluit nemen (kaders) programma’s OBR beleid *1 Hoeft niet per definitie een gevolg te zijn van projecten *2 Bedrijfsruimte Huurcontracten Visrecht Pachten etc. 6. Beheren en monitoren resultaat *1 2. Ontwikkelen 5. 4. Voorbereiden 3. Onderzoeken 1. Beleids- ontwikkeling Stedelijke op het gebied van ruimte en economie

Relationship between business architecture and application architecture

Specifieke toepassingen Financiële administratie Kennis bank Kerngegevens Scenarioplanning Eindwaarde variant 2 Eindwaarde variant 3 Risicocalculatie Eindwaarde variant 1 Rekenmodel Specifieke toepassingen Presentatie & Communicatielaag Actuele documenten Archief Plan- exploitatie Administratie Representa- vormen object Personeels administratie Onroerend goed Erfpacht Gebouwen- Grond- Objecten beheer Project planning Uren Relatie Kartografie Medewerkers Relaties Projecten Kantoor automa- tisering Planning & control Financiële administratie Document- flow Post - registratie Internet e-mail Intranet Extranet Relatie tussen informatie- en applicatie- architectuur

Application architecture

Bas Kruiswijk bkr@tg.nl www.twynstragudde.nl Alle intellectuele eigendomsrechten met betrekking tot deze presentatie berusten bij Twynstra Gudde. Niets uit deze presentatie mag worden verveelvoudigd of openbaar gemaakt zonder schriftelijke toestemming van Twynstra Gudde.