Enterprise Level Architecture Management Part II ... · Enterprise Level Architecture Management...
-
Upload
nguyencong -
Category
Documents
-
view
220 -
download
3
Transcript of 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/
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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?
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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)
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller5
pattern alert• this architect or architecture group is essential to your
success• It‘s called „Keeper of the Flame“
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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?
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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“
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller10
déja vuthings you know most likely ..
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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?
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller15
levels of architecture for an enterprise level architecture
what you might not have seen yet ...
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 ..
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller18
how do I develop a software architecture?
• and how do I transform nonfunctional requirements and architectural styles into something useful
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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!
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 ...
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller21
what you need to steal (or invent)to be an enterprise architect
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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.
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 ...
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller27
domain architectureapplication systems
GSObjekt
GSVersicherungsprodukt
GSEreignis
GSVersicherungsleistung
GSKonto
GSVermittlervertrag
GSAdresse
GSProvisionsspezifikation
GSPartner
GSProvisionsleistung
GSVersicherungsvertrag
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 ...
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller31
the rest – application and systems architecture ..
this is a commodity ...
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 ....
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller34
one level deeper: persistence service for a back office app
BusinessModel
BusinessModel
BusinessBusinessModelModel
Persistency ServicesPersistency ServicesPersistency ServicesPersistency Services
BusinessModel
BusinessModel
BusinessBusinessModelModel
BusinessBusinessModelModel
BusinessModel
BusinessModel
BusinessBusinessModelModel
TOPLinkTOPLinkTOPLinkTOPLink
CICSCICSCICSCICS
DB2/2DB2/2DB2/2DB2/2
DZSDZSDZSDZS
DB2 (Host MVS)DB2 (Host MVS)DB2 (Host MVS)DB2 (Host MVS)
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller35
and yet another level deeper: persistence service• class models
• we will not enter this level of details ....
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller37
what about the silver bullets of the late 80ties ...
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 !!!
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller41
homogeneous approaches• the late 80ties tought us to build one big integrated
system based on one data model
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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 ..
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
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
Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved
W. Keller45
summary ...
good solutions
fullhomogeneity chaos
soft migrationspragmatism