forståelse af værdien af referencearkitekturer
der er intet mere, som arkitekter elsker at gøre end at argumentere for definitioner. Hvis du nogensinde befinder dig i tomgangstid i et rum med arkitekter, kan du prøve at bede om en definition af “Service” eller “arkitektur” og se, hvilken slags kreativ nærkamp du kan starte. Når det er sagt, er definitioner faktisk meget vigtige, så vi kan have et fælles sprog til at kommunikere hensigten og fordelene ved de ting, vi forsøger at overbevise erhvervslivet om at investere i. Fra dette perspektiv er der opstået en række koncepter i det sidste årti eller deromkring, der er blevet top of mind for selvudformede virksomhedsarkitekter: arkitekturrammer og referencearkitekturer. Vi diskuterede arkitekturrammer, som efterlader emnet referencearkitekturer uberørt af Apthink. Da vi ikke kan efterlade et godt argument bag, vil vi bruge denne Apflash til at undersøge, hvad referencearkitekturer handler om, og hvilken værdi de skal tilføje til den serviceorienterede arkitektur (SOA) historie.
Hvad er en referencearkitektur?
en almindeligt accepteret definition for referencearkitektur er, at den giver en metode og/eller et sæt praksis og skabeloner, der er baseret på generalisering af et sæt vellykkede løsninger til en bestemt kategori af løsninger. Referencearkitekturer giver vejledning i, hvordan man anvender specifikke mønstre og/eller praksis for at løse bestemte klasser af problemer. På denne måde fungerer det som en “reference” for de specifikke arkitekturer, som virksomheder vil implementere for at løse deres egne problemer. Det er aldrig meningen, at en referencearkitektur skal implementeres som den er, men snarere bruges enten som et sammenligningspunkt eller som udgangspunkt for de enkelte virksomheders arkitektoniske indsats.
andre forfiner definitionen af referencearkitektur som en beskrivelse af, hvordan man bygger en klasse af artefakter. Disse artefakter kan legemliggøres i mange former, herunder designmønstre, metoder, standarder, metadata, og dokumenter af alle slags. Kort fortalt, hvis du har brug for vejledning i, hvordan du udvikler en bestemt arkitektur baseret på bedste praksis eller autoritative sæt potentielle artefakter, skal du se på en referencearkitektur, der dækker omfanget af den Arkitektur, du ønsker at bygge.
et af de mest populære eksempler på referencearkitekturer i det er Java Platform Enterprise Edition (Java EE) arkitektur, som giver en lagdelt referencearkitektur og skabeloner, der adresserer en række teknologi-og forretningsspørgsmål, der har styret mange Java-baserede virksomhedssystemer.
referencearkitekturer vs. Arkitekturrammer
mens ovenstående definition(er) kan virke ret skåret og tørret, er der meget til fælles mellem begreberne referencearkitekturer og arkitekturrammer. For nogle, det er her ting bliver dicey og definitioner bliver sløret. Arkitekturrammer, som f.eks. den åbne gruppe arkitektur ramme (TOGAF) og Department of Defense arkitektur ramme (DoDAF) giver tilgange til at beskrive og identificere nødvendige input til en bestemt arkitektur samt midler til at beskrive den arkitektur. Hvis en bestemt arkitektur er en kogebog, der giver vejledning i, hvordan man løser et bestemt sæt problemer med en bestemt tilgang, er en arkitekturramme en bog om, hvordan man skriver kogebøger. Så arkitekturrammer giver virksomhedsarkitekter de værktøjer, de har brug for til tilstrækkeligt at beskrive og indsamle krav uden at kræve nogen specifik arkitekturtype. Mere specifikt beskriver arkitekturrammer et eksempel på taksonomi af de slags arkitektoniske” synspunkter”, som en arkitekt kan overveje at udvikle, og hvorfor, og giver retningslinjer for at træffe valget til at udvikle bestemte synspunkter.
dette adskiller sig fra ovenstående koncept for en referencearkitektur, idet en referencearkitektur går et skridt videre ved at fremskynde processen for en bestemt arkitekturtype, hjælpe med at identificere, hvilke arkitektoniske tilgange der vil opfylde særlige krav, og finde ud af, hvad et minimalt acceptabelt sæt arkitektoniske artefakter er nødvendige for at opfylde kravene til “bedste praksis” for en bestemt arkitektur. For at fortsætte vores analogi med kogebøger, hvis en arkitekturramme er en bog om, hvordan man skriver kogebøger, så er en referencearkitektur en bog, der giver vejledning og bedste praksis for, hvordan man skriver kogebøger med fokus på vægttab, for eksempel. Dette ville så betyde, at den særlige arkitektur, du udvikler til din organisation, ville være en bestemt kogebog, der giver vægttabsopskrifter målrettet til din organisation. Faktisk, hvis du bliver forvirret med definitionerne, er det nyttigt at erstatte udtrykket “arkitektur” med “kogebog: kogebog rammer, reference kogebøger, og netop din kogebog.
desuden understreger de fleste referencearkitekturer “skabelon” – delen af definitionen af en referencearkitektur. Både rammer og RAs giver bedste praksis, og selvom det kan hævdes, at RAs giver mere af en metode end en ramme gør, er RAs stadig ikke rigtig karakteriseret ved deres metodekomponent. De fleste kan dog karakteriseres af deres skabelonkomponent. Fra dette perspektiv er mønstre forekomster af skabeloner i denne sammenhæng. Faktisk er flere referencearkitekturer for det samme domæne tilladte og ganske nyttige. Referencearkitekturer kan være komplementære og give vejledning til en enkelt arkitektur, såsom SOA, fra flere synspunkter.
værdien af en SOA-referencearkitektur
på mange måder er SOA-projekter i desperat behov for gennemtænkte referencearkitekturer. Vi ser en høj grad af variation i SOA-projekter. Nogle trives og lykkes, mens andre flyder og fejler. Mange gange kan årsagen til fiasko spores til dårlig arkitektonisk praksis, for tidlig indkøb af infrastruktur og utilstrækkelig styring og ledelse. Andre gange er fejlen primært organisatorisk. Det, der er almindeligt i de fleste succeser, er imidlertid veldokumenteret og/eller formidlet arkitektonisk praksis og en systematisk metode til at lære af ens fejl og have lave omkostninger ved fiasko.
desuden finder vi, at mange arkitekter bruger en betydelig del af deres tid på at undersøge, undersøge, (gen)definere, overveje og argumentere for arkitektoniske beslutninger. I mange tilfælde genopfinder disse arkitekter hjulet, da deres jævnaldrende i andre virksomheder eller endda det samme firma allerede har brugt den tid og kræfter på at definere deres egen arkitektoniske praksis. Denne ekstra indsats er ikke kun ineffektiv, men forhindrer også virksomheden i at lære af sine egne erfaringer og anvende denne viden til øget effektivitet.
fra dette perspektiv kan SOA-referencearkitekturer hjælpe dem, der kæmper med deres SOA-indsats eller tænker på at lancere en ny. SOA-referencearkitekturer giver organisationer mulighed for at lære af andre arkitekters succeser og fiaskoer og arve bevist bedste praksis. Referencearkitekturer kan give manglende arkitektoniske oplysninger, der kan leveres på forhånd til projektteammedlemmer for at muliggøre ensartet arkitektonisk bedste praksis. På denne måde giver SOA-referencearkitekturen en base af aktiver, som SOA-indsatsen kan trække på gennem hele projektets livscyklus.
for at opnå de lovede SOA-fordele ved genbrug, reduceret redundans, reducerede integrationsomkostninger og øget synlighed og styring er virksomheder faktisk nødt til at anvende deres SOA-indsats på en konsekvent måde. Det betyder mere end at købe og etablere en leverandørs infrastruktur som en virksomhedsstandard eller overholde den nyeste STANDARDSTABEL. SOA-referencearkitekturer kan tjene som grundlag for forskellige SOA-bestræbelser i hele organisationen, selvom de bruger forskellige værktøjer og teknologier. Gode SOA-referencearkitekturer giver SOA bedste praksis og tilgange på en leverandør-, teknologi-og standarduafhængig måde. Gå derfor ikke på jagt efter en fra din foretrukne leverandør af valg. Faktisk, hvis du fik din SOA-referencearkitektur fra den leverandør, kan du overveje at droppe den i stedet for noget mere leverandørneutralt.
især tilbyder OASIS en SOA Reference Architecture (RA), der “modellerer de abstrakte arkitektoniske elementer til en SOA uafhængig af de teknologier, protokoller og produkter, der bruges til at implementere en SOA. Nogle sektioner af RA vil bruge almindelige abstraherede elementer afledt af flere standarder.”Deres tilgang bruger begrebet “mønstre” til at identificere forskellige metoder og tilgange til implementering af forskellige dele af det arkitektoniske billede. Mens Oasis SOA-Referencearkitekturen bestemt ikke er den eneste gyldige på blokken, det er bestemt et godt udgangspunkt for dem, der leder efter en leverandørneutral SOA-referencearkitektur, som de kan basere deres egen arkitektoniske indsats på.
Enterprise architects har brug for al den hjælp, de kan få for at sikre, at de leverer pålidelige, smidige, robuste, leverandørneutrale arkitekturer til deres organisation, der opfylder de konstant skiftende krav i virksomheden. Mens bestemt kunsten og praksis med virksomhedsarkitektur fortsætter med at modnes, virksomheder bør se efter at låne så meget bedste praksis som de kan og lære af andre, der allerede er gået ned ad EA-og SOA-stien. Hvis du planlægger at lære SOA, eller nogen form for EA for den sags skyld, som du går sammen, eller endnu værre, fra en leverandør, så risikerer du hele succesen med din SOA indsats. Snarere gearing (gratis) SOA referencearkitekturer, så du kan gå videre i et hurtigere tempo og lavere risiko. Bernard af Chartres udtrykte det bedst i det velkendte ordsprog: “Vi er som dværge på GIGANTERNES skuldre, så vi kan se mere end de og tingene i større afstand, ikke i kraft af nogen skarphed i synet fra vores side eller nogen fysisk skelnen, men fordi vi bæres højt og hæves op af deres gigantiske størrelse.”Stå på skuldrene af andre virksomhedsarkitekturgiganter, og lad dem øge din vision og succes.