Erarbeitung von Blueprints mit Architekturframeworks · Die Methode (Framework) ist rekursiv...

©Competence Center EA/TU Berlin/Dr.-Ing. Marten Schönherr 1

Erarbeitung von Blueprints mit Architekturframeworks

Marten SchönherrTechnische Universität Berlin


Agenda

LernzieleTerminologieEinordnung in das ArchitekturmanagementDefinition nach DIN ISO 15704Typ I FrameworksTyp II FrameworksGERAM als MetaframeworkBeispiel anhand von TOGAFKritische Würdigung zur Verwendung von FrameworksLiteratur

Exkurs: Abgrenzung zu anderen Ansätzen aus SE, Operations und IT-Governance (RUP, ITIL, CobIT)


Lernziele

Überblick über Enterprise Architecture FrameworksModellierung, Sichten und Bestandteile eines FrameworksFrameworks im Kontext des ArchitekturmanagementsDiskussion Aufwand vs. NutzenKomplexitätsproblem


Was sind Blueprints (Blaupausen)?

Bsp. Architektur-Blueprint Internetanwendungen einer Versicherungzzgl. Textdokumentation nach Keller (2006)


Blueprints

beinhalten Standards, state of the art, best practicebietet Referenzarchitekturdifferenziert Sichtenadressiert verschiedene Zielgruppen

IST bzw. SOLL-Zustand der realen Situation einer Firma?

Welche Position im Architekturmanagement?


Architekturmanagement nach Dern

Architekturentwicklung: Operative Projektarbeit

Blaupausen und Referenz-architekturen Projekten zur Verfügung stellenProjektberatungDurchführung von Architekturprojekten

Architekturplanung: Entwicklung und Verfolgung von strategischen Vorgaben

Management der AnwendungslandschaftArchitekturstrategieArchitekturprinzipien definieren

Architekturmanagement

Quelle: Hess sd&m, in Anlehnung an Dern


Ziel Blueprint

Architekturentwicklung über die Erstellung, Abstimmung und Abnahme von BlueprintsSituativ reduziert auf relevante Aspekte, Sichten und ZielgruppenansprücheGestaltung von Abstimmungsprozessen imArchitekturmanagement (Architekturentwicklung) anhand von BlueprintsSichten können in Abhängigkeit der Zielgruppen von abstraktenrein fachlichen Schwerpunkten einer Architektur bis hin zuphysischen Aspekten variierenFunktionale und nicht-funktionale Aspekte werdenunterschiedenEs gehen sowohl IST als auch SOLL Aspekte ein, zumindest istein Ausschluss von IST-Aspekten nicht möglich


Gibt es methodische und generische Grundlagen für die Erstellung von Blueprints?

Welche Aspekte sollen betrachtet werden?Welche Rollen sind typisch?Welche Sichten werden modelliert?…

Enterprise Architecture Frameworks als mögliche Lösung!


Enterprise Architektur Frameworks (EAF)

Enterprise Architecture is„a description (model) of the basic arrangement and connectivity of parts of a

system (either a physical or a conceptual object or entity)“

Typ 1direkte Beschreibung eines GesamtsystemsModell der Strukturen statische Aspekte (Komponenten, Interfaces etc.)

dynamische Aspekte (Beziehung zw. stat. Aspekten)Typ 2

Projekte zur nachhaltigen Veränderung der UnternehmensarchitekturModell der Aktivitäten, Konzepte, Entwicklung und Betrieb der ArchitekturLebenszyklusaspekte aller betroffenen Subsysteme

(ISO 15704, 2000)


EAF

weitere Eigenschaften einer Enterprise Architecture

Architekturregeln und -musterAbstraktion in der Modellierungganzheitliche Betrachtungsweise (nicht IT-spezifisch)Konstruktionsmethoden (Standards, Referenzmodelle etc.)langfristig planender Charakter (Masterplan)


Typ I Architekturelemente

Architektur-Ebenen

Geschäfts-architektur

Prozess-architektur

Applikations-architektur

IT-Architektur

Anwendungsorientierte Sichten

Anwendungs-neutrale Sichten

Standardsoftware-SichtHafner/Winter 2005


Architekturelemente II

Dern, 2003


Architektur - Architekturelemente III

Foegen, 2003


Architektur - Architekturelemente IV

Strategie

Aufbau- Ablauf-

Organisation

Informationsarchitektur

Daten-architektur

Anwendungs-architektur

Kommuni-kations-

architektur

Technologiearchitektur

IS-architektur

Krcmar, 1990

Gemeinsamkeitendiv. Ebenen zwischen Geschäfts-und IT-ArchitekturKausalität zwischen IT- und Unternehmenszielen wird thematisiertGeschäftsprozess nicht identisch zu Prozessen in IT-EbenenStrategische Elemente vorwiegend in den Geschäftsebenen


Vergleich der Ansätze

Krcmar FoegenHafner/Schelp/WinterDern


Zachmann - Architekturanalogie

Analogie zur Architektur, iteratives VorgehenAuftragnehmer-Auftraggeber-Verhältnis (Verständnis)unterstellt Vermutung, dass jedes komplexe Produkt nach diesemMuster erbaut werden kann (Flugzeugbau)


Zachmann

Verallgemeinert drei Rollen (Eigentümer/Auftraggeber, Designer/Architekt, Baumeister)Teilsichten in Abhängigkeit der Rollen und der Phase/fachlicheAspekte des VorhabensTeilmodelle sind auch ohne den Gesamtkontext sinnvoll


Zachmann

3 generische Sichten (Material, Funktion, Ort)Analoge Übertragung in IT-Welt (Daten, Prozess, Netzwerk)Entwirft Matrix mit Rollen und Sichten


(erweiterte) Zachmann Framework I

Deployed softwareDeployed systemDeployed user

interface (including documentation)

Deployed hardware, middleware and

software

Deployed functions/ operations

Classes, components, tables

Functioning System

Implementation of business rules

Implementation of system triggers

Implementation of user interfaces

Protocols, hardware, components,

deployed software items

Implementation design of functions/

operations

Implementation strategy for entities and relationships

Detailed Representation(Builder’s View)

Business rule designSystem triggersUser interface design

Hardware, network, middleware

Program functions/ operations

System representation of

entities and relationships

Technology Model(Designer’s View)

Detailed business rulesSystem events

Actual and potential interactions between

people

Roles played in each location and

relationships between roles

Business functions and tactics

Specific entities and relationships

between them

Model of fundamental Concepts

(Architect’s View)

Goals, objectives, business policiesBusiness events

Positions and relationships

between positions

Offices and relationships

between them

Strategies and high-level business

processes

Business languages used

Enterprise Model(Business Owner’s

View)

Enterprise visionAnnual planningHuman resource philosophies and

strategies

International view of where organization

operatesMissionMost significant

business conceptsObjectives/ Scope

(Planners View)

Motivation(WHY)

Time(WHEN)

People(WHO)

Locations(WHERE)

Activities(HOW)

Structure(WHAT)

Immon, Zachman, Geiger, 1997


Regeln des Zachman Frameworks

Spalten haben keine RangfolgeJede Spalte hat ein einfaches, grundlegendes und eindeutiges Modell(bspw. Daten – Entity und Relationen)Zeilen sind klar abgegrenzt (keine Überschneidungen)Jede Zelle ist einmaligAlle Zellen einer Zeile erzeugen ein komplettes Modell fürdie Interessen/Verantwortlichkeiten dieser RolleDie Methode (Framework) ist rekursiv (belibieg ;-)

Jede Zelle stellt einen eigenen Aspekt der Architektur dar-alle Zellen zusammen bilden die Gesamtarchitektur



Zachman Framework II


Kommuni-kation

Netzwerk-architektur

Hardware-architektur

Verteilte System-architektur

Logistik-netzwerk

Liste geschäfts-funktionen

KnotenVerbin-dungen

FunktionenProgrammFunktions-diagramm

Datenfluß-diagramm

Funktions-baum

Liste Geschäfts-prozesse

Prozess-Beschreibung

DatenDatenbank-system

Datenbank-design

Daten-modell

ERDListe Geschäfts-objekte

EntityRelation

Rechen-zentrum

EntwicklerEntwicklerUser & Ent-wickler

Fachabtlg.Top-Mgmt.Verant-wortung

OperatingImplement-ation

System-design

Pflichten-heft

Geschäfts-design

Ressourcenverteilung

Aufgabe

RunTimeMaschinen-sicht

CodesichtDesignsichtFachsichtGrobsichtSicht

Kommuni-kation

Netzwerk-architektur

Hardware-architektur

Verteilte System-architektur

Logistik-netzwerk

Liste geschäfts-funktionen

KnotenVerbin-dungen

FunktionenProgrammFunktions-diagramm

Datenfluß-diagramm

Funktions-baum

Liste Geschäfts-prozesse

Prozess-Beschreibung

DatenDatenbank-system

Datenbank-design

Daten-modell

ERDListe Geschäfts-objekte

EntityRelation

Rechen-zentrum

EntwicklerEntwicklerUser & Ent-wickler

Fachabtlg.Top-Mgmt.Verant-wortung

OperatingImplement-ation

System-design

Pflichten-heft

Geschäfts-design

Ressourcenverteilung

Aufgabe

RunTimeMaschinen-sicht

CodesichtDesignsichtFachsichtGrobsichtSicht

StrategischeZiele

BusinessModell IS-Modell Technolog.

ModellDetail-

beschreibungPhysisches

System

Daten

Prozesse

Netzwerk


Zachmann- Rekursivität

Framework kann auf beliebig vielen Ebenen abstrahiertangewendet werdenDadurch ercsheint es flexibel aber auch sehr allgemeinGuter allgemeiner Rahmen – in der Praxis oft zu unspezifisch


ARIS

BetriebswirtschaftlicheMethodeBasiert auf Modellierungvon GP4 Sichten – 3 EbenenLebenszyklusaspektestark vereinfachtFachkonzept ist stabil13 Betrachtungsfeldereigene Notation (EPK, eEPK, VKD …)eigenes ToolsetCa. 150 NotationenNur begrenzt als Typ II Architektur einsetzbar

Betriebswirtschaftliche Problemstellung

Implementierung

DV Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Datensicht Steuerungssicht Funktionssicht


GRAI GIM

Seit 70iger Jahren an LAP UNI Bordeaux/Frankreich zum ThemaArchitekturmodellierung (GRAI)Seit Ende 80iger mitintegrierender Methodologie GIMFokus produzierende Industrie(CIM)4 Grundelemente- Referenzmodell- Modellierungsframework- Modellierungsregeln- Vorgehensweise (s. Abb.)Entscheidungsprozesse werdeni.V. zu anderen Frameworks hervorgehoben

Detection ofInconsistencies

Initialization

Informational ViewDesign

Decisinal ViewDesign

Functional ViewDesign

Physical ViewDesign

InformationDesign

OrganizationDesign

ManufacturingDesign

Informational ViewAnalysis

Decisinal ViewAnalysis

Funtional ViewAnalysis

Physical ViewAnalysis

Definition of the Domain

Implementation

UserRequirements

Technical orientedSpecification

User OrientedSpecification

Consolidated UserRequirements

ExistingSystem

NewSystem

Detection ofInconsistencies

Initialization

Informational ViewDesign

Decisinal ViewDesign

Functional ViewDesign

Physical ViewDesign

InformationDesign

OrganizationDesign

ManufacturingDesign

Informational ViewAnalysis

Decisinal ViewAnalysis

Funtional ViewAnalysis

Physical ViewAnalysis

Definition of the Domain

Implementation

UserRequirements

Technical orientedSpecification

User OrientedSpecification

Consolidated UserRequirements

ExistingSystem

NewSystem


GRAI GIM

Unterscheidet 3 Elemente- physisches System (Material i.S. einer Produktion) – Schwerpunktesind hier Simulation und Planung- Entscheidungssystem differenziert vom physischen System abhängige bzw. unabhängige Entscheidungen- Informationssystem beliefert Entscheidungssystem

GRAI verwendet eigene Modellierungsnotationen

Entscheidungsprozesse werden mit- GRAI Grid globale Sicht (Mgmnt.) - Top-Down- GRAI Nets detallierte Instanzmodellierung - Bottum Up

GIM erweitert GRAI um Informationen (Daten +), Funktionen (Objekte) und physische Ebene (IT-Infrastruktur)

GIM fokussiert auf frühe Lebenszyklusaspekte(Design Time)- Anforderungen- Systemdesign


CIMOSA

Generation of views

GenericLevel

PartialLevel

ParticularLevel

Instantiation ofBuilding blocks

Derivationof models

Organization

Resource

Information

Function

ReferenceArchitecture

RequirementsDefinition Model

Design Speci-fication Model

ImplementationDescription Model

Computer Integrated Manufacturing Open System Architecture

1984 ESPRITeurop. Forschungsprojekt

ca. 10 Jahre

Framework für wandelungsfähigeIT-Systeme in CIM

CIMOSA besteht aus:- Mod.-framework- Integrations-

infrastruktur- Systemlebenszyklus

Implementierungs-unabhängigesFachkonzept

Mod.-framework differenziertArchitektur, Modelle und Sichten

Architektur von Referenz- nachindividueller Architektur

Modellebene stelltLebenszyklusaspekte von SW-Projekten dar

Sichten sind:- Organisation- Ressourcen- Informationen- Funktionen


CIMOSA

eigene Toolseigene und bekannteNotationen (UML, IDEF, ERD)Integrationsinfrastrukturführt Modell aus Framework rechnerbasiert als GPM aus(Modellinterpreter s. Abb.)kein Industriestandardaber Grundlage mehrererNormen(Enterprise Modelling EM, Constructs for EM)

release

ParticularEnterprise Model

Particular ImplementationDescription Model

Integration Infrastructure

Enterprise Operation Resources

ManagementEntity

BusinessEntity

CommonEntity

PresentationEntity

InformationEntity

Information TechnologyResources

ManufacturingResources


DoDAF

Department of Defense Architecture Framework

lange Historie im Department of Defense TAFIM, JTA, DoDTRM, C4ISR – seit 80iger Jahren

Ziele aller Ansätze: Stabilität, Interoperabilität und Kommunikation aller beteiligten Systemeder Streitkräfte im Einsatz

DoDAF direkt aus C4ISR

definiert Richtlinien zur Gesamtarchitekturbeschreibung und –modellierung

keine Designvorgaben für die Entwicklung oder Richtlinien zum Einkauf von Systemen

besteht aus 3 Dokumenten- Teil I beschreibt Architekturmodellierung und deren Sichten sowie die zu erreichenden Ziele- Teil II beschreibt die zu verwendenden Notationen ausführlich- Teil III (nachgereicht) beschreibt anhand praktischer Bsp. die Umsetzung von I & II

DoDAF differenziert 4 Sichten:- Operational (Menschen, Strukturen, Prozesse etc.)- Systems (entsprechende Systeme)- Technical Standards (detaillierte Beschreibung Systemkomponenten)- All (Zusammenhänge der drei ersten Sichten)

26 Methoden zur Architekturbeschreibung

eigene Notationen (basierend auf IDEF1) und UML

Core Architecture Data Model (CADM )

alle Daten relational (Verwaltung in DB´s)


DoDAF


PERA

Purdue Enterprise Architecture FrameworkReferenzmodell für CIM alsHerkunftVorgehen für CIM entwickeltund gleichzeitigReferenzmodell verbessertPERA teilt in IST (as is) und SOLL (to be) und schlägtMasterplan für die Überführung vorBranchenneutralSchlägt 28 Zustände imLebenszyklus vorSpezifiziert für alle ZuständeAspekte der ElementeResourcen, Menschen/Orga & ITKeine Vorgabe von Notationen bzw. Tools


Elemente der Modellierung in PERA


TOGAF - Struktur

The Open Group Architectural FrameworkOnline verfügbar, open source Lizenz

Part I IntroductionPart II Architecture Development Method (ADM)Part III Enterprise ContinuumPart IV Resources


TOGAF - Definitionen

TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture. It is described in a set of documentation published by The Open Group on its public web server, and may be used freely by any organization wishing to develop an enterprise architecture for use within that organization.

Enterprise Architecture differentiates:- Business (Process) Architecture- Data Architecture- Application Architecture- Technology Architecture.


TOGAF Definitionen – Architektur I

Architecture (Grundlage für TOGAF):

The definition of an architecture used in ANSI/IEEE Std 1471-2000 is:

“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.

TOGAF spezifiziert

Architecture has two meanings depending upon its contextual usage:

- A formal description of a system, or a detailed plan of the system at component level to guide its implementation.

- The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.


TOGAF Definitionen – Architektur II

An architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.

An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.


TOGAF Definitionen – Architektur III

Enterprise ArchitectureThe primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy

EA FrameworkUsing an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.


Part II Architecture Development Method

Reihenfolge definiert, iterative Abarbeitung empfohlen, allerdings Rückkoplung und spätere Anpassung möglich

jeweils definiert:- Objectives- Approach- Inputs- Steps- Outputs

Req. Mngmt. Als zentralerProzess definiert und Templates vorgeschlagen

http://www.volere.co.uk/template.htm


Part II ADM

jede Phase der Methodeist detailliertbeschriebenModellierungs- und Dokumentations-konstrukte sind definiert

http://www.opengroup.org/architecture/togaf8-doc/arch/


Part III Enterprise Continuum

Introduction The Enterprise Continuum in Detail

Architecture Continuum Solutions Continuum Enterprise Continuum and Your Organization

TOGAF Foundation Architecture: Technical Reference ModelTRM Concepts High-level Breakdown TRM in Detail Detailed Platform Taxonomy

TOGAF Foundation Architecture: Standards Information BaseIntroduction Open Group Standards Using the SIB and Linked Resources

TOGAF Integrated Information Infrastructure Reference Model Basic Concepts High-Level View Detailed Taxonomy


Enterprise Continuum

Hilfswerk zur Unterstützung des Architekturentwicklungsprozesses:

- enthält wieder verwendbare Referenzmodelle, Modelle, Muster, Beschreibungen

- TOGAF hat ein Standart Kontinuum, dieses dient Unternehmen als anzupassende Basis um ein unternehmensbezogenes Kontinuum aufzubauen

- Komponenten TOGAF Kontinuum:- TRM =Technical Reference Model- SIB = Standart Information Base- III-RM = Integrated Information Infrastructure Reference Model


Part III Enterprise Continuum

Kontextuelle Einordnung/Verortung des jeweiligen BeteiligtenFehlerfreie Kommunikation zwischen BeteiligtenParadigma der unterschiedlichen Betrachtungsebenen einerEnterprise Architecture


Technisches Referenzmodel

Grobe Struktur Verfeinerte Struktur


TRM

TRM =Technical Reference Model:

- beinhaltet Taxonomie, mit Hilfe welcher Diskussion über Informationssysteme/-architekturen auf einheitlicher Begriffsbasis stattfinden können

- beinhaltet ein Model, welches allgemeine Komponenten eines Systems darstellt- anhand dieses können unternehmenseigene Informationssysteme/-architekturen entwickelt werden

- Grobe Struktur:- Anwendungsportabilität ermöglichen (Definition Standartservices die

durch Anwendungsplattform zu Verfügung gestellt werden müssen)- Interoperabilität (Anwendung unabhängig von

Kommunikationsumgebung > Standartdienste mit denen Plattform umgehen können muss)

- Verfeinerte Struktur- Nennung von Servicekategorien


Integrated Information Infrastructure Reference Model


III-RM

III-RM = Integrated Information Infrastructure Reference Model(-> Model noch im Aufbau)

- Überschneidet sich mit dem TRM, jedoch liegt beim III-RM der Schwerpunkt bei den Anwendungskomponenten und der Anwendungssoftware

- Ziel ist das ermöglichen das Information ohne Einschränkungen schnell verschiedenen Bereichen verfügbar gemacht werden kann.(Kurzfristiges Zusammenstellen eines Expertenteams aus verschiedenen Bereichen > Zugang zu Informationen aus den einzelnen Bereichen muss zeitnah möglich sein)


Part IV Resources

Architecture BoardArchitecture ComplianceArchitecture ContractsArchitecture GovernanceArchitecture Maturity ModelsArchitecture PatternsArchitecture PrinciplesArchitecture Skills Framework

weiterhin Cases, Glossar, EA Tools, Mapping mit anderenEA (Zachmann)


GERAM – Framework Components

Elemente eines EA FrameworksEngineering MethodenModellierungssprachenGenerische ElementePartielle ModelleSpezifische ModelleToolsModuleOperationale IT-Systeme

ISO, 15740, 2000

GERAGeneralised EnterpriseReference ArchitectureIdentifies concepts of Enterprise Integration

EEMEnterprise Engineering

MethodologyDescribe processes ofEnterprise Engineering

GEMCsGeneric Enterprise Modeling

Conceptsdefine the meaning ofmodeling constructs

EMOsEnterprise Modules

provide implementablemodules

EMsEnterprise Models

Enterprise models tosupport analysis & operation

PEMsPartial Enterprise ModelsProvide reusable refrence

models

EETsEnterprise Engineering

ToolsSupport of

Enterprise Engineering

EMLsEnterprise Modeling

LanguagesModeling constructs forHuman, process & IT

EOSEnterprise operational

Systemssupport the operation of a

particular Enterprise

employs utilise

used to build

used to implement

support

implemented in

GERAGeneralised EnterpriseReference ArchitectureIdentifies concepts of Enterprise Integration

EEMEnterprise Engineering

MethodologyDescribe processes ofEnterprise Engineering

GEMCsGeneric Enterprise Modeling

Conceptsdefine the meaning ofmodeling constructs

EMOsEnterprise Modules

provide implementablemodules

EMsEnterprise Models

Enterprise models tosupport analysis & operation

PEMsPartial Enterprise ModelsProvide reusable refrence

models

EETsEnterprise Engineering

ToolsSupport of

Enterprise Engineering

EMLsEnterprise Modeling

LanguagesModeling constructs forHuman, process & IT

EOSEnterprise operational

Systemssupport the operation of a

particular Enterprise

employs utilise

used to build

used to implement

support

implemented in


Lebenszyklusaspekte

DesignPreliminary design

Detailed design

Identification

Concept

Requirements

Implementation

Operation

Decommissionlife-

cycl

e ph

ases

ISO, 15740, 2000


Projekte

ISO, 15740, 2000


Detailed design

Identification

Concept

Requirements

Implementation

Operation

Decommission

Life-cycle phases

Enterprise Operation

Time

Decommissioningproject

Enterprise EngineeringProjects

Redesign/continuous improvementproject


Detailed design

Identification

Concept

Requirements

Implementation

Operation

Decommission

Life-cycle phases

Enterprise Operation

Time

Decommissioningproject

Enterprise EngineeringProjects

Redesign/continuous improvementproject


Lebenszyklus unterschiedlicher Elemente

designpreliminary design

detailed design

identification

concept

requirements

implementation

operation

decommission

operation {

entity Aentity B

ISO, 15740, 2000


Generische Entities

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Strategic Management

Entity

Entity Type 1

Engineering Implementation

Entity

Entity Type 2

Initiates, defines,supports

Develops, builds

Enterprise Entity

Entity Type 3

ProductEntity

Entity Type 4

Preliminary design

Detailed design

Identification

Concept

Requirements

Design

Operation

Decommissioning

Implementation

MethodologyEntity

Entity Type 5

Establishes Task 1

Task 2

Task 3

Task 4

Supports

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Develops, builds

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Design

Design

Design

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation


Entity

Entity Type 1


Entity

Entity Type 1


Entity

Entity Type 2


Entity

Entity Type 2

Initiates, defines,supports

Develops, builds

Enterprise Entity

Entity Type 3

Enterprise Entity

Entity Type 3

ProductEntity

Entity Type 4

ProductEntity

Entity Type 4

Preliminary design

Detailed design

Identification

Concept

Requirements

DesignDesign

Operation

Decommissioning

Implementation

MethodologyEntity

Entity Type 5

MethodologyEntity

Entity Type 5

Establishes Task 1

Task 2

Task 3

Task 4

Supports

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

Develops, builds

Preliminary design

Detailed design

Identification

Concept

Requirements

Operation

Decommissioning

Implementation

DesignDesign

DesignDesign

DesignDesign

ISO, 15740, 2000


vom Referenzmodell zum konkreten Modell

Instantiation

Life-cyclephases

Views


Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

Reference Architecture

Particular Architecture

GenericPartial

Particular

ISO, 15740, 2000


Bsp.

{

HardwareSoftware

Instantiation

Management Customer service

HumanMachine

Life-cyclephases

Views

}

}}

GenericPartialParticular{

}


Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

ResourceOrganisationInformationFunction

}

Reference Architecture Particular Architecture

accordingSubdivision

to genericity

according to purposeSubdivision

of activity

according to physical manifestation

Subdivision

according toSubdivision

model content

to means ofSubdivision according

implementation

and control

{{

HardwareSoftware

Instantiation

Management Customer service

HumanMachine

Life-cyclephases

Views

}

}}

GenericPartialParticular{

}


Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

ResourceOrganisationInformationFunction

}

Reference Architecture Particular Architecture

accordingSubdivision

to genericityaccordingSubdivision

to genericity

according to purposeSubdivision

of activityaccording to purposeSubdivision

of activity

according to physical manifestation

Subdivisionaccording to physical manifestation

Subdivision

according toSubdivision

model contentaccording toSubdivision

model content

to means ofSubdivision according

implementationto means ofSubdivision according

implementation

and control

{

ISO, 15740, 2000


Fazit

Es gibt kein perfektes Typ II FrameworkEs gibt keinen StandardVorteil ist die VollständigkeitNachteil der AufwandFokussieren auf individuelle Ziele und daraus die notwendigen Elemente erarbeitenGERAM ist nicht für die praktische Anwendung!Metaframework um eigenes bzw. bekanntes Framework zu bewerten

Blueprints sind als Projekt gedacht – EAF sollte als permanente Größe betrachtet werdenAllerdings werden i.d.R. auch permanent IT-Projekte gemacht, daher die Frage, ob ein Framework nicht doch denkbar istKompetenz bezgl. EAF hilft sicherlich, um Blueprints zu erstellen


(weiterführende) Literatur

Aier, S. and D.-I. M. Schönherr, Eds. (2005). Unternehmensarchitekturen und Systemintegration. Enterprise Architecture. Berlin, GITO.Aier, S. and M. Schönherr, Eds. (2004). Enterprise Application Integration – Serviceorientierung und nachhaltige Architekturen. Enterprise Architecture. Berlin, Gito.Athena-Project: State of the Art in Enterprise Modelling Techniques and Technologies to Support Enterprise Interoperability. http://www.athena-ip.org/components/com_docman/dl2.php?archive=0&file=REExMTEtU290QS12MS5wZGY=Burke, B. (2003). "Enterprise Architecture or City Planning?" Retrieved 31.12.2004, 2004, fromhttp://www.eacommunity.com/articles/openarticle.asp?ID=1864Dern, G. (2003). Management von IT-Architekturen – Informationssysteme im Fokus von Architekturplanung und -entwicklung. Wiesbaden, Vieweg.Foegen, M. (2003). "Architektur und Architekturmanagement – Modellierung von Architekturen und Architekturmanagement in der Software-Organisation." Retrieved 18.04.2005, 2005, fromhttp://www.wibas.de/download/architekturundarchitekturmanagement.pdfHafner, M., J. Schelp, et al. (2004). "Architekturmanagement als Basis effizienter und effektiver Produktion von IT-Services." HMD 41(237): S. 54–66.Hafner, M. and R. Winter (2005). Vorgehensmodell für das Management der unternehmensweiten Applikationsarchitektur. Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. O. K. Ferstl and E. J. Sinz. Heidelberg, Physica: S. 627–646.Horn, E. and T. Reinke (2002). Softwarearchitektur und Softwarebauelemente: Eine Einführung für Softwarearchitekten. München, Wien, Hanser.Keller, W. (2006). IT-Unternehmensarchitektur. Von der Geschäftsstrategie zur optimalen IT-Unterstützung. Dpunkt Verlag.Krcmar, H. (1990). "Bedeutung und Ziele von Informationssystem-Architekturen." Wirtschaftsinformatik 32(5): S. 395–402.Krüger, S. and J. Seelmann-Eggebert (2003). IT-Architektur-Engineering – Systemkomplexität bewältigen, Kosten senken, Potenziale freisetzen. Bonn, Galileo Press.


Exkurs: IT-Standards


Überblick


Abgrenzung

Reifegradstufe

Zeitpunkt im Software-Lifecycle

Abdeckungstiefe

Idee Disposal

Prozess-durchführung

Metriken

Projekt-/ Vorhabens-management

Gesamt-unternehmen

Standard-prozess

Prozess-optimierung / KVP

Einzelvorhaben

oberflächlich

vollständig

ITIL

Anforderungs-management ITIL

SPICE SPICE

SPICE

Unternehmensgrenzen Kunde - Entwickler - Betreiber

Vorgehensmodell(z.B. V-Modell XT)


Exkurs – COBiTControl Objectives for Information and related Technology


Themen* Strategie und Taktik für die IT-

Unterstützung* Erfüllung der Geschäftsanforderungen* Ausreichend geplant, kommuniziert und

“gemanaged”* Korrekte organisatorische und

technische Infrastruktur

Themen* Realisierung der IT-Strategie* Lösungen identifiziert, entwickelt oder

beschafft und implementiert* Lösungen in den Geschäftsprozess

integriert* Änderung und Unterhalt von Systemen

Themen* Effektive Ablieferung benötigter

Dienstleistungen* Wirklich sicherer Betrieb inkl. Training* Aufstellung von Unterstützungsprozessen* Effektive Datenverarbeitung durch

Anwendungen

Themen* Regelmässige Beurteilung aller IT-

Prozesse* Einhaltung und Qualität der Kontrollen

Geschäftsprozesse

IT-Ressourcen

Kriterien (Ziele) • Vertraulichkeit • Verfügbarkeit • Integrität • Verlässlichkeit • Effektivität • Effizienz • Einhaltung r.E.

Überwachung

Betrieb &Unterstützung

Beschaffung &Implementation

Planung &Organisation

• Daten • Anwendungen • Technologien • Anlagen • Personal

COBIT-FrameworkGeschäftsprozesse <> IT-Ressourcen

Control Objectives for Information and related Technology


IT-Governance“Definition”

IT-Governance bedeutet:Die IT ist ausgerichtet auf die Geschäftstätigkeit, ermöglicht diese und maximiert dabei den NutzenIT-Ressourcen werden vernünftig (wirtschaftlich) verwendetIT-bezogene Risiken werden angemessen “gemanaged”

IT-Governance bedeutet:Die IT ist ausgerichtet auf die Geschäftstätigkeit, ermöglicht diese und maximiert dabei den NutzenIT-Ressourcen werden vernünftig (wirtschaftlich) verwendetIT-bezogene Risiken werden angemessen “gemanaged”

IT-Governance ist ein umfassender Begriff, enthaltend:

Technologien und Kommunikation für Informationssystemegeschäftliche, rechtliche und andere Themenalle betroffenen Stakeholder wie Direktoren, das obere Management, die Eigner von Prozessen, Anwender, IT-Lieferanten, Revisoren, …

IT-Governance ist ein umfassender Begriff, enthaltend:

Technologien und Kommunikation für Informationssystemegeschäftliche, rechtliche und andere Themenalle betroffenen Stakeholder wie Direktoren, das obere Management, die Eigner von Prozessen, Anwender, IT-Lieferanten, Revisoren, …


Elemente von COBIT (3rd ed)6 Module plus CD-ROM

Implementation Tool Set

Executive Summary

Framework

Control Objectives

Audit Guidelines

Management Guidelines

Critical Success FactorKey Goal Indicator Key

Performance Indicator Maturity Model

Senior Executives (CEO, CIO)

“There is a Method...”

Senior Operational Management

“The Method Is...”

Middle Management

“Minimum Controls Are...”Line Management, Controls Practitioner

“Here’s How You Audit...”Director, Middle Management

“Here’s How You Measure...”

Director, Middle Management

“Here’s How You Implement...”


In COBIT integrierte Quelleninsgesamt 41 nationale und internationale Standards

Technische Standards von ISO, EDIFACT, usw.Codes of conduct herausgegeben durch EU, OECD, ISACA, usw.Qualifikationskriterien für IT-Systeme und -Prozesse: ITSEC, TCSEC, ISO 9000, SPICE, TickIT, ITIL , Common Criteria, usw.Berufsstandards in interner Kontrolle und Revision: COSO Report, IFAC, AICPA, IIA, ISACA, PCIE, GAO Standards, usw.Industrie-Praktiken und Anforderungen von Industrie-gremien (ESF, I4) und staatlich-gesponsorten Plattformen (IBAG, NIST, DTI), usw.Neue industrie-spezifische Anforderungen aus den Umfeld Banken, Electronic Commerce und IT-Herstellern


Unterschiedliche

Prozessebenen

Geschäftsprozesse

EingabeVerarbeitung

Rein applikationsabhängige Betrachtung

Ausgabe

Einbezug applikationsunabhängiger Themen

IT-Prozesse

IT-Ressourcen

Geschäftsprozesse

IT-Ressourcen

Kriterien (Ziele) • Vertraulichkeit • Verfügbarkeit • Integrität • Verlässlichkeit • Effektivität • Effizienz • Einhaltung r.E.

Überwachung

Betrieb &Unterstützung

Beschaffung &Implementation

Planung &Organisation

• Daten • Anwendungen • Technologien • Anlagen • Personal


Themen* Strategie und Taktik für die IT-Unterstützung* Erfüllung der Geschäftsanforderungen* Ausreichend geplant, kommuniziert und “gemanaged”* Korrekte organisatorische und technische Infrastruktur

IT-Domain

Planung & Organisation

PO1 Definition eines strategischen Plans für IT PO2 Definition der InformationsarchitekturPO3 Bestimmung der technologischen RichtungPO4 Definition der IT-Organisation und ihrer BeziehungenPO5 Verwaltung der IT-InvestitionenPO6 Kommunikation von Unternehmenszielen und -richtungPO7 PersonalwesenPO8 Sicherstellung der Einhaltung von externen AnforderungenPO9 RisikobeurteilungPO10 ProjektmanagementPO11 Qualitätsmanagement


Themen* Realisierung der IT-Strategie* Lösungen identifiziert, entwickelt oder beschafft und implementiert

* Lösungen in den Geschäftsprozess integriert* Änderung und Unterhalt von Systemen

IT-Domain

Beschaffung & Implementation

BE1 Identifikation von automatisierten LösungenBE2 Beschaffung und Unterhalt von AnwendungssoftwareBE3 Beschaffung und Unterhalt der technischen ArchitekturBE4 Entwicklung und Unterhalt von IT-Verfahren BE5 Installation und Akkreditierung von SystemenBE6 Änderungswesen


Themen* Effektive Ablieferung benötigter Dienstleistungen

* Wirklich sicherer Betrieb inkl. Training* Aufstellung von Unterstützungsprozessen* Effektive Datenverarbeitung durch Anwendungen

IT-Domain

Auslieferung & Unterstützung

AU1 Definition und Management von DienstleistungsgradenAU2 Handhabung der Dienste von DrittparteienAU3 Leistungs- und KapazitätsmanagementAU4 Sicherstellen der kontinuierlichen DienstleistungAU5 Sicherstellen der SystemsicherheitAU6 Identifizierung und Zuordnung von KostenAU7 Aus- und Weiterbildung von BenutzernAU8 Unterstützung und Beratung von IT-KundenAU9 KonfigurationsmanagementAU10 Umgang mit Problemen und VorfällenAU11 Verwaltung von DatenAU12 Verwaltung von EinrichtungenAU13 Management der Produktion


Themen* Regelmässige Beurteilung aller IT-Prozesse* Einhaltung und Qualität der Kontrollen

IT-Domain

Überwachung

Ü1 Überwachung der ProzesseÜ2 Beurteilung der Angemessenheit der internen KontrollenÜ3 Erlangen einer unabhängigen BestätigungÜ4 Für eine unabhängige Revision sorgen


Informationskriterien IT-Ressourcenx Effektivität

x Effizienz

x Vertraulichkeit

x Integrität

x Verfügbarkeit

x Einhaltung rechtlicher Erfordernisse

x Zuverlässigkeit

x Personal

x Anwendungen

x Technologie

x Anlagen

IT-Prozesse x Daten

PO1 Definition eines strategischen Plans für IT P S

PO2 Definition der Informationsarchitektur P S S S

PO3 Bestimmung der technologischen Richtung P S

PO4 Definition der IT-Organisation und ihrer Beziehungen P S

PO5 Verwaltung der IT-Investitionen P P S

PO6 Kommunikation von Unternehmenszielen und -richtung P S

PO7 Personalwesen P P

PO8 Sicherstellung der Einhaltung von externenAnforderungen P P S

PO9 Risikobeurteilung S S P P P S S

PO10 Projektmanagement P P

PO11 Qualitätsmanagement P P P S

BE1 Identifikation von automatisierten Lösungen P S

BE2 Beschaffung und Unterhalt von Anwendungssoftware P P S S S

BE3 Beschaffung und Unterhalt der technischen Architektur P P S

BE4 Entwicklung und Unterhalt von IT-Verfahren P P S S S

BE5 Installation und Akkreditierung von Systemen P S S

BE6 Änderungswesen P P P P S

AU1 Definition und Management von Dienstleistungsgraden P P S S S S S

AU2 Handhabung der Dienste von Drittparteien P P S S S S S

AU3 Leistungs- und Kapazitätsmanagement P P S

AU4 Sicherstellen der kontinuierlichen Dienstleistung P S P

AU5 Sicherstellen der Systemsicherheit P P S S S

AU6 Identifizierung und Zuordnung von Kosten P P

AU7 Aus- und Weiterbildung von Benutzern P S

AU8 Unterstützung und Beratung von IT-Kunden P P

AU9 Konfigurationsmanagement P S S

AU10 Umgang mit Problemen und Vorfällen P P S

AU11 Verwaltung von Daten P P

AU12 Verwaltung von Einrichtungen P P

AU13 Management der Produktion P P S S

Ü1 Überwachung der Prozesse P P S S S S S

Ü2 Beurteilung der Angemessenheit der internen Kontrollen P P S S S P S

Ü3 Erlangen einer unabhängigen Bestätigung P P S S S P S

Ü4 Für eine unabhängige Revision sorgen P P S S S P S

P = primäre KriterienS = sekundäre Kriterien

= anwendbar

IT-Res

source

n

Qualität

Rechnungslegung

Sicherheit

Informationskriterien

IT-P

roze

sse

Pers

onal

Anw

endu

ngen

Dat

en

Tech

nolo

gien

Anla

gen

Domain

Prozesse

Aktivitäten

IT-ProzesseEinbettung im COBIT-Würfel

34 IT-Prozesse4 Domains34 Prozesse318 Aktivitäten

7 InformationskriterienEffektivitätEffizienz VerlässlichkeitEinhaltung r.E.VertraulichkeitVerfügbarkeitIntegrität

5 IT-RessourcenPersonalAnwendungenTechnologieAnlagenDaten


The

Tech

nolo

gy

Service Management

Exkurs: Betriebsmanagement - ITIL

Quelle: OGC, 2005

The

Busi

ness

Planning to implement Service Management

BusinessPerspective

ServiceDelivery

ServiceSupport

ITInfrastructureManagement

Suppliers

ApplicationManagement

Supply ChainManagement

SecurityManagement


ITIL – IT Infrastructure Library www.itil.co.uk

Entworfen vom Office of Government Commerce (OCG) mit dem Ziel die IT-Services der brit. Ministerien zu verbessern und zu standardisieren (1980iger Jahre)Danach weiterentwickelt von Praktikern aus aller Welt (Schwerpunkt Europa und Kanada)Heute verbreitete nicht offizielle Zertifizierung von IT-Services (nur de-facto Standard im Vgl. zu bspw. ISO 900*)Wird offen zugänglich weiterentwickelt und ist weiterhin offiziell im Besitz der brit. Regierung


Merkmale des Frameworks

generisches (nicht proprietäres sprich anbieterabhängiges) Rahmenwerk, das öffentlich verfügbar istdefiniert IT-Prozesse (Vorsicht: weites undifferenziertes Feld)branchen- und technologieneutralbasiert auf Best Practicelehnt sich stark an ISO 900* an (Qualitätsmanagement für IT-Services)


Definition

Was ist ITIL?ITIL is best practice in IT Service Management, developedby OGC and supported by publications, qualifications and an international user group.ITIL is intended to assist organisations to develop a framework for IT Service Management. Worldwide, ITIL isthe most widely used best practice for IT Service Management.Current editions of the ITIL library can be purchased in printor CD format or as an intranet licence.


IT Service Mgmnt.

Was ist IT Service Mgmnt.?IT Service Management is a top-down, business driven

approach to the management of IT that specificallyaddresses the strategic business value generated by the IT organisation and the need to deliver a high quality IT service. IT Service Management is designed to focus on thepeople, processes and technology issues that IT organisations face.


Ziele

reduced costsimproved IT services through the use of proven best practice processesimproved customer satisfaction through a more professional approach to servicedelivery improved delivery of third party services through the specification of ITIL or BS15000 as the standard for service delivery in services procurements.standards and guidanceimproved productivityimproved use of skills and experience

KeyLDO GmbH


Wo steht es beschrieben?

Service SupportService DeliveryPlanning to Implement Service ManagementApplication ManagementICT Infrastructure ManagementSecurity ManagementSoftware Asset ManagementThe Business Perspective: The IS View on DeliveringServices to the Business


Service Support & Service Delivery

Incident ManagementProblem ManagementConfiguration ManagementChange ManagementRelease Management

Service Level ManagementAvailability ManagementCapacity ManagementIT-Service ContinuityManagementFinancial Management of IT-Services


ITIL Bestandteile Prozessbeschreibung

Definition der Grundbegriffe (http://www.get-best-practice.co.uk/glossary.aspx?product=ictinfrastructurelibrary)

ZieleProzessbeschreibungAktivitäten(bspw. Fehleraufnahme, Klassifikation, Prüfen, Beheben etc.)Steuerungsgrößen(Berichte, Leistungsindikatoren, beteiligte Rollen etc.)Barrieren und Kosten


Incident Management Prozess

dv-werk.de

Erarbeitung von Blueprints mit Architekturframeworks · Die Methode (Framework) ist rekursiv...

Documents

Transcript of Erarbeitung von Blueprints mit Architekturframeworks · Die Methode (Framework) ist rekursiv...