Forstå Verdien Av Referansearkitekturer
det er ikke noe mer som arkitekter elsker å gjøre enn å krangle om definisjoner. Hvis du noen gang finner deg selv med ledig tid i et rom med arkitekter, prøv å be om en definisjon av «Tjeneste» eller «arkitektur» og se hva slags kreativ melee du kan starte. Når det er sagt, definisjoner er faktisk svært viktig slik at vi kan ha et felles språk for å kommunisere hensikten og nytte av de tingene vi prøver å overbevise virksomheten å investere i. Fra det perspektivet har det oppstått en rekke konsepter i det siste tiåret eller så som har blitt opptatt av selvutnevnte bedriftsarkitekter: arkitekturrammer og referansearkitekturer. I tidligere ZapFlashes diskuterte vi arkitekturrammer, som etterlater temaet referansearkitekturer uberørt Av ZapThink. Siden Vi ikke kan legge igjen et godt argument bak, skal vi bruke Denne ZapFlash til å utforske hvilke referansearkitekturer som handler om og hvilken verdi DE må legge til Den Serviceorienterte Arkitekturen (SOA) historien.
Hva Er En Referansearkitektur?
En allment akseptert definisjon for referansearkitektur er at den gir en metodikk og / eller sett med praksis og maler som er basert på generalisering av et sett med vellykkede løsninger for en bestemt kategori av løsninger. Referansearkitekturer gir veiledning om hvordan man bruker bestemte mønstre og / eller praksis for å løse bestemte klasser av problemer. På denne måten fungerer den som en «referanse» for de spesifikke arkitekturene som selskapene vil implementere for å løse sine egne problemer. Det er aldri meningen at en referansearkitektur skal implementeres som den er, men heller brukes som et sammenligningspunkt eller som utgangspunkt for enkeltbedrifters arkitektoniske innsats.
Andre finjusterer definisjonen av referansearkitektur som en beskrivelse av hvordan man bygger en klasse artefakter. Disse artefakter kan være nedfelt i mange former, inkludert designmønstre, metoder, standarder, metadata, og dokumenter av alle slag. Lang historie kort, hvis du trenger veiledning om hvordan du utvikler en bestemt arkitektur basert på beste praksis eller autoritative sett med potensielle gjenstander, bør du se på en referansearkitektur som dekker omfanget av arkitekturen du ønsker å bygge.
Et av de mest populære eksemplene på referansearkitekturer I It er Java Platform Enterprise Edition (Java EE) arkitektur, som gir en lagdelt referansearkitektur og maler som adresserer en rekke teknologi – og forretningsproblemer som har styrt Mange Java-baserte bedriftssystemer.
Referansearkitekturer vs Arkitekturrammer
mens ovennevnte definisjon(er) kan virke ganske kuttet og tørket, er det mye felles mellom konseptene referansearkitekturer og arkitekturrammer. For noen er det her ting blir dicey og definisjoner blir uklare. Arkitekturrammer, Som Zachman Framework, OPEN Group Architecture Framework (TOGAF) og Department of Defense Architecture Framework (DoDAF) gir tilnærminger for å beskrive og identifisere nødvendige innganger til en bestemt arkitektur, samt midler for å beskrive den arkitekturen. Hvis en bestemt arkitektur er en kokebok som gir veiledning om hvordan man skal løse et bestemt sett med problemer med en bestemt tilnærming, er et arkitekturrammeverk en bok om hvordan man skriver kokebøker. Så, arkitektur rammer gi enterprise arkitekter verktøyene de trenger for å tilstrekkelig beskrive og samle krav, uten mandat noen bestemt arkitektur type. Nærmere bestemt beskriver arkitekturrammer et eksempel på taksonomi av hvilke arkitektoniske «synspunkter» som en arkitekt kan vurdere å utvikle, og hvorfor, og gir retningslinjer for å velge mellom å utvikle bestemte synspunkter.
dette adskiller seg fra det ovennevnte konseptet med en referansearkitektur ved at en referansearkitektur går et skritt videre ved å akselerere prosessen for en bestemt arkitekturtype, bidrar til å identifisere hvilke arkitektoniske tilnærminger som vil tilfredsstille spesielle krav, og finne ut hva et minimalt akseptabelt sett med arkitektoniske gjenstander er nødvendig for å møte kravene til «beste praksis» for en bestemt arkitektur. For å fortsette vår analogi med kokebøker, hvis et arkitekturrammeverk er en bok om hvordan man skriver kokebøker, så er en referansearkitektur en bok som gir veiledning og beste praksis for hvordan man skriver kokebøker fokusert på vekttap, for eksempel. Dette vil da bety at den bestemte arkitekturen du utvikler for organisasjonen din, vil være en bestemt kokebok som gir vekttap oppskrifter rettet mot organisasjonen din. Faktisk, hvis du blir forvirret med definisjonene, erstatte begrepet «arkitektur» med «kokebok» er nyttig: kokebok rammer, referanse kokebøker, og din bestemt kokebok.
videre understreker de fleste referansearkitekturer» mal » – delen av definisjonen av en referansearkitektur. Både rammer og RAs gir beste praksis, og mens Det kan hevdes At RAs gir mer av en metodikk enn et rammeverk, Er RAs fortsatt ikke egentlig preget av metodikkkomponenten. De fleste kan imidlertid karakteriseres av deres malkomponent. Fra dette perspektivet er mønstre forekomster av maler i denne konteksten. Faktisk er flere referansearkitekturer for samme domene tillatt og ganske nyttige. Referansearkitekturer kan være komplementære og gi veiledning for en enkelt arkitektur, for EKSEMPEL SOA, fra flere synspunkter.
VERDIEN AV EN SOA Referansearkitektur
PÅ MANGE måter ER SOA-prosjekter i desperat behov for gjennomtenkte referansearkitekturer. ZapThink ser en høy grad av variabilitet I SOA-prosjekter. Noen blomstrer og lykkes, mens andre flyter og mislykkes. Mange ganger kan årsaken til feil spores til dårlig arkitektonisk praksis, for tidlig infrastrukturinnkjøp og utilstrekkelig styring og ledelse. Andre ganger er feilen først og fremst organisatorisk. Men det som er vanlig i de fleste suksesser er veldokumentert og / eller kommunisert arkitektonisk praksis og en systematisk metode for å lære av ens feil og ha lave kostnader for feil.
videre finner vi at mange arkitekter bruker en betydelig del av sin tid på å forske, undersøke, (re-)definere ,vurdere og argumentere arkitektoniske beslutninger. I mange tilfeller er disse arkitektene gjenoppfinne hjulet som sine jevnaldrende i andre selskaper, eller til og med samme selskap, har allerede brukt den tiden og krefter definere sine egne arkitektoniske praksis. Denne ekstra innsatsen er ikke bare ineffektiv, men hindrer også selskapet i å lære av egne erfaringer og anvende denne kunnskapen for økt effektivitet.
FRA dette perspektivet KAN SOA referansearkitekturer gi litt hjelp til de som sliter MED SIN SOA-innsats eller tenker på å lansere en ny. SOA referanse arkitekturer tillate organisasjoner å lære av andre arkitekter suksesser og fiaskoer og arve bevist beste praksis. Referansearkitekturer kan gi manglende arkitektonisk informasjon som kan gis på forhånd til prosjektgruppemedlemmer for å muliggjøre konsekvent arkitektonisk beste praksis. PÅ denne måten GIR soa referansearkitektur en base av eiendeler SOM SOA innsats kan trekke fra hele prosjektets livssyklus.
for Å oppnå DE lovede SOA-fordelene ved gjenbruk, redusert redundans, reduserte integrasjonskostnader og økt synlighet og styring, må selskapene faktisk bruke SOA-innsatsen på en konsistent måte. Dette betyr mer enn å kjøpe og etablere noen leverandørs infrastruktur som en bedriftsstandard eller overholde den nyeste ws-* standardstakken. SOA referansearkitekturer kan tjene som grunnlag FOR ulik SOA-innsats i hele organisasjonen, selv om de bruker forskjellige verktøy og teknologier. Gode SOA referansearkitekturer gir SOA beste praksis og tilnærminger på en leverandør-, teknologi-og standarduavhengig måte. Derfor, ikke gå på jakt etter en fra din favoritt leverandør av valget. Faktisk, hvis DU fikk DIN SOA referansearkitektur fra den leverandøren, vil du kanskje vurdere å slippe den i stedet for noe mer leverandørnøytralt.
OASIS tilbyr SPESIELT EN Soa Reference Architecture (RA) som «modellerer abstrakte arkitektoniske elementer for EN SOA uavhengig av teknologier, protokoller og produkter som brukes til å implementere EN SOA. Noen deler AV RA vil bruke felles abstraherte elementer avledet fra flere standarder. Deres tilnærming bruker begrepet «mønstre» for å identifisere ulike metoder og tilnærminger for å implementere ulike deler av det arkitektoniske bildet. MENS OASIS SOA Referanse Arkitektur er absolutt ikke den eneste gyldige på blokken, det absolutt gjør et godt utgangspunkt for de som leter etter en leverandør-nøytral SOA referanse arkitektur som å basere sin egen arkitektoniske innsats.
ZapThink Take
Bedriftsarkitekter trenger all hjelp de kan få for å sikre at de leverer pålitelige, smidige, robuste, leverandørnøytrale arkitekturer til organisasjonen som oppfyller de stadig skiftende kravene i virksomheten. Mens kunsten og praksisen med bedriftsarkitektur fortsetter å modnes, bør selskapene se etter å låne så mye beste praksis som de kan og lære av andre som allerede har gått NED I EA og SOA-banen. Hvis DU planlegger Å lære SOA, ELLER NOEN FORM FOR EA for den saks skyld, mens du går, eller enda verre, fra en leverandør, risikerer du hele SUKSESSEN TIL SOA-innsatsen din. Snarere utnytte (gratis) SOA referansearkitekturer slik at du kan gå videre i et raskere tempo og lavere risiko. Bernard Av Chartres sa det best i det velkjente ordtaket: «vi er som dverger på kjempers skuldre, slik at vi kan se mer enn de, og ting på større avstand, ikke på grunn av noen skarphet av syn fra vår side eller noen fysisk forskjell, men fordi vi bæres høyt og oppvokst av deres gigantiske størrelse.»Stå på skuldrene til andre bedriftsarkitekturgiganter og la dem øke din visjon og suksess.