concepts for modelling enterprise architectures

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.


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-


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


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


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-


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/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


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.


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.


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


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.


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.


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.


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.


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


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


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


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.

concepts for modelling enterprise architectures

Documents