concepts for modelling enterprise architectures
TRANSCRIPT
-
7/29/2019 Concepts for Modelling Enterprise Architectures
1/18
Concepts for Modelling Enterprise Architectures
HenkJonkers1,MarcLankhorst1,RenvanBuuren1,StijnHoppenbrouwers2,MarcelloBonsangue3,LeendertvanderTorre4
1
TelematicaInstituut,P.O.Box589,7500ANEnschede,theNetherlandsPhone:+31534850485,fax:+31534850400,e-mail:[email protected]
2UniversityofNijmegen,Nijmegen,theNetherlands
3LeidenInstituteforAdvancedComputerScience,Leiden,theNetherlands4CWI,Amsterdam,theNetherlands
Abstract
Acoherentdescriptionofanenterprisearchitectureprovides insight,enablescommunicationamongstakeholdersandguidescomplicatedchangeprocesses.Unfortunately,sofarnoenterprisearchitecturedescriptionlanguageexists thatfullyenablesintegratedenterprisemodelling,becauseforeacharchi-tecturaldomain,architectsusetheirownmodellingtechniquesandconcepts,toolsupport,visualisationtechniques,etc.In thispaperweoutlinesuchan integrated languageandwe identifyandstudycon-cepts that relatearchitecturaldomains. Inour languageconcepts fordescribing the relationshipsbe-tweenarchitecturedescriptionsat thebusiness,application,and technology levelsplayacentralrole,relatedtotheubiquitousproblemofbusinessITalignment,whereasforeacharchitecturaldomainweconform toexisting languagesorstandardssuchasUML. Inparticular,usageofservicesofferedbyonelayertoanotherplaysanimportantroleinrelatingthebehaviouraspectsofthelayers.Thestruc-turalaspectsofthelayersarelinkedthroughtheinterfaceconcept,andtheinformationaspectsthroughrealisationrelations.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
2/18
Concepts for Modelling Enterprise Architectures
Abstract
Acoherentdescriptionofanenterprisearchitectureprovides insight,enablescommunicationamongstakeholdersandguidescomplicatedchangeprocesses.Unfortunately,sofarnoenterprisearchitecturedescriptionlanguageexists thatfullyenablesintegratedenterprisemodelling,becauseforeacharchi-tecturaldomain,architectsusetheirownmodellingtechniquesandconcepts,toolsupport,visualisationtechniques,etc.In thispaperweoutlinesuchan integrated languageandwe identifyandstudycon-cepts that relatearchitecturaldomains. Inour languageconcepts fordescribing the relationshipsbe-tweenarchitecturedescriptionsat thebusiness,application,and technology levelsplayacentralrole,relatedtotheubiquitousproblemofbusinessITalignment,whereasforeacharchitecturaldomainweconform toexisting languagesorstandardssuchasUML. Inparticular,usageofservicesofferedbyonelayertoanotherplaysanimportantroleinrelatingthebehaviouraspectsofthelayers.Thestruc-turalaspectsofthelayersarelinkedthroughtheinterfaceconcept,andtheinformationaspectsthroughrealisationrelations.Noteforthereferees:inthefullversionarunningexamplewillbeintroducedinSections4,5and6,whichillustratesthevariousdistinctionsintroducedanddiscussedinthispaper.1. IntroductionFor the stateof theart inenterprisemodelling,wehave toconsider languages fororganisationandprocessmodellingaswellaslanguagesforapplicationandtechnologymodelling.First,awidevarietyoforganisationandprocessmodellinglanguagesarecurrentlyinuse,becausethereisnosinglestan-dardformodelsinthisdomain.Theconceptualdomainsthatarecovereddifferfromlanguagetolan-guage. Inmany languages, the relationsbetweendomainsarenotclearlydefined.Someof themostpopular languagesareproprietary toaspecific software tool.Relevant languages in thiscategory in-clude the ebXML set of standards for XML-based electronic business, developedby OASIS andUN/CEFACT,theBusinessProcessModelingLanguageBPML(Arkin,2002)oftheBusinessProcessManagement Initiative, IDEF (IDEF, 1993), originating from the US Ministry of Defense, ARIS(Scheer,1994),partofthewidelyusedARISToolset,and theTestbedlanguageforbusinessprocessmodelling(Eertinketal.,1999).Second,and incontrast toorganisationandbusinessprocessmodel-ling,inmodellingapplicationsandtechnologytheUnifiedModellingLanguage(UML)(Booch,Rum-baugh,andJacobson,1999)hasbecomeatrueworldstandard.TheUMListhemainstreammodellingapproachwithin ICT,and itsuse isexpanding intootherareas,e.g., inbusinessmodelling (ErikssonandPenker,2000).Most languagesmentionedaboveprovideconcepts tomodel,e.g.,detailedbusinessprocesses,but
not thehigh-level relationshipsbetweendifferentprocesses.Theyare thereforenot reallysuitable todescribe architectures (IEEEComputer Society, 2000).Architecture description languages (ADLs)define high-level concepts for architecturedescription, such as components and connectors, and areusedtodescribeormodelenterprisearchitectures.AlargenumberofADLshavebeenproposed,somefor specificapplicationareas, somemoregenerallyapplicable,butmostlywitha focuson softwarearchitecture.MedvidovicandTaylor(2002)describethebasicsofADLsandcomparethemostimpor-tantADLswitheachother.Mosthaveanacademicbackground,and theirapplication inpractice islimited.However,theyhaveasoundformalfoundation,whichmakesthemsuitableforunambiguousspecificationsandamenabletodifferenttypesofanalysis.TheADLACME(Garlan,MonroeandWile,1997) iswidely accepted as a standard to exchange architectural information, alsobetween otherADLs.TheReferenceModelforOpenDistributedProcessing(RM-ODP) isajointISO/ITU-Tstan-dardforthespecificationopendistributedsystems.Thereisafairlycompletelanguagecoverageoftheseperate architectural domains,but aweak integrationbetween the languages for the domains.Nocompletesetofarchitecturedescriptiontechniquesexistthatfullyenableandexploitintegratedenter-prisemodelling(Jonkersetal.,2003).Inthispaperwediscussalanguagethatmakesthisintegrationpossible.Forexample,weconsider
theso-called
business-IT
alignment,
the
relationship
between
the
organisational
processes
and
the
informationsystemsandapplicationsthatsupportthem.Thisrelationshiphasattractedsomeattentionlately,butmodellingtechniquestoreallyexpressthisrelationshiphardlyexistyet.Thislackofintegra-
-
7/29/2019 Concepts for Modelling Enterprise Architectures
3/18
tion isan importantproblem forenterprisemodelling,becausechanges inacompanys strategyandbusinessgoalshavesignificantconsequenceswithinalldomainssuchasfortheorganisationstructure,processes,softwaresystems,datamanagementandtechnicalinfrastructures.Companieshavetoadjustprocesses to theirenvironment,openup internalsystemsandmake them transparent toboth internalandexternalparties.Theuseofanenterprisearchitecturehelpstochartthecomplexityofanorganisa-tion.Manyorganisationshaverecognisedthevalueofarchitecturesandusethemduringthedevelop-mentandevolutionoftheirproducts,processes,andsystems.Thegoalsofsuchanintegratedmodelaretohelp increating insight,aidingcommunicationbetween stakeholders,andassessing the impactofchanges.Take forexampleacompany thatneeds toassess the impactof introducinganewproduct in its
portfolio.Thismayrequiredefiningadditionalbusinessprocesses,hiringextrapersonnel,changingthesupportingapplications,andaugmentingthetechnologicalinfrastructuretosupporttheadditionalloadof theseapplications.Perhaps thismayeven requirea changeof theorganisational structure.Manystakeholderswithinandoutsidethecompanycanbeidentified,rangingfromtop-levelmanagementtosoftwareengineers.Eachstakeholderrequiresspecificinformationpresented inanaccessibleway, todealwith the impactofsuchwide-rangingdevelopments.It isverydifficult toobtainanoverviewofthesechangesandtheirimpactoneachother,andtoprovidebothdecisionmakersandengineersim-plementingthechangeswiththeinformationtheyneed.Thedevelopmentofacoherentviewofanen-terprise and a disciplined architecturalworkingpractice significantly contribute to the solution ofcomplexorganisationalpuzzles.An integratedenterprisearchitectureprovides insight, enablescom-municationamongdifferentstakeholders,andguidescomplicatedchangeprocesses.The first steps towardsan integrated languagearedescribed in (Jonkersetal.,2003).Thispaper
presentsanextendedandimprovedoutlineofthislanguagebypresentingamoredetaileddiscussionoftheconceptsusedinthelanguage.Inparticular,inthispaperweaddressthefollowingquestions:1. Atwhichlevelofspecificityshouldconceptsbedescribed,andmoregenerally,whatistherela-
tionbetween the integrated language and existing detailed languages? Typically, languagesaimedatasingledomainareveryspecificandresultindetailedmodels.Wewanttointegratethese different domains, without substituting the existing, domain-specific modelling ap-proaches.Asinglelanguageforalldomainswiththelevelofdetailofferedbytheseindividualapproaches,however,wouldprobablyresultinanunworkablebehemoth.Ouraimistoprovideanoverviewofanentireenterprise;drillingdowntotheindividualdomainsshouldbedoneus-ingtheexistingapproaches.
2. Whichdomainsshouldbeidentifiedinthelanguage?Inordertoarriveatacoherentarchitec-tural description, several architecture domains and layers aswell as their relationsmustbemodelled.Dependingonthetypeofenterpriseandthematurityofitsarchitecturepractice,dif-ferentarchitecturaldomainsaredistinguished,suchas theproduct,business, information,andapplicationdomains.
3. Foreachdomain,whichconcepts shouldbe included in the language?Currently,we restrictourselvestodescribingoperationalconceptsandrelations,i.e.,thosethatdirectlycontributetotherealisationoftheproductsorservicesofthatlayer.Manyothertypesofconceptsandrela-tionsarelikelytoberelevantinarchitecturaldescriptions,suchasownership,governance,sup-port,responsibility,etc.Whereneeded,thesewillbeaddedinlaterversionsofthelanguage.
4. Howtodescribetherelationsbetweenthedomains?Therelationsbetweenthebusiness,appli-cation,andtechnologylayers,whichplayacentralroleinthisversionofthelanguage,shouldcontributetosolvingthebusiness-ICTalignmentproblemthatwetrytotackle.
Toaddressthesequestions,weproceedasfollows.First,wedefineconceptsatanintermediateabstrac-tionlevel.Theyareapplicabletodescribeenterprisearchitecturesofanyinformation-intensiveorgani-sationand,ifdesired,theycanbefurtherspecialisedorcomposedtoformconceptstailoredtowardsamore specificcontext.Second,webaseourchoice for theconceptualdomainson thedomainscom-monlydistinguished inarchitectural frameworksormethods, suchas theTOGAF framework (OpenGroup, 2003), the Zachman framework (Sowa and Zachman, 1992), and the architecturalpracticewithinorganisationsparticipatingintheArchiMateproject.Third,withinthearchitecturaldomains,wereuseelementsfromexistinglanguagesasmuchaspossible.Moreover,webaseourmodelonanactorperspective.Fourth,ourlanguageidentifiestheserviceconceptaslinkingpin.ThispaperisaresultfromtheArchiMateproject(Jonkersetal.,2003),apublic/privatecooperation
betweenseveral
companies
and
research
institutes
that
aims
to
provide
enterprise
architects
with
con-ceptsand techniques formodelling,visualising,andanalysing integratedarchitectures.Thesetofar-
chitecturemodellingconceptsdescribedinthispaper,togetherwiththeirrelationships,willbereferred
-
7/29/2019 Concepts for Modelling Enterprise Architectures
4/18
toastheArchiMatemetamodel.TheArchiMateprojectstudiestheenterprisemodellinglanguagethatrepresentsthecomplexityofarchitecturaldomainsandespeciallytheirrelationswithinthescopeofaset of architecture instruments and techniques visualized inFigure 1.Views andpresentation tech-niquesaretailoredtotheneedsofdifferentstakeholders,providingthemwithinsightintheirparticularareaofinterest,andfacilitatingcross-domaindiscussionandunderstanding.TheyarecenteredaroundthenotionofaviewpointinaccordancewiththeIEEEstandard1471(IEEEComputerSociety,2000).Analysistechniquesareusedtoassesstheimpactofdevelopmentsandchanges.Theenterprisemodel-ling language is evaluatedby case studies, aswell as its suitability to visualizeviews andperformanalyses.TherelationsamongtheelementsoftheArchiMateprojecthasbeensketchedin(Jonkersetal.,2003).Amoredetaileddescriptionof therelationsaswellasadiscussiononviews,analysisandpresentationisbeyondthescopeofthispaper,thoughtoillustratetheintegrationofarchitecturesinourArchiMatelanguagewediscussanexamplethatinvolvesasimpleanalysistechnique.
ModelsModels
ArchitectsArchitects
PresentationPresentation
ViewView
StakeholdersStakeholdersviewpointviewpoint
Analysis
analysisquestion
Analysis
analysisquestionanalysisquestion
Figure1.ArchiMateContextThelayoutofthispaperisasfollows.InSection2wediscussthelevelofgranularityoftheArchi-
MatelanguageandtherelationshipbetweentheArchiMatelanguageandotherlanguages.InSection3wediscussourframeworkofconceptualdomains.InSections4,5and6wediscusstheconceptsofthebusiness layer, theapplication layerand the technology layer, respectively.Finally, inSection7wediscussintra-andinter-relationships.InSection8wepresentanintegratedexamplethatinvolvesalsoaqualitativeanalysistechnique.2. SpecificityofconceptsformodellingenterprisearchitecturesAkeychallengeinthedevelopmentofageneralmetamodelforenterprisearchitectureistostrikea
balancebetweenthespecificityoflanguagesforindividualarchitecturedomains,andaverygeneralsetofarchitectureconceptswhichreflectsaviewofsystemsasameresetofinterrelatedentities.Figure2illustratesthatconceptscanbedescribedatdifferentlevelsofspecialisation.
ProcessApplication
Partner-specificconcepts,standards
Enterprisearchitectureconcepts(ArchiMatemetamodel)
Underlying
genericconcepts
moregeneric
moresp
ecific
Object
Relation
Figure2.MetamodelsatdifferentlevelsofspecificityAtthebaseofthetriangle,wefindthemetamodelsofthearchitecturemodellingconceptsusedby
specificorganisations,aswellasavarietyofexistingmodellinglanguagesandstandards;UMLisanexampleofalanguageinthiscategory.Relevantlanguagesinclude:x The ebXML set of standards for XML-based electronic business, developed by OASIS and
UN/CEFACT, specifies the Business Process Specification Schema (Business Process ProjectTeam,2001).Itprovidesastandardframeworkbywhichbusinesssystemsmaybeconfiguredtosupportexecutionofbusinesscollaborationsconsistingofbusiness transactions.Itisfocussedon
-
7/29/2019 Concepts for Modelling Enterprise Architectures
5/18
theexternalbehaviourofprocessesforthesakeofautomatingelectroniccommercetransactions.Itisthereforelesssuitedforgeneralenterprisearchitecturemodelling.
x TheBusinessProcessModelingLanguageBPML(Arkin,2002)oftheBusinessProcessManage-mentInitiative,isanXML-basedlanguageformodellingbusinessprocessesthathasrootsintheworkflowmanagementworld.Itcanbeusedtodescribetheinnerworkingsof,e.g.,ebXMLbusi-nessprocesses.
x IDEF(IDEF,1993),originatingfromtheUSMinistryofDefense,isacollectionof16(unrelated)diagramming techniques, three of which are widely used: IDEF0 (function modelling),IDEF1/IDEF1x(informationanddatamodelling)andIDEF3(processdescription).
x ARIS(Scheer,1994) ispartof thewidelyusedARISToolset.AlthoughARISalsocoversotherconceptualdomains,thereisaclearfocusonbusinessprocessmodellingandorganisationmodel-ling.
x TheTestbedlanguageforbusinessprocessmodelling(Eertinketal.,1999),isusedbyanumberoflargeDutchorganisations in thefinancialsector,wasdevelopedby theTelematica Instituut.Wehavegainedalotofexperiencewithboththedefinitionandthepracticaluseofthislanguage,andithasprovidedimportantinspirationforthedefinitionofbusiness-layerconcepts.
x Concerninglanguagesforapplicationandtechnologymodelling,theUMListhemainstreammod-ellingapproachwithinICT,anditsuseisexpanding intootherareas,e.g.,inbusinessmodelling(ErikssonandPenker,2000).AnotherexampleistheUMLprofileforEnterpriseDistributedOb-jectComputing(EDOC),whichprovidesanarchitectureandmodellingsupportforcollaborativeorInternetcomputing,withtechnologiessuchaswebservices,EnterpriseJavaBeans,andCorbacomponents (ObjectManagementGroup, 2002b).ThismakesUML an important language notonlyformodellingsoftwaresystems,butalsoforbusinessprocessesandforgeneralbusinessar-chitecture.TheUMLhaseitherincorporatedorsupersededmostoftheolderICTmodellingtech-niques still in use.However, it is not easily accessible and understandable formanagers andbusiness specialists; therefore, special visualisations and views ofUMLmodels shouldbepro-vided.AnotherimportantweaknessoftheUMListhelargenumberofdiagramtypes,withpoorlydefinedrelationsbetweenthem.Thisisanotherillustrationofthelackofintegrationdiscussedintheintroductionofthispaper.GiventheimportanceoftheUML,othermodellinglanguageswilllikelyprovideaninterfaceormappingtoit.Atthetopofthetrianglewefindthemostgeneralmetamodelforsystemarchitectures,essentially
ametamodelmerelycomprisingnotionssuchasobject,component,andrelation.Somearchitec-turaldescription languagessuchasACME (Garlan,Monroe&Wile,1997)partly fall into thiscate-gory.These generic conceptsmaybe suitable as abasis for the formal semantic description of theconcepts and formal analysis techniques.There are initiatives to integrateACME inUML,bothbydefiningtranslationsbetweenthelanguagesandbyacollaborationwithOMGtoincludeACMEcon-ceptsinUML2.0(U2Partners,2003).Inthisway,theconceptswillbemadeavailabletoalargeuserbaseandbesupportedbyawiderangeofsoftwaretools.ThisobviatestheneedforaseparateADLformodellingsoftwaresystems.TheArchitectureDescriptionMarkupLanguage(ADML)wasoriginallydevelopedasanXMLencodingofACME.TheOpenGrouppromotesADMLasastandardforenter-prisearchitectures.Moreover, theReferenceModel forOpenDistributedProcessing (RM-ODP) isajointISO/ITU-Tstandardforthespecificationopendistributedsystems.ItdefinesfiveviewpointsonanODPsystemthateachhas theirownspecification language.Forexample,fortheenterpriseview-point,whichdescribespurpose,scopeandpoliciesofasystem,theRM-ODPEnterpriseLanguagehasbeendefinedinwhich,e.g.,businessobjectivesandbusinessprocessescanbemodelled(ITU-T,2001).Themetamodelthatweproposedefinestheconceptssomewherebetweenthesetwoextremes.Itis
moredetailed than the abstract languages,becausebesides abstract concepts like component it alsocontainsmoredetailedconceptslikebusinessfunction.Moreover,itismoreabstractthanforexampleUML,becauseitdoesnotcontainconceptslikeTheconceptsattheintermediatelevelareapplicabletodescribeenterprisearchitecturesofanyinformation-intensiveorganisationand,ifdesired,theycanbefurtherspecialisedorcomposedtoformconceptstailoredtowardsamorespecificcontext.Figure1raises thequestionhowtheArchiMate language isrelatedtomoreabstract languages,as
wellastomoredetailedlanguages.Forexample,theADLACME(Garlan,MonroeandWile,1997)iswidelyacceptedasastandardtoexchangearchitecturalinformation,alsobetweenotherADLs.CanasimilarrolebeplayedbytheArchiMatelanguage?Moreover,howcantheArchiMateenterprisearchi-tecture
concepts
be
used
to
integrate
more
specific
models
described
in
other
languages?
Adetaileddiscussionon the relationbetween theArchiMate languageandother languages isbe-
yondthescopeofthispaper,becauseherewewanttofocusontheconceptsusedintheArciMatelan-
-
7/29/2019 Concepts for Modelling Enterprise Architectures
6/18
guage.However,asanexamplewesketchanexampleofhowtouseArchiMateconceptstodescribethehigh-levelstructureoftheorganisation,thebusinessprocessesandtheapplicationsupportfortheseprocessesandrelations.ToolssuchasTestbedStudioorARISfordetailedbusinessprocessmodels,andtoolssuchasRationalRoseorSelectComponentArchitectfordetailedUMLdesignmodels,canbeusedformoredetaileddescriptions.Figure3showsanexampleofthisapproachinwhichaninte-gratedarchitecturalviewonanumberofdisjointUMLdiagramsisconstructedbymeansofanoverallArchiMatemodel.
Transaction
entryBill
creation
FinancialApplicationFinancialApplication
TakeoutinsuranceReceiverequest
Processrequest
Collectpremium
Requestinsurance
RequestInvoice
Class
diagram
Component
diagram
Activitydiagram
Figure3.ExampleofArchiMateasalanguagetolinkUMLdesignmodels3. TheconceptualdomainsintheArchiMatelanguageThe set ofarchitecturemodelling conceptsdescribed in thispaper, togetherwith their relationships,willbereferredtoas theArchiMatemetamodel.Thestartingpointforthedevelopmentofthismeta-modelisacollectionofso-calledconceptualdomains,eachcoveringaspecificbusinessarea.Webaseourchoiceofconceptualdomainsonthedomainscommonlydistinguishedinarchitecturalframeworksormethods,suchastheTOGAFframework(OpenGroup,2003),theZachmanframework(SowaandZachman,1992),andthearchitecturalpracticewithinorganisationsparticipatingintheArchiMatepro-ject.Theproductdomain,with theconceptproduct thatdescribes the(information)productsorservicesthatanorganisationofferstoitscustomers.
Theorganisationdomain,describingthebusinessactors(employees,organisationalunits)andtherolestheymayfulfil.
Theprocessdomain,describingbusinessprocessesorbusinessfunctionsconsistingofbusinessactivi-ties.
Theinformationdomain,representingtheknowledgeinanorganisationandthewayitisstructured.Thedatadomain, inwhich information is represented insuchaway that it issuitableforautomatedprocessing.
Theapplication
domain,
describing
software
applications
that
support
the
business
through
application
services.
Thetechnicalinfrastructuredomain,comprisingconceptsfor,e.g.,hardwareplatformsandcommuni-cationinfrastructure,neededtosupportapplications.
Inthecurrentpracticeoforganisations,architecturaldescriptionsaremadefordifferentlayersoftheorganisation.Theseare layers in the sense that the lower layersprovide functionality to support thehigherlayers.Thelayersthatareusuallyrecognisedinthiscontextarethebusinesslayer,theapplica-tion layerand the technology layer.Although, toacertainextent,modelling supportwithineachofthese layers isavailable,well-describedconcepts todescribe the relationshipsbetween the layersarealmostcompletelymissing.SuchconceptsareessentialtotacklethebusinessITalignmentprobleminasystematicway.Basedon thecommonaspectsof thesedomainsand layers,wemakea firstgeneralisationof the
coreconcepts.Inourview,asystemororganisationprimarilyconsistsofasetofentities,whichhavean internalstructure,performbehaviour,anduseandexchange information.For instance,asalesor-
-
7/29/2019 Concepts for Modelling Enterprise Architectures
7/18
ganisationmayconsistofanumberofdepartments,whichperformbusinessprocesses,usingandex-changingcustomerdata.Theaspectsandlayersformaframeworkofninecells,asillustratedinFigure4.Theconceptual
domainsmentionedearlierareprojectedintothisframework.
Business
layer
Application
layer
Technology
layer
Information
aspect
Behaviour
aspect
Structure
aspect
Process
domain
Organisation
domainInformation
domain
Data
domainApplicationdomain
Technicalinfrastructuredomain
Productdomain
Figure4.ArchitecturalframeworkItisimportanttorealisethattheclassificationofconceptsbasedonconceptualdomains,or basedonaspectsand layers, isonlyaglobalone.It is impossible,andundesirable, todefineastrictboundarybetweentheaspectsandlayers,becauseconceptsthatlinkthedifferentaspectsandlayersplayoneofthemostimportantrolesinacoherentarchitecturaldescription.Forexample,runningsomewhataheadofthelaterconceptualdiscussions,servicesandrolesserveasintermediaryconceptsbetweenpurelybehavioural concepts and purely structural concepts.Also, there are concepts that covermultipleaspectsandlayers.Anexampleisabusinessdomainconcept,e.g.themortgagedomainforabank,whichcoversboththebusinesslayerandapplicationlayer,andincludeselementsfromallofthethreeaspects.4. BusinesslayerconceptsInthissectionweidentifytheconceptsforarchitecturaldescriptionsthatcanbeplacedinthebusinesslayerofourframeworkofSection3.Wedescribeconceptscoveringeachofthethreeaspectsstruc-ture,behaviourandinformationaswellasconceptslinkingtheseaspects.Figure5givesanoverviewofthebusinesslayerconceptsandtheirrelationships.Forthisfigure,as
wellasfortheothermetamodelrepresentationsinthisdocument,weusearestrictedversionofUMLclassdiagrams.Theconceptsareroughlypositionedaccordingtothethreeaspectsofourframework.However,theboundariesbetweentheaspectsarenotstrict:someconceptsaremostnaturallyplacedonthelinethatseparatestheaspectsinFigure4.Theseconceptsmayservetomakethelinkbetweentheconceptswithinthedifferentaspects.Inparticular,theconceptrepresentationlinksthestructuralandinformational aspects, and the concepts role, collaboration and interface link the structural andbehaviouralaspect.
accessessassociated
withaccesses
assignedto
assignedto
realisesrealisesuses uses
assignedto
BusinessroleBusinessprocess/function
Businesscollaboration
Businessinterface
Purpose
Meaning
Organisationalservice
Businessactor
associatedwith
associatedwith
accessess
uses
Businessevent
triggers triggers
triggers triggers
triggers
Representation
Businessinteraction
triggers
triggers
triggersassigned
to
Businessobject
accessess associatedwith
Figure5.Businesslayermetamodel
-
7/29/2019 Concepts for Modelling Enterprise Architectures
8/18
Picture to be inserted for final version
Figure6.Exampleofabusiness-layermodel.4.1 StructureThe
structure
aspect
at
the
business
layer
refers
to
the
static
structure
of
an
organisation,
in
terms
of
the
entitiesthatmakeuptheorganisationandtheirrelationships.Twotypesofentitiesaredistinguished:x Businessactors:theactiveentities(thesubjects)thatperformbehavioursuchasbusinessprocessesor functions.Business actorsmaybe individualpersons (e.g. customersor employees),but alsogroupsofpeopleandresources thathaveapermanent(orat leastlong-term)statuswithintheor-ganisations.Typicalexamplesofthelatterareadepartmentandabusinessunit.
x Businessobjects:thepassiveentitiesthataremanipulatedbybehavioursuchasbusinessprocessesorfunctions.Businessobjectsrepresenttheimportantconceptsinwhichthebusinessthinksaboutadomain.
AlthoughUML,whichisbasedontheobject-orientedparadigm,doesnotmakethedistinctionbetweenactive andpassive entities, these two concepts are very common in other enterprisemodelling ap-proaches.Forexample, theRM-ODPEnterpriseLanguage(Tyndale-Biscoe,2002)distinguishes ac-torandartefactastwospecialisationsofenterpriseobject.Atthebusinesslayer,itiscommontomakethelinkbetweenactorsandbehaviourmoreflexibleby
introducing the intermediaryconceptbusiness role.The idea is that thework thatanactorperformswithinanorganisationisalwaysbasedonacertainrolethattheactorfulfils.Thereareatleasttworea-sons.First,thesetofrolesinanorganisationcanbeexpectedtobemuchmorestablethanthespecificactorsfulfillingtheseroles,sotodescribethestructureofanorganizationrolesseemtobebettercan-didatesthanactors.Second,multipleactorscanfulfilthesamerole,andconversely,asingleactorcanfulfilmultiple roles.Roles are typically used to distinguish responsibilities, and it canbe checkedwhethertheassignmentofactorstorolessatisfiesdesirableproperties.Architectural descriptions focus onstructure,whichmeans that the interrelationships of entities
withinanorganisationplayanimportantrole.Tomakethisexplicit,theconceptofbusinesscollabora-tionhasbeenintroduced.Acollaborationisacollectiveofroleswithinanorganisationwhichperformcollaborativebehaviour.BusinesscollaborationshavebeeninspiredbycollaborationsasdefinedintheUML (U2Partners,2002),although theUMLcollaborationsapply tocomponents in theapplicationlayer.Also,ourbusinesscollaborationconcepthasastrongresemblancetothecommunityconceptasdefined in theRM-ODPEnterpriseLanguage (Tyndale-Biscoe,2002),and to the interactionpointconcept,definedintheAMBERlanguage(Eertinketal.,1999).AswillbeexplainedinSection7.2,theserviceconceptplaysanimportantroleinlinkingmodelsin
thedifferent layersofour framework. In the lightof this service-orientedapproach, it isuseful tohavethepossibilitytoexplicitlymodelthebusinessinterfaces,i.e.,the(logicalorphysical)locationswheretheservicesthataroleofferstotheenvironmentcanbeaccessed.Thesameservicemaybeof-feredonanumberofdifferentinterfaces:e.g.,bymail,bytelephoneorthroughtheInternet.Incontrasttoapplicationmodelling,itisuncommonincurrentbusinesslayermodellingapproachestorecognisethe business interface concept. However, the channel concept, as defined in, among others, theNEMLlanguage(Steenetal.,2002),hasastrongresemblancetoabusinessinterface.4.2 BehaviourBasedonserviceorientation,acrucialdesigndecisionforthebehaviouralpartofourmetamodelisthedistinctionbetween externalandinternalbehaviourofanorganisation.Theexternallyvisiblebe-haviourismodelledbytheconceptorganisationalservice,whichrepresentsaunitoffunctionalitythatismeaningful from thepointofviewof theenvironment.Within theorganisation, theseservicesarerealisedbybusinessprocesses,businessfunctionsorbusinessinteractions.Businessprocesses,func-tionsand interactions, in turn,mayuseother services (internal to theorganisation,butexternal toasmallerentitywithintheorganisation).Abusinessprocess/functionisaunitofinternalbehaviour,performedbyoneormoreroleswithin
theorganisation.Abusinessactivitycouldbedefinedasabehaviourelementthathastherightgranu-laritytodeterminetheservicesandapplicationsneededtosupportit.Wecansolvethisbydefiningaspecialisation
of
abusiness
process
function,
which
has
as
aconstraint
that
it
cannot
be
further
decom-posed.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
9/18
Althoughthedistinctionbetweenthetwoisnotalwayssharp,itisoftenusefultodistinguishaproc-essviewandafunctionviewonbehaviour.Bothconceptscanbeusedtogroupmoredetailedbusinessprocesses/functions,butbasedondifferentgroupingcriteria.Abusinessprocessrepresentsaflowofsmallerprocesses/functions,withoneormoreclearstartingpointsandleading tosome result(some-timesdescribedascustomertocustomer,wherecustomermayalsobeaninternalcustomer,inthecaseofsubprocesseswithinanorganisation).Abusinessfunctionoffersusefulfunctionalitythatmaybeusefulforoneormorebusinessprocesses.Itgroupsbehaviourbasedon,e.g.,requiredskills,capa-bilities, resources, (application)support,etc.Typically, thebusinessprocessesofanorganisationaredefinedbasedontheproductsandservicesthattheorganisationoffers,whilethebusinessfunctionsarethebasisfor,e.g.,theassignmentofresourcestotasksandtheapplicationsupport.Abusinessinteractionisaunitofbehavioursimilartoabusinessprocessorfunction,butitisper-
formed inacollaborationof twoormore roleswithin theorganisation.This strongly resembles theinteractionconceptinAMBER(Eertinketal.,1999).Similartoprocessesorfunctions,theresultofabusinessinteractioncanbemadeavailabletotheenvironmentthroughanorganisationalservice.A business event is something that happens (externally) andmay influencebusinessprocesses,
functionsor interactions.Abusinessevent ismostcommonlyused tomodelsomething that triggersbehaviour,butothertypesofeventsarealsoconceivable:e.g.,aneventthatinterruptsaprocess.ThebusinesseventconceptissimilartothetriggerconceptinAMBER(Eertinketal.,1999)andtheinitialstateandfinalstateconceptsasusedin,e.g.,UMLactivitydiagrams(U2Partners,2003).4.3 InformationTheinformationalconceptsprovideawaytolinktheoperationalsideofanorganisationtoitsbusinessgoals,theinformationthatisprocessed,andtotheproductsorservicesthatanorganisationofferstoitscustomers.Arepresentationis theperceptibleformofthe informationcarriedbyabusinessobject,suchasa
document.Ifrelevant,representationscanbeclassifiedinvariousways,forexample intermsofme-dium(e.g.,electronic,paper,audio)orformat(e.g.,HTML,PDF,plaintext,barchart).Asinglebusi-nessobjectcanhaveanumberofdifferentrepresentations,butarepresentationalwaysbelongstoonespecificbusinessobject.Apurposeisthefunctionalityofsomeorganisationalserviceseenfromthepointofviewofanex-
ternaluser.Itmodelstheintendedcontributionofaservicetowardstheachievingofaparticular(busi-ness)goal,orasetofgoals.Apurposeconcernsahigh-leveldescriptionofsomebasicfunctionalityintermsofbehaviourorevensomeconditionorstatesupportedorenabledbysomeorganisationalser-vice,seenstrictlyfromthepointofviewofsomeexternalactor(typically,acustomer).PurposestronglyresemblesaUMLusecase.Looselyspeaking,apurposecanbeseenasacharac-
terisationofarequiredservice,asopposedtoanofferedservicefromtheorganisationsperspec-tive. In thisway,we have abehavioural counterpart of the required interface/offered interfaceduality for the structureaspect.Thepurposeconceptprovidesanatural linkbetween theoperationalbusinessprocesses,functionsandservices,andtheproductdomainthatwillbeaddedtoourmetamodelinalaterstage.Ameaningisthecontributionoftherepresentationofabusinessobjecttotheknowledgeorexper-
tiseofsomeactor,givenaparticularcontext.Inotherwords,meaningrepresentstheinformativevalueofabusinessobjectforauserofsuchanobject.Itisthroughacertaininterpretationofarepresentationoftheobjectthatmeaningisbeingofferedtoacertainuserortoacertaincategoryofusers.5. ApplicationlayerconceptsFigure7givesanoverviewoftheapplicationlayerconceptsandtheirrelationships.Manyofthecon-ceptshavebeeninspiredbytheUML(includingsomeoftheUML2.0proposals),asthisisthedomi-nant language,and thedefacto standard, fordescribing softwareapplications.Wheneverapplicable,wedrawinspirationfromtheanalogywiththebusinesslayer.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
10/18
assignedto
accessesrealisesuses
assignedto
usesrealisesuses
assignedto
accesses
Applicationfunction
Applicationcollaboration
Applicationinterface
Applicationinteraction
Applicationcomponent
Dataobject
accessesApplication
serviceassociated
with
triggersFigure7.Application-layermetamodel
Picture to be inserted for final version
Figure8.Exampleofanapplication-layermodel.5.1 StructureThemain structural concept for theapplication layer is theapplicationcomponent.Thisconcept isused tomodelany structural entity in theapplication layer:notjust (reusable) softwarecomponentsthatcanbepartofoneormoreapplications,butalsocompletesoftwareapplications,subapplicationsorinformationsystems.ThisconceptisverysimilartotheUMLcomponent.The interrelationships of components are also an essential ingredient in application architecture.
Therefore,wealsointroduce theconceptofapplicationcollaborationhere,definedasacollectiveofapplicationcomponentswhichperformapplicationinteractions.Theconceptisverysimilartothecol-laborationasdefinedintheUML2.0proposals(U2Partners,2002).Inthepurelystructuralsense,anapplicationinterfaceisthe(logical)locationwheretheservicesof
acomponentcanbeaccessed.Inabroadersense(asused in,amongothers, theUMLdefinition),anapplication interface also has somebehavioural characteristics: it defines the set of operations andeventsthatareprovidedbythecomponent,orthosethatarerequiredfromtheenvironment.Thus,itisused
to
describe
the
functionality
of
acomponent.
A
distinction
may
be
made
between
aprovided
in-terfaceandarequiredinterface.Theapplicationinterfaceconceptcanbeusedtomodelbothapplica-
tion-to-application interfaces, offering internal application services, and application-to businessinterfaces(oruserinterfaces),offeringexternalapplicationservices.Alsoat theapplication layer,wedistinguish thepassivecounterpartof thecomponent,whichwe
calladataobject.Thisconceptisusedinthesamewayasdataobjects(orobjecttypes)inwell-knowndatamodellingapproaches,mostnotablytheclassconceptinUMLclassdiagrams.5.2 BehaviourBehaviourintheapplicationlayercanbedescribedinawaythatisverysimilartobusinesslayerbe-haviour.Wemakeadistinctionbetweentheexternalbehaviourofapplicationcomponentsintermsofapplicationservices,andtheinternalbehaviourofthesecomponentstorealisetheseservices.Anapplicationserviceisanexternallyvisibleunitoffunctionality,providedbyoneormorecom-ponents,exposedthroughwell-definedinterfaces,andmeaningfultotheenvironment.Theservicecon-
ceptprovidesawaytoexplicitlydescribethefunctionalitythatcomponentssharewitheachotherandthefunctionalitythattheymakeavailabletotheenvironment.Theconceptfitswellwithinthecurrentdevelopmentsintheareaof,e.g.,webservices(Lankhorst,2002).Thetermbusinessserviceissome-timesusedforanexternalapplicationservice,i.e.,applicationfunctionalitythatisusedtodirectlysup-port theworkperformed in abusinessprocess or function, exposedby an application-to-businessinterface.Internalapplicationservicesareexposedthroughanapplication-to-applicationinterface.Anapplicationfunctiondescribes theinternalbehaviourofacomponentneededtorealiseoneor
moreapplicationservices.Inanalogywiththebusinesslayer,aseparateapplicationflowconceptisconceivableasthecounterpartofabusinessprocess.However,forthemomentwehavedecidednottoincludethisasaseparateconceptinourmetamodel.Anapplication interaction is thebehaviourofacollaborationof twoormoreapplicationcompo-
nents.TheUML2.0proposals(U2Partners,2002)alsoincludetheinteractionconcept.Anapplication
-
7/29/2019 Concepts for Modelling Enterprise Architectures
11/18
componentisexternalbehaviourfromtheperspectiveofeachoftheparticipatingcomponents,butthebehaviourisinternaltothecollaborationasawhole.5.3 InformationFor themoment,wehavenotdefinedanypurely informationalconceptsat theapplication layer,be-cause
the
link
to
objectives
and
products
is
less
apparent
here
than
it
is
at
the
business
layer.
However,
it isconceivable thatapplication-layerversionsof the informationalconceptsturnouttobeusefulincertain situations.Givenourdefinitionof the businesspurposeconcept,a usecase, in theUMLsense,wouldbeanaturalcandidateforitsapplication-layercounterpart.Thecounterpartofthebusi-nessmeaningconceptwouldhavetobesubjecttoautomatedinterpretation,whichsuggestssomethinginthedirectionofoperationalsemantics.Furtherstudyisneededtocometothemostsuitablesetofinformationalconceptsattheapplicationlayer,ifany.6. TechnologylayerconceptsInthissectionweidentifytheconceptsforarchitecturaldescriptionsthatcanbeplacedinthetechnol-ogylayerofourframework.Figure9givesanoverviewoftheapplicationlayerconceptsandtheirre-lationships.ManyoftheconceptshavebeeninspiredbytheupcomingUML2.0standard(U2Partners,2003),asthisisthedominantlanguageandthedefactostandardfordescribingsoftwareapplications.Wheneverapplicable,wedrawinspirationfromtheanalogywiththebusinessandapplicationlayers.
assigned
to
uses
Communication
path
Infrastructure
interface
Infrastructure
service
realises
Execution
environmentDevice Network
associated
with
realises
assignedtoNodeArtifact
assigned
to
associated
with
Figure9.Technology-layermetamodelPicture to be inserted for final version
Figure10.Exampleofatechnology-layermodel.6.1 StructureThemainstructuralconceptfortheapplicationlayeristhenode.Thisconceptisusedtomodelstruc-turalentitiesinthetechnologylayer.ItisidenticaltothenodeconceptofUML2.0.Itstrictlymodelsthestructuralaspectofanapplication:itsbehaviourismodelledbyanexplicitrelationshiptothebe-haviouralconcepts.Aninfrastructure interface isthe(logical)locationwheretheinfrastructuralservicesofferedbya
nodecanbeaccessedbyothernodesorbyapplicationcomponentsfromtheapplicationlayer.Nodescomeintwoflavours:deviceandexecutionenvironment,bothtakenfromUML2.0.Ade-
vicemodelsaphysicalcomputationalresource,uponwhichartifactsmaybedeployedforexecution.Anexecutionenvironmentrepresentsthesoftwareenvironmentforspecific typesofcomponentsanddataobjectsthataredeployedonitintheformofartifacts.Typically,anodewillconsistofanumberofsubnodes,forexampleadevicesuchasaserverandanexecutionenvironmenttomodeltheoperat-ingsystem.Theinterrelationshipsofcomponentsinthetechnologylayeraremainlyformedbycommunication
infrastructure. The communicationpathmodels the relationbetween two ormore nodes, throughwhich thesenodescanexchange information.Thephysical realisationofacommunicationpath isamodelledwithanetwork,i.e.,aphysicalcommunicationmediumbetweentwoormoredevices.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
12/18
6.2 BehaviourIn the technology layer, thebehaviouralconcept thatwedeemrelevant is the infrastructure service.Modelling the internalbehaviour of infrastructure components such as routers or database serverswouldaddalevelofdetailthatisnotusefulattheenterpriselevelofabstraction.Infrastructureservicescanbeclassifiedintothreemaintypes:x
Processingservices;
x Datastorageandaccessservices;x Communicationservices.Theseservicescorrespondtothethreemaintypesofphysicalinfrastructure:computingdevices,stor-age,andnetworks.6.3 InformationAnartifactisaphysicalpieceofinformationthatisusedorproducedinasoftwaredevelopmentproc-ess,orbydeploymentandoperationofasystem.Itistherepresentation,intheformofe.g.afile,ofadataobjectoranapplicationcomponent,andcanbeassignedto(i.e.,deployedon)anode.TheartifactconcepthasbeentakenfromUML2.0.7. Intra-andinter-layerrelationshipsIntheprevioussectionswehavepresentedtheconceptstomodelthebusiness,application,andtech-nologylayersofanenterprise,respectively.However,oneofthemainissuesinenterprisearchitectureisbusiness-ITalignment:howcantheselayersbematched?Manylanguagesexist tomodelbusinessarchitectureson theonehand,orapplicationand technicalarchitectureson theotherhand.However,languagesthatsupportacleardescriptionoftherelationshipbetweentheselayersaremissing.7.1 Intra-layerrelationshipsIneachofthelayerspresentedthusfar,differentrelationshipsbetweenconceptshavebeenused.Table1givesanoverviewoftheserelationships.
Table1.Intra-layerrelationshipsAccess Theaccessrelationshipmodelstheaccessofbehaviouralconceptstobusinessordata
objects.Aggregation Theaggregationrelationshipindicatesthatanobjectgroupsanumberofotherob-
jects.Assignment Theassignmentrelationshiplinksunitsofbehaviourwithactiveelements(e.g.roles,
components)thatperformthem,roleswithactorsthatfulfilthem,orartifactsthataredeployedonnodes.
Association Associationmodelsarelationshipbetweenobjectsthatisnotcoveredbyanother,morespecificrelationship.
Composition Thecompositionrelationshipindicatesthatanobjectconsistsofanumberofotherobjects.
Realisation Therealisationrelationshiplinksalogicalentitywithamoreconcreteentitythatre-alisesit.
Specialisation Thespecialisationrelationshipindicatesthatanobjectisaspecialisationofanotherobject.
Triggering Thetriggeringrelationshipdescribesthetemporalorcausalrelationsbetweenproc-esses,function,interactionsandevents.
Use Theuserelationshipmodelstheuseofservicesbyprocesses,functionsorinterac-tionsandtheaccesstointerfacesbyroles,componentsorcollaborations.
Aswedidfortheconceptsusedtodescribethedifferentconceptualdomains,asmuchaspossibleweadoptcorrespondingrelationshipconceptsfromexistingstandards.Forinstance,relationshipcon-ceptssuchascomposition,association,specializationaretakenfromtheUMLwhiletriggeringisusedinmostbusinessprocessmodellinglanguagessuchasARISandTestbed.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
13/18
7.2 Inter-layerrelationships:theserviceconceptaslinkingpinGeneralisingfromtherelationshipspresentedintheprevioussection,itcanbeobservedthatthearchi-tecturallayers(business,applicationandtechnology)constitutesomesortofhierarchywithinanenter-prise.Acommonwayoflookingatanenterpriseistostartfromthebusinessprocessesandactivitiesperformed.Thesearecarriedoutbysomeactororroleintheorganisation,possiblysupportedbyoneor
more
business
applications,
or
even
fully
automated.
These
activities
however,
can
also
be
viewed
as
servicestothisbusinessprocess,renderingaspecificaddedvaluetotheprocessathand.Onemayalsoadoptabottom-upstrategy,inwhichthebusinessprocessesarejustamechanismfor
instantiatingandcommerciallyexploiting the lower-level services to theoutsideworld. In thisview,themostvaluableassetsarethecapabilitiestoexecutethelower-levelservices,andtheprocessesaremerelyameansofexploitation.Applyingsuchaservice-orientedviewresultsinaservicehierarchyasdepicted inFigure11.This isvery similar to the layeredmodelofe.g. the ISO-OSImodel (ISO,1984).Eachlayermakestheirexternalservicesavailabletothenexthigherlayer.Theexternalservicesof
thehigherlayermaydependonservicesinthesamearchitecturallayeroronelayerbelow.Organisa-tional services, forexample,maydependonexternalapplication services. Internal servicesareusedwithinthesamearchitecturallevel;forinstance,anapplicationcomponentmayuseservicesofferedbyanother application component. Likewise, a business process may be viewed as comprising sub-processesthatoffertheirservicestoeachotherandtothecontainingprocess.Externalorganisationalservicescouldalsobecalledcustomerservices,i.e.,servicesofferedtothe(external)customersoftheenterprise.
External
org.serviceInternal
org.serviceExternal
app.serviceInternalapp.service
Internal
tech.service
External
tech.service Technologylayer
Applicationlayer
Businesslayer
customer
Figure11.Servicearchitecture:hierarchyofservicesExternalorganisational servicescouldalsobecalled customerservices, i.e., servicesoffered to the(external) customersof the enterprise/system.Similarly, external application services are sometimescalledbusinessservices,i.e.,servicesofferedbyapplicationsbutusedbythebusiness.Figure12shows themainrelationsbetweenconcepts inthebusinesslayer,theapplicationlayer,andthetechnologylayer.Forclarityssake,wehaveomittedmostintra-layerrelations.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
14/18
usesuses uses
Businessrole
Applicationservice
BusinesslayerApplicationlayer
uses
Businessbehaviour
Businessinteraction
Businessobject
realises
Artifact
Businesscollaboration
Application
interface
usesuses uses
Application
component
Infrastructureservice
Application layer
Technologylayeruses
Application
behaviour
Application
interactionData
object
realises
Application
collaboration
Infrastructure
interface
Node
ActorOrganisational
service
realises
Figure12.RelationsbetweenthelayersThereisnodirectoperationallinkbetweenbusinessobjectsanddataobjects,withouttheinterventionofbehaviour(i.e.,services):dataobjectsintheapplicationlayerareonlyavailabletothebusinesslayerthroughservices thatareofferedbyapplicationcomponents.However, thereisanimportantrealisa-tionrelationship:oneormoredataobjectsintheapplicationlayerrealise(orrepresent)oneormorebusiness
objects
in
the
business
layer.
Wealsoseesuchrelisationrelationsbetweenontheonehandthedataobjectsandapplicationcom-
ponentsintheapplicationlayer,andontheotherhandtheartifactsrepresentingtheminthetechnologylayer.8. ExampleToillustrateourapproach,weuseaservice-orientedenterprisearchitectureofanimaginaryinsurancecompany,ArchiSurance.Figure13givesavery simple exampleofa layeredenterprisearchitectureusingservicestorelatetheinfrastructurelayer,theapplicationlayer,thebusinessprocesslayer,andtheenvironment.The insurant and insurer roles represent the client and insurance company (ArchiSur-ance), respectively. Invocation of the claims registration serviceby the insurant starts the damageclaimingprocess.The insurant is informedwhether theclaim isaccepted,and, ifso,receivesapay-ment.
Interaction
between
business
processes
and
organisational
roles
is
through
business
services.
Thus,servicesconnecttheprocessarchitectureandtheorganisationarchitecture.Likewise,applicationservicesrelatethebusinessprocessarchitecturetotheapplicationarchitecture.Theautomatedpartofeachbusinessprocess isprovidedby an external application service.These application services arerealisedbyapplicationcomponents.Finally,thetechnologylayerconsistsofanumberofinfrastructureelements suchasamainframeandanapplication server,whichexecuteapplicationcomponentsandprovideservicestotheapplicationlayer.
-
7/29/2019 Concepts for Modelling Enterprise Architectures
15/18
Infrastructure
Externalinfrastructureservices
Applicationcomponentsandservices
Rolesandactors
Externalapplicationservices
Externalbusinessservices
Damageclaimingprocess
Client Insurant Insurer ArchiSurance
Registration PaymentValuationAcceptance
Customer
information
service
Claims
payment
service
Claims
administration
service
Risk
assessment
service
Payment
service
Risk assessment
Claims administration Financial applicationClaim
information
service
Claim
registration
service
Claim
registration
service
Customer
administration
service
Customer administration
Claim
filesservice
zSeriesmainframeDB2
database
Riskassessment
EJB
Customerfiles
service
SunBladeiPlanet
appserver
Figure13.Exampleofaservice-orientedenterprisearchitectureFormoredetailsonthe(provisional)notationusedinthisexample,see(Buurenetal.,2003).Givenourintegratedenterprisearchitecturelanguage,asappliedintheexample,howdoesthiscon-
tribute to thegoalswehave set in the introduction?More specifically,howdoes suchan integratedmodelhelp increatinginsight,aidingcommunicationbetweenstakeholders,andassessingtheimpactofchanges?First,astheexampleshows,ahigh-leveloverviewofanentireenterprisecanbeshowninasingle
integratedandwell-definedmodel.Admittedly,ourexamplewasverysimple;inreality,suchamodelwouldbemuchlarger,requiringtechniquesforselectingandvisualisingtheelementsthatarerelevantforaparticularstakeholder.Second, thismodelcanbe interpretedby, forexample,bothamanager requiring the bigpicture
andasoftwareengineerthatimplementsanapplicationcomponentandneeds toknowthecontextofthiscomponent.Thus,byusingsuchamodelasameansofcommunicating,differentstakeholderscanbetterunderstandeachother.Withineachspecificdomain,thishigh-levelmodelmayserveasastart-ingpointformoredetaileddescriptions.Third,thewell-definedsemanticsoftheconceptsandtheirrelationscanbeusedtoanalysetheim-
pactofeventsandchanges.For instance,iftheSunBladeserverin theexamplemodel fails,wecancomputewhichapplicationscannolongerrun,whichservicescannotbeoffered,whichprocessesare
-
7/29/2019 Concepts for Modelling Enterprise Architectures
16/18
impacted,andfinallywhichservicescannolongerbeofferedtoclients.ThisisshownbythedarkenedconceptsinFigure14.Thus,amanagercandecidehowseveretheimpactofthehardwarefailuremightbe,andhowrobusttheinfrastructureshouldbe.
Infrastructure
Externalinfrastructureservices
Applicationcomponentsandservices
Rolesandactors
Externalapplicationservices
Externalbusinessservices
Damageclaimingprocess
Client Insurant InsurerArchiSurance
Registration PaymentValuationAcceptance
Customer
information
service
Claims
payment
service
Claims
administration
service
Risk
assessment
service
Payment
service
Risk assessment
Claims administration Financial applicationClaim
information
service
Claim
registration
service
Claim
registration
service
Customer
administration
service
Customer administration
Claim
files
service
zSeriesmainframeDB2
database
Risk
assessment
EJB
Customer
files
service
SunBladeiPlanet
appserver
Figure14.Exampleofimpactanalysis;darkenedconceptsshowwhatisaffectedbyfailureoftheSunBladeserver
9.Conclusions
and
future
work
In thispaperwehaveoutlineda language fordescribing integratedenterprisearchitectures.This
languagesaimstobringthemanyseparatearchitecturaldescriptionsforspecificarchitecturaldomainscloser together,asatpresentnoarchitectural languageexistsfordescribingthearchitectureofanen-terpriseasawhole.Sinceseparatelanguagesandtheircorrespondingapproachesaredeeplyembeddedinorganisations,itisnotrecommendabletodevelopanentirelynewlanguage.Therefore,ournewlan-guageaimstoembraceandextendsuccessfulandwidelyadoptedlanguagessuchastheUML.Inpar-ticular,inthispaperweaddressthefollowingquestions.First,atwhichlevelofspecificityshouldconceptsbedescribed,andmoregenerally,whatisthere-
lationbetweentheintegratedlanguageandexistingdetailedlanguages?Theconceptsofourlanguageforenterprisearchitecturedescriptionholdthemiddlebetweenthedetailedconceptsthatareusedformodelling individual domains, e.g., theUML formodelling software, and very general architectureconceptsthatviewsystemsmerelyasentitiesandtheirinter-relations.Thelanguageformsabasisforbridgingtheheterogeneityofexistinglanguages.Currentworkintheprojectaimatdevelopingatool
-
7/29/2019 Concepts for Modelling Enterprise Architectures
17/18
integrationenvironmentinwhichmodelsoriginatingfromvarioustoolscanbelinked.Thisstimulatespossiblereuseinaformthatisstillrecognisablefortheoriginaldesigner.Second,whichdomainsshouldbe identified in the language?Concepts inour languagecurrently
cover thebusiness,application,and technology layersofanenterprise.Moreover, foreach layerwedistinguishtheinformation,behaviourandstructureaspects.Theinformation,product,process,organi-sation,data,applicationandtechnicalinfrastructuredomainareprojectedintothisframework.Third, foreachdomain,whichconceptsshouldbe included in the language?Foreach layer,con-
ceptsandrelationsformodellingtheinformation,behaviour,andstructureaspectsaredefined.Atthebusiness layerwedistinguishthestructuralconceptsbusinessactorsandobjects,rolesandcollabora-tions,thebehaviouralconceptsorganisationalservice,businessprocess,functionsandinteractionsandevents,and the informationalconceptsrepresentation,purposeandmeaning.Attheapplication layer,wedistinguishthestructuralconceptsapplicationcomponent,collaboration,interface,anddataobject,andthebehaviouralconceptsofapplicationservice,functionandinteraction.Atthetechnologylayer,wedistinguishtheFourth,howtodescribetherelationsbetweenthedomains?Usageofservicesofferedbyonelayer
toanotherplaysanimportantroleinrelatingthebehaviouraspectsofthelayers.Thestructuralaspectsof thelayersare linked through the interfaceconcept,and theinformationaspects throughrealisationrelations.Looking at themetamodels for the different layers, it is apparent that they havemany things incommon.Theyusesimilarconceptstomodelthethreeaspectsfromourframework,beitatdifferent
levelsofdetail.Itisusefultorecognisethiscommonbasisofthelayer-specificmetamodels.Thissim-plifies the formalisationof themetamodels,and the sameor similaranalysisandvisualisation tech-niquescanbedevelopedapplicabletobothlayers.Bymeansofasimpleexamplewehavedemonstratedthatourconceptscanbeusedtomakeaco-
herentdescription,coveringallaspectsand layerswithinanenterprise.Wehave illustrated thatsuchintegratedmodels arevery useful in creating insight, facilitating the communicationbetween stake-holders,andassessingtheimpactofeventsandchanges.However,eventhislimitedexampledemon-stratesthatthecomplexityoftheintegratedmodelsneedstobeaddressed.Thedevelopmentofviewsthat selectandvisualise relevantelements from thesemodels for specific stakeholdershelps to fullyexploitthemodels.Theworkdescribedinthispaperispartofanongoingprojectforthedevelopmentofconceptsand
techniquesforsupportingenterprisearchitects.Herewefocussedonthecoreconceptsandrelationsofanenterprisearchitecturelanguage.Furtherworkwillinvolve,amongotherthings:x Furtherspecificationofthedetailedrelationsbetweenconcepts,aspectsandlayers;x Furtherspecificationofconcepts,forexample,bymeansofattributes;x Extensionofthemetamodeltotheproductdomain;x Formalisationofthemetamodeltoallowforanalysisandautomatedvisualisation;x Identificationofrelevantviewpointsandrelatedvisualisations;x Integrationwithothertoolsupportenvironments;x Furtherpracticalvalidationofthemetamodel.Acknowledgments
ThispaperresultsfromtheArchiMateproject(http://archimate.telin.nl),aresearchinitiativethataimstoprovideconceptsandtechniquestosupportenterprisearchitectsinthevisualisation,communicationandanalysisofintegratedarchitectures.TheArchiMateconsortiumconsistsofABNAMRO,StichtingPensioenfondsABP, theDutchTaxandCustomsAdministration,Ordina,Telematica Instituut,Cen-trumvoorWiskundeenInformatica,KatholiekeUniversiteitNijmegen,andtheLeidenInstituteofAd-vancedComputerScience.References
Arkin,A.,(2002),BusinessProcessModelingLanguage,BPMI.org.http://www.bpmi.org/bpmi-downloads/BPML1.0.zip
Booch,G.,J.RumbaughandI.Jacobson(1999),TheUnifiedModelingLanguageUserGuide,Addison-Wesley. BusinessProcessProjectTeam(2001),ebXMLBusinessProcessSpecificationSchemaVersion1.01,
UN/CEFACTandOASIS.http://www.ebxml.org/specs/ebBPSS.pdf
-
7/29/2019 Concepts for Modelling Enterprise Architectures
18/18
Eertink,H.,W.Janssen,P.OudeLuttighuis,W.TeeuwandC.Vissers(1999),ABusinessProcessDesignLan-guage,inProc.ofthe1stWorldCongressonFormalMethods,Toulouse,France,Sept.1999.
Eriksson,H.-E.andM.Penker(2000),BusinessModelingwithUML:BusinessPatternsatWork,J.Wiley.Frankel,D.S.(2003),ModelDrivenArchitecture:ApplyingMDAtoEnterpriseComputing,Wiley,2003.Garlan,D.,R.T.Monroe,andD.Wile(1997),ACME:AnArchitectureDescriptionInterchangeLanguage,inPro-
ceedingsofCASCON97,Toronto,Canada,Nov,1997,pp.169-183.IDEF(1993),IntegrationDefinitionforFunctionModeling(IDEF0)Draft,FederalInformationProcessingStan-
dardsPublicationFIPSPUB183,U.S.DepartmentofCommerce,Springfield, VA,USA,Dec.1993.IEEEComputerSociety(2000).IEEEStd1471-2000:IEEERecommendedPracticeforArchitecturalDescriptionofSoftware-Intensive Systems,Oct.9,2000.
ISO(1984).BasicReferenceModelforOpenSystemsInterconnection,ISO7498.InternationalOrganisationforStandardisation.
ITU-T(2002),InformationtechnologyOpenDistributedProcessingReferenceModelEnterpriseLanguage,ITUTRecommendationX.911ISO/IEC15414.InternationalTelecommunication Union.
Jonkers,H.etal.(2003),TowardsaLanguageforCoherentEnterpriseArchitectureDescription, inM.SteenandB.R.Bryant(eds.),Proceedings7thIEEEInternationalEnterpriseDistributedObjectComputingConference(EDOC2003),Brisbane,Australia,Sept 2003.
Medvidovic,N.andR.N.Taylor(2000),Aclassificationandcomparisonframeworkforsoftwarearchitecturedescriptionlanguages,IEEETransactionsonSoftwareEngineering,26(1),Jan.2000,pp.70-93.
ObjectManagementGroup(2002a),MetaObjectFacility(MOF)Specification,version1.4,April2002.ObjectManagementGroup(2002b),UMLProfileforEnterpriseDistributedObjectComputting(EDOC),OMG
finaladoptedspecificationptc/02-02-05, http://www.omg.org/docs/ptc/02-02-05.pdf OpenGroup(2003),TheOpenGroupArchitecturalFrameworkVersion7,http://www.opengroup.org/togaf/. Reijswoud,V.E.van,andJ.L.G.Dietz(1999),DEMOModellingHandbook,Volume1,DelftUniversityofTech-
nology,Dept.ofInformationSystems,1999.Scheer,A.-W.(1994),BusinessProcessEngineering:ReferenceModelsforIndustrialEnterprises,Springer,Ber-
lin,2nded.,1994.Sowa,J.F.andJ.A.Zachman(1992),ExtendingandFormalizingtheFrameworkforInformationSystemsArchi-
tecture,IBMSystemsJournal,31(3),1992,pp.590-616.Steen,M.W.A.,M.M.LankhorstandR.G.vandeWetering(2002),ModellingNetworkedEnterprises,inProc.
SixthInternationalEnterpriseDistributedObjectComputingConference(EDOC'02),Lausanne,Switzerland,Sept.2002,pp.109-119.
Tyndale-Biscoe, S.,RM-ODPEnterpriseLanguageISO/ITU-T15414/X911,2002.http://www.itu.int/itudoc/itu-t/com17/tutorial/81999_pp7.ppt.
U2Partners,UnifiedModelingLanguage:Superstructure,version2.0,3rdrevisedsubmission,OMGdocumentad/03-04-01,April10,2003.