Enterprise Level Architecture Management Part II ... · Enterprise Level Architecture Management...

Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved

W. Keller1

Enterprise Level Architecture Management

Part II: Architecture at anEnterprise Level

Wolfgang Keller, Plattform-Management,Generali Office Service & Consulting AG, Wien

Email: [email protected] http://www.objectarchitects.de/


W. Keller2

Contents• why is software architecture interesting?• levels of architecture for an enterprise level architecture

• domain architecture• application architecture• systems architecture

• what about the silver bullets of the late 80ties• homogeneous approaches versus heterogeneous

architectures• enterprise data models


W. Keller3

one of many definitions for„software architecture“

The software architecture of a program or computing system is the structure or structures of the system,which comprise software components, the externally visible properties of those components,and the relationships among them.

Bass, Clements, and Kazman. Software Architecture in Practice,Addison-Wesley 1997

Why is this interesting?


W. Keller4

software architecture

I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most importantsingle step toward conceptual integrity... After teaching a software engineering laboratory more than 20 times, I came to insist thatstudent teams as small as four people choose a manager, and a separate architect.

Fred Brooks, The Mythical Man-Month (20th Anniversary Edition. 1995)


W. Keller5

pattern alert• this architect or architecture group is essential to your

success• It‘s called „Keeper of the Flame“


W. Keller6

a typical project in the financial industry ..• 60-70 domain app kernel objects,

• like customer, order, order position, employee• 100-200 screens or dialogs• project takes 2-3 years• team size 2 -> 5 -> 10-20 -> 4• budget 2,5 – 7 Mio. Euros• potentially hundreds of users• mission critical app for the core business of your

organization


W. Keller7

why would I need an architecture in such a project?• 15 developers start implementing at a time• 12 of the 15 developers have are fresh from school with

experience in Java but no experience in MVS, COBOL, CICS, Smalltalk or other necessary evils.

• 3 of the 15 developers have experience in more than one project

• despite all this the project is a success• Why?


W. Keller8

why would I need an enterprise level architecture?• lets say you have 5-7 of such projects in your company

at the same time• in different stages• plus you are buying software from third parties

• You need some orientation


W. Keller9

STOP

building architecture• a few architects design the whole building.

• the plan is rather generic and not very detailed and can be reused in many situations

• the detailed plans are specified by project architects with eachproject

• with respect to the detailed functional requirements of the customers

• a herd of construction workers is erecting the new building

• such a process does not make sense for „huts“


W. Keller10

déja vuthings you know most likely ..


W. Keller11

what you might know from literature on software architecture

Electronic Clerk Electronic Clerk Electronic Clerk

Application Kernel

Database Access Layer

Gateways

Presentation Layer

Dialog Control

Input/Output Formats

Batch Control

App

licat

ion

Ser

vice

s


W. Keller12

boxes, boxes, boxes ...• architecture is about

components and their interactions

• but how, when and what should I design?

• where do all those boxes come from?


W. Keller13

and you might know that architectures balance forces like• performance• time to market• total costs of ownership• robustness (fault tolerance)• maintainability• changeability and flexibility • simplicity

• the strength of these forces significantly influences the solution


W. Keller14

you might also know catalogs of architectural styles (a.k.a.patterns)

Data Centered

Repository Blackboard

Call and Return

LayeredProcedural Obj. OrientedInterpreter Rule Based System

Virtual Machine

Data Flow

Batch Sequential Pipes & Filters

Independent Components

Communication Processes

Event Systems

Implicit Invocation Explicit Invocation


W. Keller15

levels of architecture for an enterprise level architecture

what you might not have seen yet ...


W. Keller16

levels of an architecturefor enterprise level architecture

Unter

nehm

ensm

odell

Analy

semod

elle

Fa

charc

hitek

tur

SystemarchitekturSystemarchitektur

Anwendungsarchitektur

Anwendungsarchitektur

ProdProdVertraVertraLeistLeistProvProv

Metamodell

Topologie


W. Keller17

different levels of an architecture describe different things• Domain Architecture

• describes top level domain items and business systems• may optionally split these into coarse grained components• we use o-o domain analysis models• plus domain analysis and architectural patterns

• Application Architecture• divides an application into layers and types of components• defines how layers and components communicate• uses architectural and design patterns

• Systems Architecture• assigns the items of the application architecture to tiers, system

components and the like ..


W. Keller18

how do I develop a software architecture?

• and how do I transform nonfunctional requirements and architectural styles into something useful


W. Keller19

how do I ...

• only a few architectures will ever be constructed on the green field – there has always been someone who has done a similar job before ...

steal!


W. Keller20

plus other things that help ...• Experience

• use known „architectural styles“ and „architectural patterns“

• Think Forces!• and know how to balance them

• Read, read, read ...• and you will find many interesting methods and insights on

architecture ...


W. Keller21

what you need to steal (or invent)to be an enterprise architect


W. Keller22

domain architecture summary• clear vision• mile wide – inch deep map of business systems• use of domain patterns and other patterns

• to communicate the core ideas and pieces• like architectural styles do decide on a coarse architecture• design patterns for dependency management


W. Keller23

Domain Architectureis comparable to• former „Enterprise Level Data Model“

• a common reference model for all applications• is expressed in terms of an object model

• an object model• in order to be usable such a model needs to be split up into subsystems

and components• interfaces are the interesting item• a single class is seldom ever an interesting item or subject of a

discussion

• Generali example has about 1500 elements – more would be possible – but don‘t make sense.


W. Keller24

sample architecture principles: Phoenix

flexible to organizational changes

flexible to organizational changes business process orientationbusiness process orientation

strong competitiveposition

strong competitiveposition product orientationproduct orientation

field and companyindependent solutions

field and companyindependent solutions

model driven software development

model driven software development

optimal quality-/effort rationReUse, Make & Buy

optimal quality-/effort rationReUse, Make & Buy object orientationobject orientation

computer assistancedistributed and flexible

computer assistancedistributed and flexible client/serverclient/server

minimize technical risksminimize technical risks standards and open systems

standards and open systems


W. Keller25

pattern alert• the fewer principles you have the better – we have 3• the simpler they are, the better

• this is called a „Clear Vision“

• that can be understood by everybody in each and every project ...


W. Keller26

hierarchy in a domain architecture• business systems (BS)

• application systems– like product, contract, claims ...

• service systems– like print system, archiving, authorization ...

• subsystems• are a further layer to partition a BS into units that are easy to handle with

clear interfaces and clear responsibilities

• domain classes• are the smallest unit of a domain architecture


W. Keller27

domain architectureapplication systems

GSObjekt

GSVersicherungsprodukt

GSEreignis

GSVersicherungsleistung

GSKonto

GSVermittlervertrag

GSAdresse

GSProvisionsspezifikation

GSPartner

GSProvisionsleistung

GSVersicherungsvertrag


W. Keller28

pattern alert• such a top layer of an architecture is called

„Mile Wide – Inch Deep“• don‘t get lost in details – stay inch deep• but try to cover everything that‘s important – have a

mile wide picture ...


W. Keller29

example: internal structure of a „partner“ business system

politischeGebietelektronisches Gebiet

Die hier modellierte Spezialisierungsebene ist nur exemplarisch dargestellt. Die für ein konkretes Unternehmen relevanteGebietsstruktur muß an die benötigten Informationsstrukturen angpaßt werden.

Gebiet-zu-Gebiet Beziehung

GSAdresse

<<Ableitung>>( )Adresse ermitteln( )Gebiet ermitteln( )abfragbare Attribute ermitteln( )Attributwerte ermitteln( )<<Prüfung>>( )Gebietsprüfung( ) GS Adresse Strukturdarstellung Seite 3.S

GPAdresse

Adresse anlegen( )Adresse bearbeiten( )Gebiet anlegen( )Gebiet bearbeiten( )Gebiet suchen( )

Elementargebiet

geographisches Gebiet

TelefonVerzeichnisandereVerzeichnisse

StrassenUndOrtsVerzeichnisPostleitzahlenverzeichnis

AdresseGebietsbaustein

Gebiet

Kurse

Währungen

StaatLandOrtStraße


W. Keller30

domain architectureother possible artifacts• activities of the business systems

(workflow interface)• class descriptions

• with rather different degree of detail• but this does not really matter

• interaction diagrams and state transitions diagrams for important domain objects


W. Keller31

the rest – application and systems architecture ..

this is a commodity ...


W. Keller32

application architecture• top level of abstraction is a three layer architecture in

most cases • below that people specify what‘s in the layers and also

the service systems• Interactions may be specified using design patterns like

• e.g. MVC, Publish/Subscribe, Singleton etc.

• this times „n“ for back-office, sales laptops, internet, brokers, call-center application and per family of architectures if you buy complete business systems ....


W. Keller33

top layer: 3-layer-architecture

Benutzungsschnittstelle

Geschäftslogik

Daten-Management

Präsentation

Dialog-Kontrolle

ProzeßAnwendungskern

Datenzugriff

Datenbank

Allg

emei

ne D

iens

te


W. Keller34

one level deeper: persistence service for a back office app

BusinessModel

BusinessModel

BusinessBusinessModelModel

Persistency ServicesPersistency ServicesPersistency ServicesPersistency Services

BusinessModel

BusinessModel



BusinessModel

BusinessModel


TOPLinkTOPLinkTOPLinkTOPLink

CICSCICSCICSCICS

DB2/2DB2/2DB2/2DB2/2

DZSDZSDZSDZS

DB2 (Host MVS)DB2 (Host MVS)DB2 (Host MVS)DB2 (Host MVS)


W. Keller35

and yet another level deeper: persistence service• class models

• we will not enter this level of details ....


W. Keller36

sample systems architecture ... one of many

KommunikationDistribution

Geschäftslogik

Datenverwaltung

Server Host

Workflow

DB2

Sm

allta

lk G

UI-

Bui

lder

DB2/2

Smalltalk

3GL 3GL

Middleware CICS-Family

SmalltalkSmalltalk,

3GLSmalltalk

3GL

Smalltalk

PHX WF Client

OS/2 OS/2 MVS

OPCA Batch

3GL

Client


W. Keller37

what about the silver bullets of the late 80ties ...


W. Keller38

enterprise data models• an enterprise data model used to be a data model of

the complete enterprise ...• can be compared to ..

• a domain architecture• minus interfaces and subsystems • minus the functionalities

• used to be enforced by a strong „data police“• underlying model – homogeneous,

monolithic system !!!


W. Keller39

the drawbacks of usingenterprise data models• endless discussion about minor details with a dogmatic

„data police“• does not facilitate „buy“ but promotes „make“

• as you would seldom find a package that could fulfill the dogmatic requirements of the „data police“

• does not facilitate handling of very large systems due to the absence of interfaces and packages

• no dependency management – big ball of something• often very complex and abstract concepts – tough to

understand – far from the KISS principle


W. Keller40

the drawbacks of NOT usingenterprise data models• absence of an enterprise wide data dictionary with

domain data types• trouble at the interfaces when two systems need to be

adapted to each other


W. Keller41

homogeneous approaches• the late 80ties tought us to build one big integrated

system based on one data model


W. Keller42

the drawbacks of usinghomogeneous approaches• very complex• tough to understand• therefore hard to change• no dependency management – one change can have

consequences everywhere in a system• prevents buying other vendors components• ever did a version management for such a beast?• technically outdated before implemented• project durations of 8 years plus not exotic – insane

project risk


W. Keller43

the drawbacks of NOT usinghomogeneous approaches• if you assume that your rate of change ever allows you

to get it implemented, then maintenance cost are claimed to be lower than for heterogeneous approaches ..


W. Keller44

summary: enterprise architecture we have ...• ONE domain architecture (Owner „enterprise domain architect“)

• the domain architecture is an ideal vision – existing system typically have deltas – these deltas can be described if needed ...

• the domain architecture is used as a reference model• very slow rate of change

• for our own software development project we have ONE application architecture (owner: tech chief architect)

• you need very good reasons not to use it• deviations must be argued with critical requirements• buying an off the shelf system is the most common reason for deviations• fast rate slow rate of change – therefore MANY variants are in production

• ONE systems architecture (owner: it operations)• slow rate of change due to high availability and robustness requirements

and high costs of change


W. Keller45

summary ...

good solutions

fullhomogeneity chaos

soft migrationspragmatism


W. Keller46

summary ...

domain architecture

APM target portfolio

technical mappingmigration project

existing apps

middlewarestrategie

new portfolio

next comes

Date post:	31-Mar-2018
Category:	Documents
Upload:	nguyencong
View:	220 times
Download:	3 times

Enterprise Level Architecture Management Part II ... · Enterprise Level Architecture Management...

Documents