Concepts for Modelling Enterprise Architectures

HenkJonkers1,MarcLankhorst1,RenvanBuuren1,StijnHoppenbrouwers2,MarcelloBonsangue3, LeendertvanderTorre4 TelematicaInstituut,P.O.Box589,7500ANEnschede,theNetherlands Phone:+31534850485,fax:+31534850400,e-mail:Henk.Jonkers@telin.nl

2 3 1

UniversityofNijmegen,Nijmegen,theNetherlands
4

LeidenInstituteforAdvancedComputerScience,Leiden,theNetherlands CWI,Amsterdam,theNetherlands

Abstract A coherent description of an enterprise architecture provides insight, enables communication among stakeholdersandguidescomplicatedchangeprocesses.Unfortunately,sofarnoenterprisearchitecture descriptionlanguageexiststhatfullyenablesintegratedenterprisemodelling,becauseforeacharchitecturaldomain,architectsusetheirownmodellingtechniquesandconcepts,toolsupport,visualisation techniques,etc.Inthis paper weoutlinesuchanintegratedlanguageand weidentifyand studyconcepts that relate architectural domains. In our language concepts for describing the relationships betweenarchitecturedescriptionsatthebusiness,application,andtechnologylevelsplayacentralrole, relatedtotheubiquitousproblemofbusinessITalignment,whereasforeacharchitecturaldomainwe conform to existing languages or standards such as UML. In particular, usage of services offered by onelayertoanotherplaysanimportantroleinrelatingthebehaviouraspectsofthelayers.Thestructuralaspectsofthelayersarelinkedthroughtheinterfaceconcept,andtheinformationaspectsthrough realisationrelations.

Concepts for Modelling Enterprise Architectures

Abstract A coherent description of an enterprise architecture provides insight, enables communication among stakeholdersandguidescomplicatedchangeprocesses.Unfortunately,sofarnoenterprisearchitecture descriptionlanguageexiststhatfullyenablesintegratedenterprisemodelling,becauseforeacharchitecturaldomain,architectsusetheirownmodellingtechniquesandconcepts,toolsupport,visualisation techniques,etc.Inthis paper weoutlinesuchanintegratedlanguageand weidentifyand studyconcepts that relate architectural domains. In our language concepts for describing the relationships betweenarchitecturedescriptionsatthebusiness,application,andtechnologylevelsplayacentralrole, relatedtotheubiquitousproblemofbusinessITalignment,whereasforeacharchitecturaldomainwe conform to existing languages or standards such as UML. In particular, usage of services offered by onelayertoanotherplaysanimportantroleinrelatingthebehaviouraspectsofthelayers.Thestructuralaspectsofthelayersarelinkedthroughtheinterfaceconcept,andtheinformationaspectsthrough realisationrelations. Noteforthereferees:inthefullversionarunningexamplewillbeintroducedinSections4,5and6, whichillustratesthevariousdistinctionsintroducedanddiscussedinthispaper.

1. Introduction
For the state of the art in enterprise modelling, we have to consider languages for organisation and processmodellingaswellaslanguagesforapplicationandtechnologymodelling.First,awidevariety oforganisationandprocessmodellinglanguagesarecurrentlyinuse,becausethereisnosinglestandardformodelsinthisdomain.Theconceptualdomainsthatarecovereddifferfromlanguagetolanguage. In many languages, the relations between domains are not clearly defined. Some of the most popularlanguagesare proprietarytoaspecific softwaretool.Relevantlanguagesinthiscategoryinclude the ebXML set of standards for XML-based electronic business, developed by OASIS and UN/CEFACT,theBusinessProcessModelingLanguageBPML(Arkin,2002)oftheBusinessProcess Management Initiative, IDEF (IDEF, 1993), originating from the US Ministry of Defense, ARIS (Scheer,1994),partofthewidelyusedARISToolset,andtheTestbedlanguageforbusinessprocess modelling(Eertinketal.,1999).Second,andincontrasttoorganisationandbusinessprocessmodelling,inmodellingapplicationsandtechnologytheUnifiedModellingLanguage(UML)(Booch,Rumbaugh,andJacobson,1999)hasbecomeatrueworldstandard.TheUMListhemainstreammodelling approach withinICT,andits useisexpandingintootherareas,e.g.,in businessmodelling(Eriksson andPenker,2000). Mostlanguagesmentionedaboveprovideconceptstomodel,e.g.,detailedbusinessprocesses,but not the high-level relationships between different processes. They are therefore not really suitable to describe architectures (IEEE Computer Society, 2000). Architecture description languages (ADLs) define high-level concepts for architecture description, such as components and connectors, and are usedtodescribeormodelenterprisearchitectures.AlargenumberofADLshavebeenproposed,some for specific application areas, some more generally applicable, but mostly with a focus on software architecture.MedvidovicandTaylor(2002)describethebasicsofADLsandcomparethemostimportant ADLs with each other. Most have an academic background, and their application in practice is limited.However,theyhaveasoundformalfoundation,whichmakesthemsuitableforunambiguous specificationsandamenabletodifferenttypesofanalysis.TheADLACME(Garlan,MonroeandWile, 1997) is widely accepted as a standard to exchange architectural information, also between other ADLs.The ReferenceModelforOpenDistributed Processing(RM-ODP)isajointISO/ITU-Tstandardforthespecificationopendistributedsystems.Thereisafairlycompletelanguagecoverageofthe seperate architectural domains, but a weak integration between the languages for the domains. No completesetofarchitecturedescriptiontechniquesexistthatfullyenableandexploitintegratedenterprisemodelling(Jonkersetal.,2003). Inthispaperwediscussalanguagethatmakesthisintegrationpossible.Forexample,weconsider the so-called business-IT alignment, the relationship between the organisational processes and the informationsystemsandapplicationsthatsupportthem.Thisrelationshiphasattractedsomeattention lately,butmodellingtechniquestoreallyexpressthisrelationshiphardlyexistyet.Thislackofintegra-

tion is an important problem for enterprise modelling, because changes in a companys strategy and businessgoalshavesignificantconsequenceswithinalldomainssuchasfortheorganisationstructure, processes,softwaresystems,datamanagementandtechnicalinfrastructures.Companieshavetoadjust processes to their environment, open up internal systems and make them transparent to both internal andexternalparties.Theuseofanenterprisearchitecturehelpstochartthecomplexityofanorganisation.Manyorganisationshaverecognisedthevalueofarchitecturesandusethemduringthedevelopmentandevolutionoftheirproducts,processes,andsystems.Thegoalsofsuchanintegratedmodelare to help in creating insight, aiding communication between stakeholders, and assessing the impact of changes. Take for example a company that needs to assess the impact of introducing a new product in its portfolio.Thismayrequiredefiningadditionalbusinessprocesses,hiringextrapersonnel,changingthe supportingapplications,andaugmentingthetechnologicalinfrastructuretosupporttheadditionalload of these applications. Perhaps this may even require a change of the organisational structure. Many stakeholderswithinandoutsidethecompanycanbeidentified,rangingfromtop-levelmanagementto softwareengineers.Eachstakeholderrequiresspecificinformationpresentedinanaccessibleway,to dealwiththeimpactofsuchwide-rangingdevelopments.Itisverydifficulttoobtainanoverviewof thesechangesandtheirimpactoneachother,andtoprovidebothdecisionmakersandengineersimplementingthechangeswiththeinformationtheyneed.Thedevelopmentofacoherentviewofanenterprise and a disciplined architectural working practice significantly contribute to the solution of complex organisational puzzles. An integrated enterprise architecture provides insight, enables communicationamongdifferentstakeholders,andguidescomplicatedchangeprocesses. The first steps towards an integrated language are described in (Jonkers et al., 2003). This paper presentsanextendedandimprovedoutlineofthislanguagebypresentingamoredetaileddiscussionof theconceptsusedinthelanguage.Inparticular,inthispaperweaddressthefollowingquestions: 1. Atwhichlevelofspecificityshouldconceptsbedescribed,andmoregenerally,whatistherelation between the integrated language and existing detailed languages? Typically, languages aimedatasingledomainareveryspecificandresultindetailedmodels.Wewanttointegrate these different domains, without substituting the existing, domain-specific modelling approaches.Asinglelanguageforalldomainswiththelevelofdetailofferedbytheseindividual approaches,however,wouldprobablyresultinanunworkablebehemoth.Ouraimistoprovide anoverviewofanentireenterprise;drillingdowntotheindividualdomainsshouldbedoneusingtheexistingapproaches. 2. Whichdomainsshouldbeidentifiedinthelanguage?Inordertoarriveatacoherentarchitectural description, several architecture domains and layers as well as their relations must be modelled.Dependingonthetypeofenterpriseandthematurityofitsarchitecturepractice,differentarchitecturaldomainsaredistinguished,suchasthe product,business,information,and applicationdomains. 3. For each domain, which concepts should be included in the language? Currently, we restrict ourselvestodescribingoperationalconceptsandrelations,i.e.,thosethatdirectlycontributeto therealisationoftheproductsorservicesofthatlayer.Manyothertypesofconceptsandrelationsarelikelytoberelevantinarchitecturaldescriptions,suchasownership,governance,support,responsibility,etc.Whereneeded,thesewillbeaddedinlaterversionsofthelanguage. 4. Howtodescribetherelationsbetweenthedomains?Therelationsbetweenthebusiness,application,andtechnologylayers,whichplayacentralroleinthisversionofthelanguage,should contributetosolvingthebusiness-ICTalignmentproblemthatwetrytotackle. Toaddressthesequestions,weproceedasfollows.First,wedefineconceptsatanintermediateabstractionlevel.Theyareapplicabletodescribeenterprisearchitecturesofanyinformation-intensiveorganisationand,ifdesired,theycanbefurtherspecialisedorcomposedtoformconceptstailoredtowardsa more specific context. Second, we base our choice for the conceptual domains on the domains commonly distinguished in architectural frameworks or methods, such as the TOGAF framework (Open Group, 2003), the Zachman framework (Sowa and Zachman, 1992), and the architectural practice withinorganisationsparticipatingintheArchiMateproject.Third,withinthearchitecturaldomains,we reuseelementsfromexistinglanguagesasmuchaspossible.Moreover,webaseourmodelonanactor perspective.Fourth,ourlanguageidentifiestheserviceconceptaslinkingpin. ThispaperisaresultfromtheArchiMateproject(Jonkersetal.,2003),apublic/privatecooperation betweenseveralcompaniesandresearchinstitutesthataimstoprovideenterprisearchitectswithconceptsandtechniquesformodelling,visualising,andanalysingintegratedarchitectures.Thesetofarchitecturemodellingconceptsdescribedinthispaper,togetherwiththeirrelationships,willbereferred

toastheArchiMatemetamodel.TheArchiMateprojectstudiestheenterprisemodellinglanguagethat representsthecomplexityofarchitecturaldomainsandespeciallytheirrelationswithinthescopeofa set of architecture instruments and techniques visualized in Figure 1. Views and presentation techniquesaretailoredtotheneedsofdifferentstakeholders,providingthemwithinsightintheirparticular areaofinterest,andfacilitatingcross-domaindiscussionandunderstanding.Theyarecenteredaround thenotionofaviewpointinaccordancewiththeIEEEstandard1471(IEEEComputerSociety,2000). Analysistechniquesareusedtoassesstheimpactofdevelopmentsandchanges.Theenterprisemodelling language is evaluated by case studies, as well as its suitability to visualize views and perform analyses.TherelationsamongtheelementsoftheArchiMateprojecthasbeensketchedin(Jonkerset al.,2003).Amoredetaileddescriptionoftherelationsaswellasadiscussiononviews,analysisand presentationisbeyondthescopeofthispaper,thoughtoillustratetheintegrationofarchitecturesinour ArchiMatelanguagewediscussanexamplethatinvolvesasimpleanalysistechnique.
Architects
viewpoint

Stakeholders

View

Models

Presentation

Analysis

analysisquestion

Figure1.ArchiMateContext Thelayoutofthispaperisasfollows.InSection2wediscussthelevelofgranularityoftheArchiMatelanguageandtherelationshipbetweentheArchiMatelanguageandotherlanguages.InSection3 wediscussourframeworkofconceptualdomains.InSections4,5and6wediscusstheconceptsofthe business layer, the application layer and the technology layer, respectively. Finally, in Section 7 we discussintra-andinter-relationships.InSection8wepresentanintegratedexamplethatinvolvesalsoa qualitativeanalysistechnique.

2. Specificityofconceptsformodellingenterprisearchitectures
Akeychallengeinthedevelopmentofageneralmetamodelforenterprisearchitectureistostrikea balancebetweenthespecificityoflanguagesforindividualarchitecturedomains,andaverygeneralset ofarchitectureconceptswhichreflectsaviewofsystemsasameresetofinterrelatedentities.Figure2 illustratesthatconceptscanbedescribedatdifferentlevelsofspecialisation.
Underlying genericconcepts

Object

morespecific

moregeneric

Relation

Application

Process

Enterprisearchitectureconcepts (ArchiMatemetamodel) Partner-specificconcepts, standards

Figure2.Metamodelsatdifferentlevelsofspecificity Atthebaseofthetriangle,wefindthemetamodelsofthearchitecturemodellingconceptsusedby specificorganisations,aswellasavarietyofexistingmodellinglanguagesandstandards;UMLisan exampleofalanguageinthiscategory.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 Project Team,2001).Itprovidesastandardframeworkbywhichbusinesssystemsmaybeconfiguredto supportexecutionofbusinesscollaborationsconsistingofbusinesstransactions.Itisfocussedon

theexternalbehaviourofprocessesforthesakeofautomatingelectroniccommercetransactions.It isthereforelesssuitedforgeneralenterprisearchitecturemodelling. x TheBusinessProcessModelingLanguageBPML(Arkin,2002)oftheBusinessProcessManagementInitiative,isanXML-basedlanguageformodellingbusinessprocessesthathasrootsinthe workflowmanagementworld.Itcanbeusedtodescribetheinnerworkingsof,e.g.,ebXMLbusinessprocesses. 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)ispartofthewidelyusedARISToolset.AlthoughARISalsocoversother conceptualdomains,thereisaclearfocusonbusinessprocessmodellingandorganisationmodelling. x TheTestbedlanguageforbusinessprocessmodelling(Eertinketal.,1999),isusedbyanumberof largeDutch organisationsin thefinancial sector,wasdeveloped bytheTelematicaInstituut. We havegainedalotofexperiencewithboththedefinitionandthepracticaluseofthislanguage,and ithasprovidedimportantinspirationforthedefinitionofbusiness-layerconcepts. x Concerninglanguagesforapplicationandtechnologymodelling,theUMListhemainstreammodellingapproachwithinICT,anditsuseisexpandingintootherareas,e.g.,inbusinessmodelling (ErikssonandPenker,2000).AnotherexampleistheUMLprofileforEnterpriseDistributedObjectComputing(EDOC),whichprovidesanarchitectureandmodellingsupportforcollaborative orInternetcomputing,withtechnologiessuchaswebservices,EnterpriseJavaBeans,andCorba components (Object Management Group, 2002b). This makes UML an important language not onlyformodellingsoftwaresystems,butalsoforbusinessprocessesandforgeneralbusinessarchitecture.TheUMLhaseitherincorporatedorsupersededmostoftheolderICTmodellingtechniques still in use. However, it is not easily accessible and understandable for managers and business specialists; therefore, special visualisations and views of UML models should be provided.AnotherimportantweaknessoftheUMListhelargenumberofdiagramtypes,withpoorly definedrelationsbetweenthem.Thisisanotherillustrationofthelackofintegrationdiscussedin theintroductionofthispaper.GiventheimportanceoftheUML,othermodellinglanguageswill likelyprovideaninterfaceormappingtoit. Atthetopofthetrianglewefindthemostgeneralmetamodelforsystemarchitectures,essentially ametamodelmerelycomprisingnotionssuchasobject,component,andrelation.Somearchitectural description languages such as ACME (Garlan, Monroe & Wile, 1997) partly fall into this category. These generic concepts may be suitable as a basis for the formal semantic description of the concepts and formal analysis techniques. There are initiatives to integrate ACME in UML, both by definingtranslationsbetweenthelanguagesandbyacollaborationwithOMGtoincludeACMEconceptsinUML2.0(U2Partners,2003).Inthisway,theconceptswillbemadeavailabletoalargeuser baseandbesupportedbyawiderangeofsoftwaretools.ThisobviatestheneedforaseparateADLfor modellingsoftwaresystems.TheArchitectureDescriptionMarkupLanguage(ADML)wasoriginally developedasanXMLencodingofACME.TheOpenGrouppromotesADMLasastandardforenterprise architectures. Moreover, the Reference Model for Open Distributed Processing (RM-ODP) is a jointISO/ITU-Tstandardforthespecificationopendistributedsystems.Itdefinesfiveviewpointson anODPsystemthateachhastheirownspecificationlanguage.Forexample,fortheenterpriseviewpoint,whichdescribespurpose,scopeandpoliciesofasystem,theRM-ODPEnterpriseLanguagehas beendefinedinwhich,e.g.,businessobjectivesandbusinessprocessescanbemodelled(ITU-T,2001). Themetamodelthatweproposedefinestheconceptssomewherebetweenthesetwoextremes.Itis more detailed than the abstract languages, because besides abstract concepts like component it also containsmoredetailedconceptslikebusinessfunction.Moreover,itismoreabstractthanforexample UML,becauseitdoesnotcontainconceptslikeTheconceptsattheintermediatelevelareapplicableto describeenterprisearchitecturesofanyinformation-intensiveorganisationand,ifdesired,theycanbe furtherspecialisedorcomposedtoformconceptstailoredtowardsamorespecificcontext. Figure1raisesthequestionhowtheArchiMatelanguageisrelatedtomoreabstractlanguages,as wellastomoredetailedlanguages.Forexample,theADLACME(Garlan,MonroeandWile,1997)is widelyacceptedasastandardtoexchangearchitecturalinformation,alsobetweenotherADLs.Cana similarrolebeplayedbytheArchiMatelanguage?Moreover,howcantheArchiMateenterprisearchitectureconceptsbeusedtointegratemorespecificmodelsdescribedinotherlanguages? A detailed discussion on the relation between the ArchiMate language and other languages is beyondthescopeofthispaper,becauseherewewanttofocusontheconceptsusedintheArciMatelan-

guage.However,asanexamplewesketchanexampleofhowtouseArchiMateconceptstodescribe thehigh-levelstructureoftheorganisation,thebusinessprocessesandtheapplicationsupportforthese processesandrelations.ToolssuchasTestbed Studio orARISfor detailedbusiness processmodels, andtoolssuchasRationalRoseorSelectComponentArchitectfordetailedUMLdesignmodels,can beusedformoredetaileddescriptions.Figure3showsanexampleofthisapproachinwhichanintegratedarchitecturalviewonanumberofdisjointUMLdiagramsisconstructedbymeansofanoverall ArchiMatemodel.
Takeoutinsurance
Request insurance

Receive request

Process request

Collect premium

Activitydiagram Component diagram

Transaction entry Bill creation
Invoice Request

Class diagram

FinancialApplication

Figure3.ExampleofArchiMateasalanguagetolinkUMLdesignmodels

3. TheconceptualdomainsintheArchiMatelanguage
The set of architecture modelling concepts described in this paper, together with their relationships, willbereferredtoastheArchiMatemetamodel.Thestartingpointforthedevelopmentofthismetamodelisacollectionofso-calledconceptualdomains,eachcoveringaspecificbusinessarea.Webase ourchoiceofconceptualdomainsonthedomainscommonlydistinguishedinarchitecturalframeworks ormethods,suchastheTOGAFframework(OpenGroup,2003),theZachmanframework(Sowaand Zachman,1992),andthearchitecturalpracticewithinorganisationsparticipatingintheArchiMateproject. Theproduct domain,withtheconceptproductthatdescribesthe(information)productsorservices thatanorganisationofferstoitscustomers. Theorganisationdomain,describingthebusinessactors(employees,organisationalunits)andtheroles theymayfulfil. Theprocessdomain,describingbusinessprocessesorbusinessfunctionsconsistingofbusinessactivities. Theinformationdomain,representingtheknowledgeinanorganisationandthewayitisstructured. Thedata domain,inwhichinformationisrepresentedinsuchawaythatitissuitableforautomated processing. Theapplicationdomain,describingsoftwareapplicationsthatsupportthebusinessthroughapplication services. Thetechnicalinfrastructuredomain,comprisingconceptsfor,e.g.,hardwareplatformsandcommunicationinfrastructure,neededtosupportapplications. Inthecurrentpracticeoforganisations,architecturaldescriptionsaremadefordifferentlayersofthe organisation. These are layers in the sense that the lower layers provide functionality to support the higherlayers.Thelayersthatareusuallyrecognisedinthiscontextarethebusinesslayer,theapplication layer and the technology layer. Although, to a certain extent, modelling support within each of these layers is available, well-described concepts to describe the relationships between the layers are almostcompletelymissing.SuchconceptsareessentialtotacklethebusinessITalignmentproblemin asystematicway. Based on the common aspects of these domains and layers, we make a first generalisation of the coreconcepts.Inourview,asystemororganisationprimarilyconsistsofasetofentities,whichhave aninternal structure,performbehaviour,anduseandexchange information.Forinstance,asales or-

ganisationmayconsistofanumberofdepartments,whichperformbusinessprocesses,usingandexchangingcustomerdata. Theaspectsandlayersformaframeworkofninecells,asillustratedinFigure4.Theconceptual domainsmentionedearlierareprojectedintothisframework.

Information aspect Business layer Application layer Technology layer Information domain Data domain Behaviour aspect Product domain Process domain Structure aspect Organisation domain

Applicationdomain

Technicalinfrastructuredomain

Figure4.Architecturalframework Itisimportanttorealisethattheclassificationofconceptsbasedonconceptualdomains,orbasedon aspectsandlayers,isonlyaglobalone.Itisimpossible,and undesirable,todefineastrictboundary betweentheaspectsandlayers,becauseconceptsthatlinkthedifferentaspectsandlayersplayoneof themostimportantrolesinacoherentarchitecturaldescription.Forexample,runningsomewhatahead ofthelaterconceptualdiscussions,servicesandrolesserveasintermediaryconceptsbetweenpurely behavioural concepts and purely structural concepts. Also, there are concepts that cover multiple aspectsandlayers.Anexampleisabusinessdomainconcept,e.g.themortgagedomainforabank, whichcoversboththebusinesslayerandapplicationlayer,andincludeselementsfromallofthethree aspects.

4. Businesslayerconcepts
Inthissectionweidentifytheconceptsforarchitecturaldescriptionsthatcanbeplacedinthebusiness layerofourframeworkofSection3.Wedescribeconceptscoveringeachofthethreeaspectsstructure,behaviourandinformationaswellasconceptslinkingtheseaspects. Figure5givesanoverviewofthebusinesslayerconceptsandtheirrelationships.Forthisfigure,as wellasfortheothermetamodelrepresentationsinthisdocument,weusearestrictedversionofUML classdiagrams.Theconceptsareroughlypositionedaccordingtothethreeaspectsofourframework. However,theboundariesbetweentheaspectsarenotstrict:someconceptsaremostnaturallyplacedon thelinethatseparatestheaspectsinFigure4.Theseconceptsmayservetomakethelinkbetweenthe conceptswithinthedifferentaspects.Inparticular,theconceptrepresentationlinksthestructuraland informational aspects, and the concepts role, collaboration and interface link the structural and behaviouralaspect.
associated with

Meaning

Representation

associated with

Business accesses object accessess accessess accessess

assigned to

associated with

Business event
triggers associated realises with Organisational uses service

triggers

Business actor

Purpose

triggers

usesrealises

triggers

triggers

assignedto

Business process/ function

triggers

triggers

Business role

Business interaction

assignedto

uses

triggers

assigned to

Business collaboration

Business interface

Figure5.Businesslayermetamodel

Picture to be inserted for final version Figure6.Exampleofabusiness-layermodel.

4.1 Structure
Thestructureaspectatthebusinesslayerreferstothestaticstructureofanorganisation,intermsofthe entitiesthatmakeuptheorganisationandtheirrelationships.Twotypesofentitiesaredistinguished: x Businessactors:theactiveentities(thesubjects)thatperformbehavioursuchasbusinessprocesses or functions. Business actors may be individual persons (e.g. customers or employees), but also groupsofpeopleandresourcesthathaveapermanent(oratleastlong-term)statuswithintheorganisations.Typicalexamplesofthelatterareadepartmentandabusinessunit. x Businessobjects:thepassiveentitiesthataremanipulatedbybehavioursuchasbusinessprocesses orfunctions.Businessobjectsrepresenttheimportantconceptsinwhichthebusinessthinksabouta domain. AlthoughUML,whichisbasedontheobject-orientedparadigm,doesnotmakethedistinctionbetween active and passive entities, these two concepts are very common in other enterprise modelling approaches. Forexample,theRM-ODPEnterpriseLanguage(Tyndale-Biscoe,2002) distinguishes actorandartefactastwospecialisationsofenterpriseobject. Atthebusinesslayer,itiscommontomakethelinkbetweenactorsandbehaviourmoreflexibleby introducing the intermediary concept business role. The idea is that the work that an actor performs withinanorganisationisalwaysbasedonacertainrolethattheactorfulfils.Thereareatleasttworeasons.First,thesetofrolesinanorganisationcanbeexpectedtobemuchmorestablethanthespecific actorsfulfillingtheseroles,sotodescribethestructureofanorganizationrolesseemtobebettercandidatesthanactors.Second,multipleactorscanfulfilthesamerole,andconversely,asingleactorcan fulfil multiple roles. Roles are typically used to distinguish responsibilities, and it can be checked whethertheassignmentofactorstorolessatisfiesdesirableproperties. Architectural descriptions focus on structure, which means that the interrelationships of entities withinanorganisationplayanimportantrole.Tomakethisexplicit,theconceptofbusinesscollaborationhasbeenintroduced.Acollaborationisacollectiveofroleswithinanorganisationwhichperform collaborativebehaviour.Businesscollaborationshavebeeninspiredbycollaborationsasdefinedinthe UML (U2 Partners, 2002), although the UML collaborations apply to components in the application layer.Also,ourbusinesscollaborationconcepthasastrongresemblancetothecommunityconceptas defined in the RM-ODP Enterprise Language (Tyndale-Biscoe, 2002), and to the interaction point concept,definedintheAMBERlanguage(Eertinketal.,1999). AswillbeexplainedinSection7.2,theserviceconceptplaysanimportantroleinlinkingmodelsin the different layers of our framework. In the light of this service-oriented approach, it is useful to havethepossibilitytoexplicitlymodelthebusinessinterfaces,i.e.,the(logicalorphysical)locations wheretheservicesthataroleofferstotheenvironmentcanbeaccessed.Thesameservicemaybeofferedonanumberofdifferentinterfaces:e.g.,bymail,bytelephoneorthroughtheInternet.Incontrast toapplicationmodelling,itisuncommonincurrentbusinesslayermodellingapproachestorecognise the business interface concept. However, the channel concept, as defined in, among others, the NEMLlanguage(Steenetal.,2002),hasastrongresemblancetoabusinessinterface.

4.2 Behaviour
Basedonserviceorientation,acrucialdesigndecisionforthebehaviouralpartofourmetamodelisthe distinctionbetweenexternalandinternalbehaviourofanorganisation.Theexternallyvisiblebehaviourismodelledbytheconceptorganisationalservice,whichrepresentsaunitoffunctionalitythat ismeaningfulfromthe point ofview oftheenvironment. Withintheorganisation,theseservicesare realisedbybusinessprocesses,businessfunctionsorbusinessinteractions.Businessprocesses,functions and interactions, in turn, may use other services (internal to the organisation, but external to a smallerentitywithintheorganisation). Abusinessprocess/functionisaunitofinternalbehaviour,performedbyoneormoreroleswithin theorganisation.Abusinessactivitycouldbedefinedasabehaviourelementthathastherightgranularitytodeterminetheservicesandapplicationsneededtosupportit.Wecansolvethisbydefininga specialisationofabusinessprocessfunction,whichhasasaconstraintthatitcannotbefurtherdecomposed.

Althoughthedistinctionbetweenthetwoisnotalwayssharp,itisoftenusefultodistinguishaprocessviewandafunctionviewonbehaviour.Bothconceptscanbeusedtogroupmoredetailedbusiness processes/functions,butbasedondifferentgroupingcriteria.Abusinessprocessrepresentsaflowof smallerprocesses/functions,withoneormoreclearstartingpointsandleadingtosomeresult(sometimesdescribedascustomertocustomer,wherecustomermayalsobeaninternalcustomer,inthe caseofsubprocesseswithinanorganisation).Abusinessfunctionoffersusefulfunctionalitythatmay beusefulforoneormorebusinessprocesses.Itgroupsbehaviourbasedon,e.g.,requiredskills,capabilities, resources, (application) support, etc. Typically, the business processes of an organisation are definedbasedontheproductsandservicesthattheorganisationoffers,whilethebusinessfunctionsare thebasisfor,e.g.,theassignmentofresourcestotasksandtheapplicationsupport. Abusinessinteractionisaunitofbehavioursimilartoabusinessprocessorfunction,butitisperformed in a collaboration of two or more roles within the organisation. This strongly resembles the interactionconceptinAMBER(Eertinketal.,1999).Similartoprocessesorfunctions,theresultofa businessinteractioncanbemadeavailabletotheenvironmentthroughanorganisationalservice. A business event is something that happens (externally) and may influence business processes, functionsorinteractions.A businesseventismostcommonly usedtomodel somethingthattriggers behaviour,butothertypesofeventsarealsoconceivable:e.g.,aneventthatinterruptsaprocess.The businesseventconceptissimilartothetriggerconceptinAMBER(Eertinketal.,1999)andtheinitial stateandfinalstateconceptsasusedin,e.g.,UMLactivitydiagrams(U2Partners,2003).

4.3 Information
Theinformationalconceptsprovideawaytolinktheoperationalsideofanorganisationtoitsbusiness goals,theinformationthatisprocessed,andtotheproductsorservicesthatanorganisationofferstoits customers. Arepresentationistheperceptibleformoftheinformationcarriedbyabusinessobject,suchasa document.Ifrelevant,representationscanbeclassifiedinvariousways,forexampleintermsofmedium(e.g.,electronic,paper,audio)orformat(e.g.,HTML,PDF,plaintext,barchart).Asinglebusinessobjectcanhaveanumberofdifferentrepresentations,butarepresentationalwaysbelongstoone specificbusinessobject. Apurposeisthefunctionalityofsomeorganisationalserviceseenfromthepointofviewofanexternaluser.Itmodelstheintendedcontributionofaservicetowardstheachievingofaparticular(business)goal,orasetofgoals.Apurposeconcernsahigh-leveldescriptionofsomebasicfunctionalityin termsofbehaviourorevensomeconditionorstatesupportedorenabledbysomeorganisationalservice,seenstrictlyfromthepointofviewofsomeexternalactor(typically,acustomer). PurposestronglyresemblesaUMLusecase.Looselyspeaking,apurposecanbeseenasacharacterisationofarequiredservice,asopposedtoanofferedservicefromtheorganisationsperspective. In this way, we have a behavioural counterpart of the required interface/offered interface duality for the structure aspect. The purpose concept provides a natural link between the operational businessprocesses,functionsandservices,andtheproductdomainthatwillbeaddedtoourmetamodel inalaterstage. Ameaningisthecontributionoftherepresentationofabusinessobjecttotheknowledgeorexpertiseofsomeactor,givenaparticularcontext.Inotherwords,meaningrepresentstheinformativevalue ofabusinessobjectforauserofsuchanobject.Itisthroughacertaininterpretationofarepresentation oftheobjectthatmeaningisbeingofferedtoacertainuserortoacertaincategoryofusers.

5. Applicationlayerconcepts
Figure7givesanoverviewoftheapplicationlayerconceptsandtheirrelationships.ManyoftheconceptshavebeeninspiredbytheUML(includingsomeoftheUML2.0proposals),asthisisthedominant language, and the de facto standard, for describing software applications. Whenever applicable, wedrawinspirationfromtheanalogywiththebusinesslayer.

Application interaction

assignedto

Application collaboration

accesses

accesses

realises uses

Data object
associated with

Application service

assigned to

Application interface

uses

accesses

uses realises

triggers

Application function

assignedto

Application component

Figure7.Application-layermetamodel Picture to be inserted for final version Figure8.Exampleofanapplication-layermodel.

5.1 Structure
The main structural concept for the application layer is the application component. This concept is used to model any structural entity in the application layer: not just (reusable) software components thatcanbepartofoneormoreapplications,butalsocompletesoftwareapplications,subapplicationsor informationsystems.ThisconceptisverysimilartotheUMLcomponent. The interrelationships of components are also an essential ingredient in application architecture. Therefore,wealsointroducetheconceptofapplicationcollaborationhere,definedasacollectiveof applicationcomponentswhichperformapplicationinteractions.TheconceptisverysimilartothecollaborationasdefinedintheUML2.0proposals(U2Partners,2002). Inthepurelystructuralsense,anapplicationinterfaceisthe(logical)locationwheretheservicesof acomponentcanbeaccessed.Inabroadersense(asusedin,amongothers,theUMLdefinition),an application interface also has some behavioural characteristics: it defines the set of operations and eventsthatareprovidedbythecomponent,orthosethatarerequiredfromtheenvironment.Thus,itis usedtodescribethefunctionalityofacomponent.Adistinctionmaybemadebetweenaprovidedinterfaceandarequiredinterface.Theapplicationinterfaceconceptcanbeusedtomodelbothapplication-to-application interfaces, offering internal application services, and application-to business interfaces(oruserinterfaces),offeringexternalapplicationservices. Also at the application layer, we distinguish the passive counterpart of the component, which we calladataobject.Thisconceptisusedinthesamewayasdataobjects(orobjecttypes)inwell-known datamodellingapproaches,mostnotablytheclassconceptinUMLclassdiagrams.

5.2 Behaviour
Behaviourintheapplicationlayercanbedescribedinawaythatisverysimilartobusinesslayerbehaviour.Wemakeadistinctionbetweentheexternalbehaviourofapplicationcomponentsintermsof applicationservices,andtheinternalbehaviourofthesecomponentstorealisetheseservices. Anapplicationserviceisanexternallyvisibleunitoffunctionality,providedbyoneormorecomponents,exposedthroughwell-definedinterfaces,andmeaningfultotheenvironment.Theserviceconceptprovidesawaytoexplicitlydescribethefunctionalitythatcomponentssharewitheachotherand thefunctionalitythattheymakeavailabletotheenvironment.Theconceptfitswellwithinthecurrent developmentsintheareaof,e.g.,webservices(Lankhorst,2002).Thetermbusinessserviceissometimesusedforanexternalapplicationservice,i.e.,applicationfunctionalitythatisusedtodirectlysupport the work performed in a business process or function, exposed by an application-to-business interface.Internalapplicationservicesareexposedthroughanapplication-to-applicationinterface. Anapplicationfunctiondescribestheinternalbehaviourofacomponentneededtorealiseoneor moreapplicationservices.Inanalogywiththebusinesslayer,aseparateapplicationflowconceptis conceivableasthecounterpartofabusinessprocess.However,forthemomentwehavedecidednotto includethisasaseparateconceptinourmetamodel. Anapplicationinteractionisthebehaviourofacollaboration oftwoormoreapplicationcomponents.TheUML2.0proposals(U2Partners,2002)alsoincludetheinteractionconcept.Anapplication

componentisexternalbehaviourfromtheperspectiveofeachoftheparticipatingcomponents,butthe behaviourisinternaltothecollaborationasawhole.

5.3 Information
Forthemoment,wehavenotdefinedany purelyinformationalconceptsattheapplicationlayer,becausethelinktoobjectivesandproductsislessapparentherethanitisatthebusinesslayer.However, itisconceivablethatapplication-layerversionsoftheinformationalconceptsturnouttobeusefulin certain situations. Given our definition of the business purpose concept, a use case, in the UML sense,wouldbeanaturalcandidateforitsapplication-layercounterpart.Thecounterpartofthebusinessmeaningconceptwouldhavetobesubjecttoautomatedinterpretation,whichsuggestssomething inthedirectionofoperationalsemantics.Furtherstudyisneededtocometothemostsuitablesetof informationalconceptsattheapplicationlayer,ifany.

6. Technologylayerconcepts
Inthissectionweidentifytheconceptsforarchitecturaldescriptionsthatcanbeplacedinthetechnologylayerofourframework.Figure9givesanoverviewoftheapplicationlayerconceptsandtheirrelationships.ManyoftheconceptshavebeeninspiredbytheupcomingUML2.0standard(U2Partners, 2003),asthisisthedominantlanguageandthedefactostandardfordescribingsoftwareapplications. Wheneverapplicable,wedrawinspirationfromtheanalogywiththebusinessandapplicationlayers.
Infrastructure service
realises assigned to

Infrastructure interface
uses

Artifact
assignedto

Node

associated with

Communication path
realises

Execution environment

assigned to

Device

associated with

Network

Figure9.Technology-layermetamodel Picture to be inserted for final version Figure10.Exampleofatechnology-layermodel.

6.1 Structure
Themainstructuralconceptfortheapplicationlayeristhenode.Thisconceptisusedtomodelstructuralentitiesinthetechnologylayer.ItisidenticaltothenodeconceptofUML2.0.Itstrictlymodels thestructuralaspectofanapplication:itsbehaviourismodelledbyanexplicitrelationshiptothebehaviouralconcepts. Aninfrastructureinterfaceisthe(logical)locationwheretheinfrastructuralservicesofferedbya nodecanbeaccessedbyothernodesorbyapplicationcomponentsfromtheapplicationlayer. Nodescomeintwoflavours:deviceandexecutionenvironment,bothtakenfromUML2.0.Adevicemodelsa physicalcomputationalresource, uponwhichartifactsmay bedeployedforexecution. Anexecutionenvironmentrepresentsthesoftwareenvironmentforspecifictypesofcomponentsand dataobjectsthataredeployedonitintheformofartifacts.Typically,anodewillconsistofanumber ofsubnodes,forexampleadevicesuchasaserverandanexecutionenvironmenttomodeltheoperatingsystem. Theinterrelationshipsofcomponentsinthetechnologylayeraremainlyformedbycommunication infrastructure. The communication path models the relation between two or more nodes, through which these nodes can exchange information. The physical realisation of a communication path is a modelledwithanetwork,i.e.,aphysicalcommunicationmediumbetweentwoormoredevices.

6.2 Behaviour
Inthetechnologylayer, thebehaviouralconceptthatwe deemrelevantistheinfrastructure service. Modelling the internal behaviour of infrastructure components such as routers or database servers wouldaddalevelofdetailthatisnotusefulattheenterpriselevelofabstraction.Infrastructureservices canbeclassifiedintothreemaintypes: x Processingservices; x Datastorageandaccessservices; x Communicationservices. Theseservicescorrespondtothethreemaintypesofphysicalinfrastructure:computingdevices,storage,andnetworks.

6.3 Information
Anartifactisaphysicalpieceofinformationthatisusedorproducedinasoftwaredevelopmentprocess,orbydeploymentandoperationofasystem.Itistherepresentation,intheformofe.g.afile,ofa dataobjectoranapplicationcomponent,andcanbeassignedto(i.e.,deployedon)anode.Theartifact concepthasbeentakenfromUML2.0.

7. Intra-andinter-layerrelationships
Intheprevioussectionswehavepresentedtheconceptstomodelthebusiness,application,andtechnologylayersofanenterprise,respectively.However,oneofthemainissuesinenterprisearchitecture isbusiness-ITalignment:howcantheselayersbematched?Manylanguagesexisttomodelbusiness architecturesontheonehand,orapplicationandtechnicalarchitecturesontheotherhand.However, languagesthatsupportacleardescriptionoftherelationshipbetweentheselayersaremissing.

7.1 Intra-layerrelationships
Ineachofthelayerspresentedthusfar,differentrelationshipsbetweenconceptshavebeenused.Table 1givesanoverviewoftheserelationships.
Table1.Intra-layerrelationships

Access Aggregation Assignment

Theaccessrelationshipmodelstheaccessofbehaviouralconceptstobusinessordata objects. Theaggregationrelationshipindicatesthatanobjectgroupsanumberofotherobjects. Theassignmentrelationshiplinksunitsofbehaviourwithactiveelements(e.g.roles, components)thatperformthem,roleswithactorsthatfulfilthem,orartifactsthatare deployedonnodes. Associationmodelsarelationshipbetweenobjectsthatisnotcoveredbyanother, morespecificrelationship. Thecompositionrelationshipindicatesthatanobjectconsistsofanumberofother objects. Therealisationrelationshiplinksalogicalentitywithamoreconcreteentitythatrealisesit.

Association Composition Realisation

Specialisation Thespecialisationrelationshipindicatesthatanobjectisaspecialisationofanother object. Triggering Use Thetriggeringrelationshipdescribesthetemporalorcausalrelationsbetweenprocesses,function,interactionsandevents. Theuserelationshipmodelstheuseofservicesbyprocesses,functionsorinteractionsandtheaccesstointerfacesbyroles,componentsorcollaborations.

Aswedidfortheconceptsusedtodescribethedifferentconceptualdomains,asmuchaspossible weadoptcorrespondingrelationshipconceptsfromexistingstandards.Forinstance,relationshipconceptssuchascomposition,association,specializationaretakenfromtheUMLwhiletriggeringisused inmostbusinessprocessmodellinglanguagessuchasARISandTestbed.

7.2 Inter-layerrelationships:theserviceconceptaslinkingpin
Generalisingfromtherelationshipspresentedintheprevioussection,itcanbeobservedthatthearchitecturallayers(business,applicationandtechnology)constitutesomesortofhierarchywithinanenterprise.Acommonwayoflookingatanenterpriseistostartfromthebusinessprocessesandactivities performed.Thesearecarriedoutbysomeactororroleintheorganisation,possiblysupportedbyone ormorebusinessapplications,orevenfullyautomated.Theseactivitieshowever,canalsobeviewedas servicestothisbusinessprocess,renderingaspecificaddedvaluetotheprocessathand. Onemayalsoadoptabottom-upstrategy,inwhichthebusinessprocessesarejustamechanismfor instantiating and commercially exploiting the lower-level services to the outside world. In this view, themostvaluableassetsarethecapabilitiestoexecutethelower-levelservices,andtheprocessesare merelyameansofexploitation.Applyingsuchaservice-orientedviewresultsinaservicehierarchy as depicted in Figure 11. This is very similar to the layered model of e.g. the ISO-OSI model (ISO, 1984). Eachlayermakestheirexternalservicesavailabletothenexthigherlayer.Theexternalservicesof thehigherlayermaydependonservicesinthesamearchitecturallayeroronelayerbelow.Organisational services, for example, may depend on external application services. Internal services are used withinthesamearchitecturallevel;forinstance,anapplicationcomponentmayuseservicesofferedby another application component. Likewise, a business process may be viewed as comprising subprocessesthatoffertheirservicestoeachotherandtothecontainingprocess.Externalorganisational servicescouldalsobecalledcustomerservices,i.e.,servicesofferedtothe(external)customersofthe enterprise.
customer

External org.service Internal org.service External app.service Internal app.service External tech.service Internal tech.service

Businesslayer

Applicationlayer

Technologylayer

Figure11.Servicearchitecture:hierarchyofservices External organisational services could also be called customer services, i.e., services offered to the (external) customers of the enterprise/system. Similarly, external application services are sometimes calledbusinessservices,i.e.,servicesofferedbyapplicationsbutusedbythebusiness. Figure12showsthemainrelationsbetweenconceptsinthebusinesslayer,theapplicationlayer,and thetechnologylayer.Forclarityssake,wehaveomittedmostintra-layerrelations.

Organisational service

Actor

Business object realises

Business interaction

Business behaviour

Business role

Business collaboration

uses Application service

uses

uses Application interface

uses

Businesslayer Applicationlayer

Data object realises

Application interaction

Application behaviour realises

Application component

Application collaboration

uses Infrastructure service

uses

uses Infrastructure interface

uses

Application layer Technologylayer

Artifact

Node

Figure12.Relationsbetweenthelayers Thereisnodirectoperationallinkbetweenbusinessobjectsanddataobjects,withouttheintervention ofbehaviour(i.e.,services):dataobjectsintheapplicationlayerareonlyavailabletothebusinesslayer throughservicesthatareofferedbyapplicationcomponents.However,thereisanimportantrealisationrelationship:oneormoredataobjectsintheapplicationlayerrealise(orrepresent)oneormore businessobjectsinthebusinesslayer. Wealsoseesuchrelisationrelationsbetweenontheonehandthedataobjectsandapplicationcomponentsintheapplicationlayer,andontheotherhandtheartifactsrepresentingtheminthetechnology layer.

8. Example
Toillustrateourapproach,weuseaservice-orientedenterprisearchitectureofanimaginaryinsurance company, ArchiSurance. Figure 13 gives a very simple example of a layered enterprise architecture usingservicestorelatetheinfrastructurelayer,theapplicationlayer,thebusinessprocesslayer,andthe environment. The insurant and insurer roles represent the client and insurance company (ArchiSurance), respectively. Invocation of the claims registration service by the insurant starts the damage claiming process.Theinsurantisinformedwhethertheclaimisaccepted,and,if so,receivesa payment. Interaction between business processes and organisational roles is through business services. Thus,servicesconnecttheprocessarchitectureandtheorganisationarchitecture.Likewise,application servicesrelatethebusinessprocessarchitecturetotheapplicationarchitecture.Theautomatedpartof each business process is provided by an external application service. These application services are realisedbyapplicationcomponents.Finally,thetechnologylayerconsistsofanumberofinfrastructure elements such as a mainframe and an application server, which execute application components and provideservicestotheapplicationlayer.

Rolesandactors

Client

Insurant

ArchiSurance

Insurer

Externalbusinessservices Claim registration service Customer information service Claims payment service

Damageclaimingprocess Registration Acceptance Valuation Payment

Externalapplicationservices Claims administration service Customer administration service Risk assessment service Payment service

Applicationcomponentsandservices

Customer administration

Risk assessment

Claims administration

Claim information service

Financial application

Externalinfrastructureservices Claim files service Customer files service

Infrastructure

zSeriesmainframe DB2 database

SunBlade iPlanet appserver Risk assessment EJB

Figure13.Exampleofaservice-orientedenterprisearchitecture Formoredetailsonthe(provisional)notationusedinthisexample,see(Buurenetal.,2003). Givenourintegratedenterprisearchitecturelanguage,asappliedintheexample,howdoesthiscontribute to the goals we have set in the introduction? More specifically, how does such an integrated modelhelpincreatinginsight,aidingcommunicationbetweenstakeholders,andassessingtheimpact ofchanges? First,astheexampleshows,ahigh-leveloverviewofanentireenterprisecanbeshowninasingle integratedandwell-definedmodel.Admittedly,ourexamplewasverysimple;inreality,suchamodel wouldbemuchlarger,requiringtechniquesforselectingandvisualisingtheelementsthatarerelevant foraparticularstakeholder. Second,thismodelcan beinterpreted by,forexample, bothamanagerrequiringthebigpicture andasoftwareengineerthatimplementsanapplicationcomponentandneedstoknowthecontextof thiscomponent.Thus,byusingsuchamodelasameansofcommunicating,differentstakeholderscan betterunderstandeachother.Withineachspecificdomain,thishigh-levelmodelmayserveasastartingpointformoredetaileddescriptions. Third,thewell-definedsemanticsoftheconceptsandtheirrelationscanbeusedtoanalysetheimpactofeventsandchanges.Forinstance,iftheSunBladeserverintheexamplemodelfails,wecan computewhichapplicationscannolongerrun,whichservicescannotbeoffered,whichprocessesare

impacted,andfinallywhichservicescannolongerbeofferedtoclients.Thisisshownbythedarkened conceptsinFigure14.Thus,amanagercandecidehowseveretheimpactofthehardwarefailuremight be,andhowrobusttheinfrastructureshouldbe.

Rolesandactors

Client

Insurant

ArchiSurance

Insurer

Externalbusinessservices Claim registration service Customer information service Claims payment service

Damageclaimingprocess Registration Acceptance Valuation Payment

Externalapplicationservices Claims administration service Customer administration service Risk assessment service Payment service

Applicationcomponentsandservices

Customer administration

Risk assessment

Claims administration

Claim information service

Financial application

Externalinfrastructureservices Claim files service Customer files service

Infrastructure

zSeriesmainframe DB2 database

SunBlade iPlanet appserver Risk assessment EJB

Figure14.Exampleofimpactanalysis;darkenedconceptsshowwhatisaffectedby failureoftheSunBladeserver

9. Conclusionsandfuturework
In this paper we have outlined a language for describing integrated enterprise architectures. This languagesaimstobringthemanyseparatearchitecturaldescriptionsforspecificarchitecturaldomains closertogether,asatpresentnoarchitecturallanguageexistsfordescribingthearchitectureofanenterpriseasawhole.Sinceseparatelanguagesandtheircorrespondingapproachesaredeeplyembedded inorganisations,itisnotrecommendabletodevelopanentirelynewlanguage.Therefore,ournewlanguageaimstoembraceandextendsuccessfulandwidelyadoptedlanguagessuchastheUML.Inparticular,inthispaperweaddressthefollowingquestions. First,atwhichlevelofspecificityshouldconceptsbedescribed,andmoregenerally,whatistherelationbetweentheintegratedlanguageandexistingdetailedlanguages?Theconceptsofourlanguage forenterprisearchitecturedescriptionholdthemiddlebetweenthedetailedconceptsthatareusedfor modelling individual domains, e.g., the UML for modelling software, and very general architecture conceptsthatviewsystemsmerelyasentitiesandtheirinter-relations.Thelanguageformsabasisfor bridgingtheheterogeneityofexistinglanguages.Currentworkintheprojectaimatdevelopingatool

integrationenvironmentinwhichmodelsoriginatingfromvarioustoolscanbelinked.Thisstimulates possiblereuseinaformthatisstillrecognisablefortheoriginaldesigner. Second, which domains should be identified in the language? Concepts in our language currently cover the business, application, and technology layers of an enterprise. Moreover, for each layer we distinguishtheinformation,behaviourandstructureaspects.Theinformation,product,process,organisation,data,applicationandtechnicalinfrastructuredomainareprojectedintothisframework. Third, for each domain, which concepts should be included in the language? For each layer, conceptsandrelationsformodellingtheinformation,behaviour,andstructureaspectsaredefined.Atthe businesslayerwedistinguishthestructuralconceptsbusinessactorsandobjects,rolesandcollaborations,thebehaviouralconceptsorganisationalservice,businessprocess,functionsandinteractionsand events,andtheinformationalconceptsrepresentation,purposeandmeaning.Attheapplicationlayer, wedistinguishthestructuralconceptsapplicationcomponent,collaboration,interface,anddataobject, andthebehaviouralconceptsofapplicationservice,functionandinteraction.Atthetechnologylayer, wedistinguishthe Fourth,howtodescribetherelationsbetweenthedomains?Usageofservicesofferedbyonelayer toanotherplaysanimportantroleinrelatingthebehaviouraspectsofthelayers.Thestructuralaspects ofthelayersarelinkedthroughtheinterfaceconcept,andtheinformationaspectsthroughrealisation relations. Looking at the metamodels for the different layers, it is apparent that they have many things in common.Theyusesimilarconceptstomodelthethreeaspectsfromourframework,beitatdifferent levelsofdetail.Itisusefultorecognisethiscommonbasisofthelayer-specificmetamodels.Thissimplifies the formalisation of the metamodels, and the same or similar analysis and visualisation techniquescanbedevelopedapplicabletobothlayers. Bymeansofasimpleexamplewehavedemonstratedthatourconceptscanbeusedtomakeacoherent description,coveringallaspectsandlayerswithinanenterprise.Wehaveillustratedthat such integrated models are very useful in creating insight, facilitating the communication between stakeholders,andassessingtheimpactofeventsandchanges.However,eventhislimitedexampledemonstratesthatthecomplexityoftheintegratedmodelsneedstobeaddressed.Thedevelopmentofviews that select and visualise relevant elements from these models for specific stakeholders helps to fully exploitthemodels. Theworkdescribedinthispaperispartofanongoingprojectforthedevelopmentofconceptsand techniquesforsupportingenterprisearchitects.Herewefocussedonthecoreconceptsandrelationsof anenterprisearchitecturelanguage.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),aresearchinitiativethataims toprovideconceptsandtechniquestosupportenterprisearchitectsinthevisualisation,communication andanalysisofintegratedarchitectures.TheArchiMateconsortiumconsistsofABNAMRO,Stichting Pensioenfonds ABP, the Dutch Tax and Customs Administration, Ordina, Telematica Instituut, CentrumvoorWiskundeenInformatica,KatholiekeUniversiteitNijmegen,andtheLeidenInstituteofAdvancedComputerScience. 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

Eertink,H.,W.Janssen,P.OudeLuttighuis,W.TeeuwandC.Vissers(1999),ABusinessProcessDesignLanguage,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,inProceedingsofCASCON97,Toronto,Canada,Nov,1997,pp.169-183. IDEF(1993),IntegrationDefinitionforFunctionModeling(IDEF0)Draft,FederalInformationProcessingStandardsPublicationFIPSPUB183,U.S.DepartmentofCommerce,Springfield,VA,USA,Dec.1993. IEEEComputerSociety(2000).IEEEStd1471-2000:IEEERecommendedPracticeforArchitecturalDescription ofSoftware-IntensiveSystems,Oct.9,2000. ISO(1984).BasicReferenceModelforOpenSystemsInterconnection,ISO7498.InternationalOrganisationfor Standardisation. ITU-T(2002),InformationtechnologyOpenDistributedProcessingReferenceModelEnterpriseLanguage, ITUTRecommendationX.911ISO/IEC15414.InternationalTelecommunicationUnion. Jonkers,H.etal.(2003),TowardsaLanguageforCoherentEnterpriseArchitectureDescription,inM.Steenand B.R.Bryant(eds.),Proceedings7thIEEEInternationalEnterpriseDistributedObjectComputingConference (EDOC2003),Brisbane,Australia,Sept2003. Medvidovic,N.andR.N.Taylor(2000),Aclassificationandcomparisonframeworkforsoftwarearchitecture descriptionlanguages,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,DelftUniversityofTechnology,Dept.ofInformationSystems,1999. Scheer,A.-W.(1994),BusinessProcessEngineering:ReferenceModelsforIndustrialEnterprises,Springer,Berlin,2nded.,1994. Sowa,J.F.andJ.A.Zachman(1992),ExtendingandFormalizingtheFrameworkforInformationSystemsArchitecture,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,OMGdocument ad/03-04-01,April10,2003.