förstå värdet av referensarkitekturer
det finns inget mer som arkitekter älskar att göra än att argumentera om definitioner. Om du någonsin befinner dig med ledig tid i ett arkitektrum, försök att be om en definition av ”Service” eller ”arkitektur” och se vilken typ av kreativ melee du kan börja. Med detta sagt är definitioner verkligen mycket viktiga så att vi kan ha ett gemensamt språk för att kommunicera avsikten och nyttan av just de saker vi försöker övertyga företag att investera i. Ur det perspektivet har ett antal begrepp uppstått under det senaste decenniet eller så som har blivit top of mind för självutformade företagsarkitekter: arkitekturramar och referensarkitekturer. I tidigare ZapFlashes diskuterade vi arkitekturramar, vilket lämnar ämnet referensarkitekturer kvar orörd av ZapThink. Eftersom vi inte kan lämna ett bra argument bakom, kommer vi att använda denna ZapFlash för att utforska vilka referensarkitekturer som handlar om och vilket värde de måste lägga till Service-Oriented Architecture (SOA) – historien.
Vad är en referensarkitektur?
en allmänt accepterad definition för referensarkitektur är att den tillhandahåller en metodik och/eller uppsättning metoder och mallar som bygger på generalisering av en uppsättning framgångsrika lösningar för en viss kategori av lösningar. Referensarkitekturer ger vägledning om hur man tillämpar specifika mönster och/eller metoder för att lösa vissa klasser av problem. På detta sätt fungerar det som en ”referens” för de specifika arkitekturer som företag kommer att implementera för att lösa sina egna problem. Det är aldrig tänkt att en referensarkitektur skulle implementeras som den är, utan snarare användas antingen som en jämförelsepunkt eller som utgångspunkt för enskilda företags arkitektoniska ansträngningar.
andra förfina definitionen av referensarkitektur som en beskrivning av hur man bygger en klass av artefakter. Dessa artefakter kan förkroppsligas i många former inklusive designmönster, metoder, standarder, metadata och dokument av alla slag. Lång historia kort, om du behöver vägledning om hur du utvecklar en specifik arkitektur baserad på bästa praxis eller auktoritativa uppsättningar av potentiella artefakter, bör du titta på en referensarkitektur som täcker omfattningen av arkitekturen som du vill bygga.
ett av de mest populära exemplen på referensarkitekturer i den är Java Platform Enterprise Edition (Java EE)-arkitekturen, som ger en skiktad referensarkitektur och mallar som behandlar en rad teknik-och affärsproblem som har styrt många Java-baserade företagssystem.
referensarkitekturer vs. Arkitekturramar
medan ovanstående definition(er) kan verka ganska skurna och torkade, finns det mycket gemensamt mellan begreppen referensarkitekturer och arkitekturramar. För vissa är det här där saker blir dicey och definitioner blir suddiga. Arkitekturramar, såsom Zachman Framework, Open Group Architecture Framework (TOGAF) och Department of Defense Architecture Framework (DoDAF) ger metoder för att beskriva och identifiera nödvändiga ingångar till en viss arkitektur samt medel för att beskriva den arkitekturen. Om en viss arkitektur är en kokbok som ger vägledning om hur man ska lösa en viss uppsättning problem med ett visst tillvägagångssätt, är en arkitekturram en bok om hur man skriver kokböcker. Så, arkitekturramar ger företagsarkitekter de verktyg de behöver för att på ett adekvat sätt beskriva och samla in krav, utan att kräva någon specifik arkitekturtyp. Mer specifikt beskriver arkitekturramar ett exempel taxonomi av de typer av arkitektoniska” åsikter ” som en arkitekt kan överväga att utveckla, och varför, och ger riktlinjer för att göra valet för att utveckla särskilda åsikter.
detta skiljer sig från ovanstående koncept för en referensarkitektur genom att en referensarkitektur går ett steg längre genom att påskynda processen för en viss arkitekturtyp, hjälpa till att identifiera vilka arkitektoniska tillvägagångssätt som uppfyller särskilda krav och ta reda på vad en minimalt acceptabel uppsättning arkitektoniska artefakter behövs för att uppfylla kraven på ”bästa praxis” för en viss arkitektur. För att fortsätta vår analogi med kokböcker, om en arkitekturram är en bok om hur man skriver kokböcker, är en referensarkitektur en bok som ger vägledning och bästa praxis för hur man skriver kokböcker med fokus på viktminskning, till exempel. Detta skulle då innebära att den specifika arkitekturen du utvecklar för din organisation skulle vara en specifik kokbok som ger viktminskningsrecept riktade till din organisation. Om du blir förbryllad med definitionerna är det faktiskt bra att ersätta termen ”arkitektur” med ”kokbok: kokbok ramar, referens kokböcker, och just din kokbok.
dessutom betonar de flesta referensarkitekturer ”Mall” – delen av definitionen av en referensarkitektur. Både ramar och RAs ger bästa praxis, och även om det kan hävdas att RAs ger mer av en metod än en ram gör, RAs fortfarande inte riktigt kännetecknas av deras metodkomponent. De flesta kan kännetecknas av deras mall komponent, dock. Ur detta perspektiv är mönster instanser av mallar i detta sammanhang. Faktum är att flera referensarkitekturer för samma domän är tillåtna och ganska användbara. Referensarkitekturer kan komplettera ge vägledning för en enda arkitektur, såsom SOA, från flera synpunkter.
värdet av en SOA-referensarkitektur
på många sätt är SOA-projekt i desperat behov av väl genomtänkta referensarkitekturer. ZapThink ser en hög grad av variation i SOA-projekt. Vissa blomstrar och lyckas medan andra flundrar och misslyckas. Många gånger kan orsaken till misslyckande spåras till dåliga arkitektoniska metoder, för tidigt inköp av infrastruktur och otillräcklig styrning och ledning. Andra gånger är misslyckandet främst organisatoriskt. Det som är vanligt i de flesta framgångar är dock väldokumenterade och / eller kommunicerade arkitektoniska metoder och en systematisk metod för att lära av sina misstag och ha en låg kostnad för misslyckande.
dessutom finner vi att många arkitekter spenderar en betydande del av sin tid på att undersöka, undersöka, (om)definiera, överväga och argumentera för arkitektoniska beslut. I många fall uppfinner dessa arkitekter hjulet på nytt eftersom deras kamrater i andra företag, eller till och med samma företag, redan har spenderat den tiden och ansträngningen på att definiera sina egna arkitektoniska metoder. Denna extra ansträngning är inte bara ineffektiv utan hindrar också företaget från att lära av sina egna erfarenheter och tillämpa den kunskapen för ökad effektivitet.
ur detta perspektiv kan soa-referensarkitekturer ge lite hjälp till dem som kämpar med sina SOA-ansträngningar eller funderar på att lansera en ny. SOA-referensarkitekturer gör det möjligt för organisationer att lära av andra arkitekters framgångar och misslyckanden och ärva beprövade bästa praxis. Referensarkitekturer kan ge saknad arkitektonisk information som kan tillhandahållas i förväg till projektteammedlemmar för att möjliggöra konsekvent arkitektonisk bästa praxis. På detta sätt tillhandahåller soa-referensarkitekturen en bas av tillgångar som SOA-ansträngningar kan dra från hela projektets livscykel.
för att få de utlovade soa-fördelarna med återanvändning, minskad redundans, minskade integrationskostnader och ökad synlighet och styrning måste företagen tillämpa sina SOA-ansträngningar på ett konsekvent sätt. Det betyder mer än att köpa och etablera någon leverantörs infrastruktur som en företagsstandard eller följa den senaste ws -* – standardstacken. SOA-referensarkitekturer kan tjäna som grund för olika SOA-ansträngningar i hela organisationen, även om de använder olika verktyg och tekniker. Goda soa-referensarkitekturer ger SOA bästa praxis och tillvägagångssätt på ett leverantör-, teknik-och standardoberoende sätt. Gå därför inte på jakt efter en från din favoritförsäljare. Faktum är att om du fick din SOA-referensarkitektur från den leverantören kanske du vill överväga att släppa den i stället för något mer leverantörsneutralt.
i synnerhet erbjuder OASIS en SOA-referensarkitektur (RA) som ” modellerar de abstrakta arkitektoniska elementen för en SOA oberoende av de tekniker, protokoll och produkter som används för att implementera en SOA. Vissa delar av RA kommer att använda vanliga abstraherade element som härrör från flera standarder.”Deras tillvägagångssätt använder begreppet ”mönster” för att identifiera olika metoder och metoder för att implementera olika delar av den arkitektoniska bilden. Medan Oasis SOA-Referensarkitekturen verkligen inte är den enda giltiga på kvarteret, är den verkligen en bra utgångspunkt för dem som letar efter en leverantörsneutral SOA-referensarkitektur för att basera sina egna arkitektoniska ansträngningar.
ZapThink Take
Enterprise architects behöver all hjälp de kan få för att se till att de levererar pålitliga, smidiga, fjädrande, leverantörsneutrala arkitekturer till sin organisation som uppfyller de ständigt föränderliga kraven i verksamheten. Även om konsten och praktiken av företagsarkitektur fortsätter att mogna, bör företag se till att låna så mycket bästa praxis som de kan och lära av andra som redan har gått ner på EA-och SOA-vägen. Om du planerar att lära dig SOA, eller någon form av EA för den delen, när du går, eller ännu värre, från en leverantör, riskerar du hela framgången med dina SOA-ansträngningar. Snarare utnyttja (gratis) SOA-referensarkitekturer så att du kan avancera i snabbare takt och lägre risk. Bernard av Chartres uttryckte det bäst i det välkända ordstävet: ”vi är som dvärgar på jättarnas axlar, så att vi kan se mer än de, och saker på ett större avstånd, inte på grund av någon synskärpa från vår sida eller någon fysisk skillnad, utan för att vi bärs högt och lyfts upp av deras jättestorlek.”Stå på axlarna av andra företag arkitektur jättar och låt dem öka din vision och framgång.