...
Utgångspunkten för att beskriva ett lärosäte är att definiera en struktur där sambanden mellan de olika arkitekturerna inom en verksamhet kan beskrivas. Varje arkitektur innehåller ett antal entiteter. Relationer mellan entiterna skär över de olika arkitekturerna och på så sätt fås en beskrivning av hur verksamheten är strukturerad. Stadsplanen är inte en komplett karta utan kan snarare ses som en överflygning av verksamheten som ger stöd för en viss detaljering. Stadsplan ger en ingång på ett register över verksamheten. Detta brukar kallas "repository" Repository är ett vedertaget begrepp som finns definierade i flera arkitekturramverk såsom TOGAF. Vintergatan är ett annat exempel som IRM definierar. IRM har även begreppet Stadsplan och kan ses som en instansering av vintergatan mot ett visst mål. inom olika arkitekturramverk.
En verksamhet och dess olika komponenter beskrivs ibland som en EA-pyramid. Tanken med att illustrera det som en pyramid är att alla komponenter måste finnas och ha en betydelse i systemet. Varje lager i en pyramid representerar en arkitektur. Varje arkitektur måste kunna detaljeras. För att beskriva ett visst samband mellan delarna i varje arkitektur och även samband mellan arkitekturerna görs detta genom olika perspektiv. Dessa perspektiv blir vyer. Vyerna behöver förvaltas. För att förvalta vyer sparas detta i ett register, dvs ett "repository". I bilden nedan görs ett försök att illustrerar detta.
Figur 1 Enterprisearkitektur kopplat till olika arkitekturer
För att beskriva de olika komponenterna och dess samband i arkitekturen har en metamodell tagits fram. Metamodellen gör det möjligt att beskriva en verksamhet på en högre nivå och täcker inte in alla detaljeringar, men är ett bra ingångsvärde för att beskriva verksamheten. Genom att använda metamodellen och dess regelverk kan ett lärosäte relativt snabbt beskriva sin verksamhet. I arbetet med stadsplanen har ett förslag på detaljering i vissa arkitekturer gjorts som kan användas som en mall för att beskriva ett lärosäte. Förslag på detaljering har gjorts i funktions- och applikationsarkitekturen samt det tidigare arbete som är gjort inom referensarkitekturarbetet inom ATI.
I rapporten kommer även ett förslag på hur stadsplanen kan populeras och i vilken ordning detta arbete kan göras.
...
En metamodell är en generell beskrivning på hur olika generiska element är relaterade till varandra. Med hjälp av en metamodell går det att beskriva en specifik implementation baserat på de element, relationer och regler som definieras i metamodellen. Ett exempel på en metamodell är "core-concept" i modelleringsspråket ArchiMate.
Figur 2 ArciMate v2.1 Core Model
Denna modell kan sedan användas för att beskriva exempelvis hur en specifik process använder/bearbetar information och vilken roll som är tillsatt att utföra arbetet. Det är inte säkert att den specifika implementationen använder alla element i metamodellen.
Stadsplanen är en specialisering av den helt generella metamodellen för att beskriva kontexten stadsplan för lärosäte.
| Anchor | ||||
|---|---|---|---|---|
|
| Wiki Markup |
|---|
Två centrala begrepp i metamodellen är Funktion och Förmåga. För att förenkla för läsaren görs här en genomgång på dessa begrepp. Framförallt är det ordet Förmåga som har många olika betydelser i engelskan såsom "Business Skill", "Capability", "Ability", m. fl. Även när ord används i kombination ändras betydelsen. TOGAF referera till "Business Capability" som "Function" och skiljer därmed på "Capability" och "Business Capability".
*_TOGAF9 defines a Function as:_*
_Function describes units of business capability at all levels of granularity._
_The term "function" is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc._
_Any bounded unit of business function should be described as a function._
_\[a Function\] Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as "business function"._
*_TOGAF9 defines a Capability as:_*
_A business-focused outcome that is delivered by the completion of one or more work packages._
_Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value._
I svenskan har begreppet förmåga har en tvetydig användning som ibland kan ses som funktion och ibland som förmåga. I version 3 av ArchiMate finns stöd för att använda både funktion (Business Function) och förmåga (Capability). I metamodellen lutar vi oss på ArchiMates definition.
*_ArchiMate v3 defines a Capability as:_*
_\[A capability represents an ability that an active structure element, such as an organization, person, or system, possesses.\]_
_In the field of business, strategic thinking and planning delivers strategies and high-level goals that are often not directly implementable in the architecture of an organization. These long-term or generic plans need to be specified and made actionable in a way that both business leaders and Enterprise Architects can relate to and at a relatively high abstraction level._
_Capabilities help to reduce this gap by focusing on business outcomes. On the one hand, they provide a high-level view of the current and desired abilities of an organization, in relation to its strategy and its environment. On the other hand, they are realized by various elements (people, processes, systems, and so on) that can be described, designed, and implemented using Enterprise Architecture approaches. Capabilities may also have serving relationships; for example, to denote that one capability contributes to another._
_Capabilities are expressed in general and high-level terms and are typically realized by a combination of organization, people, processes, information, and technology. For example, marketing, customer contact, or outbound telemarketing \[4\]._
_Capabilities are typically aimed at achieving some goal or delivering value by realizing an outcome. Capabilities are themselves realized by core elements. To denote that a set of core elements together realizes a capability, grouping can be used._
_Capabilities are often used for capability-based planning, to describe their evolution over time. To model such so-called capability increments, the specialization relationship can be used to denote that a certain capability increment is a specific version of that capability. Aggregating those increments and the core elements that realize them in plateaus (see Section 13.2.4) can be used to model the evolution of the capabilities._
*_ArchiMate v3 defines a Business Function as:_*
_\[A business function is a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), closely aligned to an organization, but not necessarily explicitly governed by the organization.\]_
_Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process groups behavior based on a sequence or flow of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competences, knowledge, etc._
_There is a potential many-to-many relation between business processes and business functions. Complex processes in general involve activities that offer various functions. In this sense a business process forms a string of business functions. In general, a business function delivers added value from a business point of view. Organizational units or applications may coincide with business functions due to their specific grouping of business activities._
_A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may be served by business, application, or technology services. A business role may be assigned to a business function. The name of a business function should clearly indicate a well-defined behavior. Examples are customer management, claims administration, member services, recycling, or payment processing._ |
Begreppet "Capability"
Definitionerna är inte helt tydliga och framförallt exemplen som ges för exempelvis "Capability" i ArchiMate är inte tydliga för att skapa en förståelse hos läsaren. Inom engelska används, på samma sätt som i svenskan, ett flertal begrepp som används för samma betydelse såsom:
...
Dessa arkitekturer beskriver hela verksamheten uppifrån förmågor ner till infrastrukturkomponenter. Bilden nedan visar metamodellen i sin helhet. En större bild finns i som bilaga på sid Utöver basarkitekturerna finns även en koppling till mål och krav för verksamheten samt en koppling till kund. Vissa av de begrepp som används i modellen kan verka främmande för den typ av verksamhet som finns inom utbildningssektorn. Exempel kan det verka främmande att uttrycka student som en kund till lärosäte men mönstermässigt så sammanfaller synen på student som en kund till ett lärosäte väl med generella mönster av vad en kund är.
Metamodellen alla arkitekturer visas nedan. 
Figur 3 Metamodellen i sin helhet. Metamodellen finns i större format i bilaga 1 på sid
Inom varje arkitektur och i samband mellan arkitekturerna så finns det olika nivåer av detaljering. Nivåerna känns lättast igen genom att titta på en klassisk processkarta där man utgår från processområden som exempelvis stöd-, ledning- och huvud/kärnprocesser för att sedan detaljera vidare ner till lägsta nivån i form av aktiviteter.
För att metamodellen skall bli läsbar finns inte alla tillåtna relationer i ArchiMate utritade i modellen. I flera exempel som följer används relationer som inte syns i metamodellen.
| Anchor | ||||
|---|---|---|---|---|
|
...
Genom att beskriva verksamheten i termer av funktioner är det inte nödvändigt att detaljera innehållet helt utan det räcker med en övergripande beskrivning av funktionen. Detta kan sättas i relation till att beskriva en verksamhet i processer vilket kan vara väldigt tidsödande och ger ändå inte en helhetssyn av vad verksamheten behöver kunna för att leverera. Det bör gå relativt snabbt (3–4 halvdags fokuserade workshoppar med erfaren facilitator) att skapa en modell över funktionerna inom ett lärosäte. Efter att en modell över funktionerna är på plats kan arbetet fortsätta genom att detaljera verksamheten inom de andra arkitekturerna. Detta skapar snabbt en överblick på verksamheten och ett bra sätt att detaljera vidare där det finns behov av att detaljera – såsom processer som funkar sämre eller upphandling av nya IT-system etc.
Bilden nedan illustrerar en hypotes till funktionskarta som visar funktioner på översta nivån som är aktiv inom högskola- och universitetssektorn. Nivåerna är ett sätt att succesivt öka detaljeringen av funktionerna, där nivå 1 är den högsta nivån och nivå 4 är den lägsta nivån av detaljering inom ramen för metamodellen En mer detaljerad beskrivning av nivåerna finner läsaren i ett senare kapitel på sida . En funktionskarta för nivå 1 och nivå 2 finns i bilaga på sid :
Figur 4 Förslag på funktionskarta nivå 1
En bra post om funktioner (Business Capabilies) finn på:
On Business Capabilities Functions and Application Features
...
En applikationstjänst (AT) kan användas av många verksamhetsförmågor (VF). Ibland används termen IT-tjänster för applikationstjänster och det förekommer även att IT-tjänster används för verksamhetstjänster som levereras av IT. Därför används endast applikationstjänster (AT) och verksamhetstjänster (VT) inom ramen för detta arbete.
Exempel på en sammanblandning av tjänst begreppet är inom Nya Ladok. Där används termen verksamhetstjänster för produkten Ladoks applikationstjänster. Dessa tjänster representerar givetvis det behov verksamheten har men i metamodellen sorteras de under Applikationstjänster som stödjer en eller flera funktioner. Exempelvis så stödjer Nya Ladoks tjänster olika funktioner inom studieadministrativa funktionen.
Att utgå från tjänster för att beskriva en stadsplan är på samma sätt som att använda funktioner ett sätt att förenkla och reducera detaljnivån i beskrivningen av ett lärosäte. Tjänster är det som en process eller applikation exponerar utåt genom ett gränssnitt. Genom att analysera tjänsterna blir det relativt tydligt vad verksamheten behöver för resurser för att realisera sina förmågor. Det finns både interna och externa tjänster. Externa tjänster är sådana som konsumeras av externa aktörer eller är exponerade utanför sin egen verksamhet. Interna tjänster är de tjänster som funktionerna realiserar.
Vissa IT-tjänster har ingen motsvarande verksamhetstjänst utan finns bara för att "hjälpa" andra IT-tjänster. Ett exempel på detta är en integrationsplattform som levererar en IT-tjänst som konsumeras i en integrationskontext.
Tjänster kan levereras av såväl aktörer och processer som av applikationer men också i form av infrastrukturella tjänster. När det gäller applikationstjänster och processtjänster kan man generalisera och säga att det är gränssnitten som skiljer. För processtjänster som inte är automatiserade i ett system är gränssnittet mänskligt medan för processtjänster som är implementerade i ett system är gränssnittet digitalt, exempelvis en hemsida eller liknande. När det gäller infrastrukturella tjänster är det något som användare har ganska svårt att relatera till. Ett tydligt exempel på en infrastrukturell tjänst som användare kommer i kontakt med är sin dator. Med dator som tjänst menas här den fysiska produkten, inte själva användandet av datorn.
För att visa hur tjänster förhåller sig till processer och applikationstjänster kan följande bild vara hjälpsam:
Figur 5 Hur verksamhetstjänster och applikatuionstjänster samverkar
Det är alltså funktionera som realiserar verksamhetstjänsterna (VT), och funktionen (VF) använder sig av IT-tjänster (PT & RT, båda är applikationstjänster, AT) för att göra realisationen. Processerna (VP) använder sig sedan av VT för att skapa en värdekedja. En "(N4) Aktivitet" (VA) som realiserar en VT kan ses som ett specifikt implementerat beteende i en funktion.
Figur 6 Både funktion och process kan realisera tjänster men med olika innebörd
I bilden ovan kan realisationsrelationen mellan verksamhetsaktiviteten och verksamhetstjänsten härledas genom att process är en aggregering av funktion som i sin tur realiserar tjänsten. I ArchiMate kallas det för en "derived" relation. Även om relationen går att härledas behövs en tolkning av den relationen och definiera vad den betyder. Bilden ovan försöker göra en sådan definition.
En funktion på verksamhetsnivå exponerar sin funktionalitet via egna verksamhetstjänster. Dessa verksamhetstjänster kan användas av andra verksamhetstjänster på olika sätt. En eller flera verksamhetstjänster kan till exempel koreograferas av en eller flera andra verksamhetstjänster.
Figur 7 Tjänster som koroegraferas för att realisera en annan tjänst
En funktionalitet på applikationsnivå exponerar sin funktionalitet via egna applikationstjänster. Dessa applikationstjänster kan användas av andra applikationstjänster på olika sätt. En eller flera applikationstjänster kan till exempel koreograferas av en eller flera andra applikationstjänster.
...
Nivåer i arkitekturen är till för att kunna skapa en överblicksbild på hela arkitekturen. Behovet av att detaljera nivåerna beror dels på vilken typ av verksamhet som bedrivs och vilka behov den har av att kunna analysera detaljerna. I en informationsintensiv verksamhet med krav på mycket integrationer blir det naturligt att detaljera informations-, applikations- och infrastrukturarkitekturen men kanske inte processarkitekturen. För en verksamhet med krav på hög standardisering av processer, exempelvis snabbmatskedjor, blir det processarkitekturen som behöver detaljeras mer. Sedan finns det givetvis verksamheter som behöver detaljera flera arkitekturer, såsom flygbolag, för att kunna se sambanden vid en förändring.
För att skapa en ingångsmodell av stadsplanen räcker det med en ganska låg detaljering av arkitekturen men vid ett förändringsbehov kan en eller flera arkitekturer detaljeras mer, givetvis beroende på vad som är viktigt för just den förändringen. Stadsplanen kommer att bestå av flera olika perspektiv med olika grader av detaljering beroende på behoven.
För att skapa en initial bild av verksamheten kan det vara lämpligt att börja med förmågor och tjänster.
Ett exempel på nedbrytning av en arkitektur i nivåer ges av exempelvis informations- och applikationsarkitekturen
Figur 8 Informations- och applikationsarkitekturens nivåer – där N står för nivå
Ett mer konkret exempel på nedbrytning är följande exempel
Figur 9 Ett exempel på nedbrytning av applikationsarkitekturen
I följande stycken följer en förklaring av de olika arkitekturerna och i vissa beskrivningar finns det en ytterligare förtydligande när det gäller element och nivåer där det är otydligt eller kräver ytterligare förklaring.
...
Alla element i Informationsarkitekturen består av ArchiMate Business Object. Det kan upplevas som en bredare tolkning än definitionen i Archimate specifikationen - men som alltid är det kontexten som verkligen sätter definitionen. Dvs. frågan som bör ställas är vad som skall modelleras och vad betyder definitionen just i denna kontext. Metamodellen lyfter in alla nivåer i verksamheten och beskriver också en viss kontext - dvs. en strukturering av information som används i verksamheten, från övergripande nivå till detaljerad nivå.
Metamodellen i sig har inga möjligheter att uttrycka detaljerade informationsmodeller utan är ett sätt att sortera information och se hur den används. För att göra begreppsmodeller, informationsmodeller används andra modellmetoder såsom exempelvis UML. UML kan uttrycka samtliga nivåer i metamodellen modellmässigt. Det finns givetvis en uppsjö av modellspråk som går att använda men gemensamt för alla är att objekten i dessa modeller sedan kan sorteras in i metamodellen.
Figur 10 Skillnad mellan verksamhetsobjekt (VO) och informationsobjekt (IO)
(N1) Informationsområde
En grov indelning av information som visar vilken typ av information som hanteras inom verksamheten. Indelningen kan inspireras av nivå 1 inom applikationsarkitekturen exempelvis: Utbildningsinformation, affärsinformation, myndighetsinformation etc.
(N2) Informationsgrupp
Ytterligare en nedbrytning av informationen till en mer funktionsnära nivå. Det är på denna nivå som informationsägarskapet utövas. Här är det lämpligt att titta på de definierade funktionerna för att inspireras av indelningen. Denna nivå är inte helt olikt den informationsgruppering som i IRM kalls för informationskvarter.
(N3) Verksamhetsobjekt
Denna nivå relaterar till konkreta händelser i verksamheten och som är ett resultat av en (N3) Processtjänst, se figur ovan.
(N4) Informationsobjekt
Nivå 4 är den nivå där vi hittar klassiska entitetsdiagram och klassdiagram. I figuren ovan ser vi att ett VO "(N3) kursregistrering för deltagare" är uppbyggt av minst 3 IO. Dock så finns det ingen möjlighet att inom metamodellen att uttrycka andra relationer än aggregeringar av information. För att visa relationerna mellan IO krävs andra modeller såsom UML-klassdiagram eller IRM informationsmodeller.
...
För att förstå vilken information verksamheten har behov av behöver en nedbrytning av informationen göras. En bra utgångspunkt för denna nedbrytning är att förstå vilka begrepp verksamheten använder sig av. Begreppen kan beskrivas och definieras samt att enklare relationer mellan begreppen kan identifieras. Begreppsmodellen nedan visar på en hur några begrepp inom Informationsområde (N1), Utbildningsinformation, är relaterade till varandra och enklare definitioner till begreppen. Begrepp inom verksamheten kan vara väldigt generella och andra kan vara väldigt specifika. Det gör att det är en utmaning att göra nedbrytningen till informationsnivå (N4). Vissa av begreppen realiseras av flera informationsobjekt, ofta lite mer generella begrepp, eller väldigt specifika begrepp som kan vara specialiseringar av enskilda klasser.
En gemensam begreppssyn är en grundbult för att kunna digitalisera verksamheten. Otydliga definitioner på begrepp går inte att entydigt bryta ner till väl definierade informationsobjekt (N4). Då går det inte heller att realisera dataobjekt (del av systemarkitekturen) som applikationstjänster utbyter, bearbetar eller förmedlar. Dessa tjänster och tillhörande dataobjekt är den digitala representationen av verksamheten - det som vanligtvis kallas "digitalisering av verksamheten".
Figur 11 En begreppsmodell som beskriver och visar samband mellan begrepp
Figur 12 Nedbrytning från processmodell till databasmodell
...
Ett system (motsvarar applikationsgrupp N2 i metamodell) skall definieras ur ett verksamhetsperspektiv. Ett system är en sammanhängande mängd applikationskomponenter som tydligt kan identifieras från verksamheten. System som finns för att andra system skall fungera såsom exempelvis Active Directory finns men syns inte i ett sambandsperspektiv mellan system eftersom AD ofta har relationer mellan flera system. Informationsutbyte mellan system görs i en vy mellan (N2) SystemA och (N2) SystemB utan att detaljera utbytet. I exemplet nedan sker ett informationsutbyte mellan Antagningssystemet och Intranätet. Dessa har då ett beroende till varandra på systemnivå.
Figur 13 I en detaljerad bild som visar vilka delar i systemen som samverkar på hög nivå
Figur 14 Ett hypotetiskt exempel som visar att behörighetsbevsifunktionen använder sig av dokumenthantering. Modell för att illustrera hur detaljer kan utelämnas för att enklare visa samband
...
Med applikations menas tillämpning och genom att standardisera tillämpningarna inom ett lärosäte går det att skapa en överblick hur många olika mjukvaror som realiserar tillämpningarna. Det är på denna nivå som det går att identifiera applikationer som realiserar samma tillämpningar. Som beskrivit tidigare är ett mål med systemarkitekturen att minimera antalet applikationer och i idealarkitekturen endast ha en tillämpning som realiseras av en mjukvara. Givetvis är det inte möjligt i alla fall men det ger en indikation på vart det går att rationalisera. Genom detta arbete går det också att jämföra mellan lärosäten vilka tillämpningar lärosätet använder istället för att titta på vilken mjukvara som används. Det kan vara så att två lärosäten använder samma mjukvara men med olika tillämpning. Ur ett samarbetsperspektiv blir det svårare att hitta gemensamma samarbetspunkter alternativt går det att hitta nya sätt att använda mjukvaran på. En lista på förslag av tillämpningar finns som bilaga på sid
Oavsett om arkitekturen definierar tillämpningar behövs ibland en övergång från tillämpningen till den fysiska representationen av tillämpningen. I synnerhet när lärosätet skall titta på integrationer och informationsflöden mellan fysiska "system". I arbetet med att titta på LiUs "Min-IT" blir det tydligt att det är nödvändigt att gå över i ett perspektiv som beskriver den fysiska lösningen. Dock så ger möjligheten att se att det finns återkommande produkter som samma tillämpningar. Bilden nedan är ett försök att visa detta:
Figur 15 För att koppla från tillämpning till fysisk nivå kan specialisering användas
Detta ger en möjlighet att hitta "onödiga" komponenter, dock behövs detta brytas ner i applikationsfunktioner för att verkligen se om alla fysiska instanser är nödvändiga. Det kommer definitivt finnas överlapp i funktionalitet men att detta kan vara nödvändigt då infrastrukturella egenskaper kräver redundans. Ett enkelt exempel är funktionaliteten att identifiera en användare genom autentisering. Både AD (Active Directory) och AAD (Azure AD) har denna funktionalitet. Dock så skiljer egenskaperna på infrastrukturtjänsterna – den ena gör autentisering "On Site" den andra i molnet (Azure). Så finns verksamheten i molnet måste både infrastrukturtjänsterna existera.
En bild att försöka illustrera detta:
Figur 16 AAD tillhör Azure och AD tillhör lokalt. Båda behövs om verksamheten finns lokalt och i molnet.
Tidigare i rapporten har det tryckts på att informationen i verksamheten måste vara entydigt definierad för att kunna stödja digitaliseringsarbetet. Det kan vara lämpligt att övergripande titta på vilka tillämpningar som utbyter information. Eftersom det finns flera komponenter i infrastrukturen som realiserar de olika tillämpningarna betyder det att antalet integrationer blir fler än de som syns i applikationsarkitekturen när endast tillämpningen beaktas. Dock så visar modellen att informationsmängderna i de olika fysiska komponenterna behöver definieras på samma sätt. Detta är ett sätta att beskriva skillnaden mellan logik och infrastruktur. Exempelvis om lärosätet har definierat att integration skall ske genom meddelandeintegration så skall varje nod i infrastrukturen överföra meddelande mellan varandra. Dessa meddelanden innehåller data som representerar informationsmängden som skall föras över. Modellen nedan är ett sätt att minska komplexiteten på applikationsnivå men samtidigt kunna spåra hur många integrationer (transporter) som måste till för att lösa överföringen av information.
Figur 17 Flera noder realiserar samma tillämpning men informationsbehovet på tillämpningsnivå är samma, vilket leder till fler transporter än det som syns i applikationsarkitekturen
Modellen ovan kan vara abstrakt att förstå och kanske inte är användbar i verkligheten, men författaren tycker det hjälper till att förstå skillnaderna mellan ArchiMate applikationsnivå mot infrastrukturnivån.
...
Det kan vara abstrakt att dela på applikationer och infrastruktur och kräver en del tankeverksamhet. Inom infrastrukturarkitekturen hittas "hårdvara och sladdar" tillsammans med filer och databaser mm. Det finns inga logiska beteenden i infrastrukturarkitekturen. Det som kommer fram är gemensam hårdvara för olika applikationer och på vilket sätt data skickas mellan system. Förenklat går det att säga att inom applikationsarkitekturen ses sambanden mellan beteenden och tjänster samt vilken data som utbytes medan i infrastrukturarkitekturen ses hur filerna som innehåller data transporteras och vilken hårdvara detta sker emellan. Det är alltså de fysiska sambanden som visas här och ger en bild över exempelvis i vilken datahall hårdvaran står. Fysisk datasäkerhet eller virtualiserade applikationer är ett exempel på vad som tydligt visas tydligt i infrastrukturarkitekturen. Det kan vara en utmaning att hitta rätt detaljering på denna nivå och det är viktigt att hela tiden tänka på vad som skall beskrivas. Ofta går det att förenkla och beskriva exempelvis hur filer transporteras och inte hamna i en detaljering som beskriver alla komponenter och artefakter i en server.
Det är inom denna nivå som kopplingen till ATI:s referensarkitektur finns och det är på denna nivå som integrationsmönster syns. Dock inte alla integrationsmönster. I ESB fallet finns det komponenter som beskriver hur data flyttas baserat på routinglogik men detta kan implicit ses som att det är samma nod som "hämtar och skickar" filer. I och med att alla filer passerar samma nod så bör det rimligtvis finnas logik för att "fördela" trafiken till olika mottagare. I systemarkitekturen bör det synas att det finns en applikationsfunktion som läser specifika data och sedan använder en tjänst på en annan applikation för att "lämna" data. Återigen är det viktigt att inte detaljera för mycket då bilden fort blir komplex.
Som en del i arbetet med att titta på LiU har här gjort en infrastrukturmodell över LiUs integrationsplattform:
Figur 18 LiUs integrationsplattform i ett infrastrukturperespektiv
Den är inte på komplett utan försöker mer visa vilka infrastrukturtjänster som SESAM exponerar och visa vilka infrastrukturkomponenter som realiserar LiUDBs adapter. Modellen togs fram i just det syftet att visa att LiU inte använder BizTalk för att realisera deras adapter mot LiUDB. Dock så är BizTalk en viktig del i att transformera data i integrationerna.
...
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...