Viitearkkitehtuurien arvon ymmärtäminen
ei ole mitään muuta, mitä arkkitehdit mielellään tekisivät kuin kiistelevät määritelmistä. Jos joskus löydät itsesi tyhjäkäynnillä huoneessa arkkitehdit, kokeile kysyä määritelmää ” palvelu ”tai” arkkitehtuuri ” ja katso, millainen luova nujakka voit aloittaa. Tästä huolimatta määritelmät ovat todella tärkeitä, jotta meillä on yhteinen kieli, jolla viestimme juuri niiden asioiden tarkoituksesta ja hyödystä, joihin yritämme saada yritykset investoimaan. Tästä näkökulmasta viime vuosikymmenen aikana on syntynyt useita käsitteitä, joista on tullut päällimmäisenä mielessä itseään nimittäville yritysarkkitehdeille: arkkitehtuurin viitekehykset ja referenssiarkkitehtuurit. Aiemmissa Zapflasheissa keskustelimme arkkitehtuurin kehyksistä, mikä jättää viitearkkitehtuurien aiheen koskematta Zapthinkiin. Koska emme voi jättää hyvää argumenttia taaksemme, aiomme käyttää tätä Zapflashia tutkiaksemme, mistä referenssiarkkitehtuureista on kyse ja mitä lisäarvoa niillä on palvelukeskeisen arkkitehtuurin (Soa) tarinaan.
mikä on referenssiarkkitehtuuri?
yksi yleisesti hyväksytty viitearkkitehtuurin määritelmä on, että se tarjoaa metodologian ja/tai joukon käytäntöjä ja malleja, jotka perustuvat tietyn ratkaisuluokan onnistuneiden ratkaisujen yleistämiseen. Referenssiarkkitehtuurit antavat ohjeita siitä, miten voidaan soveltaa tiettyjä malleja ja/tai käytäntöjä tiettyjen ongelmaluokkien ratkaisemiseksi. Näin se toimii ”referenssinä” niille erityisarkkitehtuureille, joita yritykset toteuttavat omien ongelmiensa ratkaisemiseksi. Viitearkkitehtuuria ei ole koskaan tarkoitus toteuttaa sellaisenaan, vaan sitä käytetään joko vertailukohtana tai yksittäisten yritysten arkkitehtuuriponnistelujen lähtökohtana.
toiset tarkentavat referenssiarkkitehtuurin määritelmää kuvaukseksi siitä, miten rakennetaan artefaktien Luokka. Nämä artefaktit voidaan sisällyttää moniin muotoihin, kuten suunnittelumalleihin, menetelmiin, standardeihin, metatietoihin ja kaikenlaisiin asiakirjoihin. Lyhyesti sanottuna, jos tarvitset ohjeita siitä, miten kehittää tiettyä arkkitehtuuria, joka perustuu parhaisiin käytäntöihin tai arvovaltaisiin mahdollisiin esineisiin, sinun pitäisi etsiä viitearkkitehtuuria, joka kattaa sen arkkitehtuurin, jonka haluat rakentaa.
yksi suosituimmista referenssiarkkitehtuureista siinä on Java Platform Enterprise Edition (Java EE)-arkkitehtuuri, joka tarjoaa kerroksellisen viitearkkitehtuurin ja malleja, jotka käsittelevät erilaisia teknologia-ja liiketoimintakysymyksiä, jotka ovat ohjanneet monia Java-pohjaisia yritysjärjestelmiä.
Reference Architectures vs. Architecture Frameworks
vaikka edellä mainitut määritelmät voivat vaikuttaa melko harvennetuilta, viitearkkitehtuurien ja arkkitehtuurin viitekehysten käsitteillä on paljon yhteistä. Joillekuille tämä on tilanne, jossa asiat muuttuvat vaikeiksi ja määritelmät hämärtyvät. Arkkitehtuurin viitekehykset, kuten Zachman Framework, Open Group Architecture Framework (TOGAF) ja Department of Defense Architecture Framework (DoDAF), tarjoavat lähestymistapoja, joilla kuvataan ja tunnistetaan tiettyyn arkkitehtuuriin tarvittavat panokset, sekä keinoja kuvata kyseistä arkkitehtuuria. Jos tietty arkkitehtuuri on keittokirja, joka antaa ohjeita siitä, miten mennä ratkaisemaan tietyn joukon ongelmia tietyllä lähestymistavalla, arkkitehtuurin viitekehys on kirja siitä, miten kirjoittaa keittokirjoja. Niinpä arkkitehtuurikehykset antavat yritysarkkitehdeille tarvittavat työkalut vaatimusten riittävään kuvaamiseen ja keräämiseen valtuuttamatta mitään tiettyä arkkitehtuurityyppiä. Tarkemmin sanottuna arkkitehtuurin viitekehykset kuvaavat esimerkin taksonomiaa siitä, millaisia arkkitehtonisia ”näkemyksiä” arkkitehti voisi harkita kehittävänsä ja miksi, ja antaa ohjeita valinnan tekemiseksi tiettyjen näkemysten kehittämiseksi.
tämä eroaa edellä mainitusta viitearkkitehtuurin käsitteestä siinä, että viitearkkitehtuuri menee askeleen pidemmälle nopeuttamalla tietyn arkkitehtuurityypin prosessia, auttamalla tunnistamaan, mitkä arkkitehtuuriset lähestymistavat täyttävät tietyt vaatimukset, ja selvittämällä, mitä minimaalisesti hyväksyttäviä arkkitehtonisia esineitä tarvitaan tietyn arkkitehtuurin ”parhaiden käytäntöjen” vaatimusten täyttämiseksi. Jos arkkitehtuurin viitekehys on kirja keittokirjojen kirjoittamisesta, viitearkkitehtuuri on kirja, joka tarjoaa ohjeita ja parhaita käytäntöjä keittokirjojen kirjoittamiseen keskittyen esimerkiksi painonpudotukseen. Tämä tarkoittaisi sitten sitä, että organisaatiollesi kehittämäsi arkkitehtuuri olisi erityinen keittokirja, joka tarjoaa organisaatiollesi kohdennettuja painonlaskureseptejä. Todellakin, jos saat ymmälläsi määritelmät, korvaa termi ”arkkitehtuuri ””keittokirja” on hyödyllistä: keittokirjan puitteet, viite keittokirjat ja oma keittokirja.
lisäksi useimmat referenssiarkkitehtuurit korostavat referenssiarkkitehtuurin määritelmän” template ” – osaa. Sekä puitteet että RAs tarjoavat parhaat käytännöt, ja vaikka voidaan väittää, että RAs tarjoaa enemmän metodologiaa kuin kehys, RAs: ille ei silti ole varsinaisesti ominaista niiden metodologinen osa. Useimmat voidaan luonnehtia niiden mallikomponentti, kuitenkin. Tästä näkökulmasta kuviot ovat esimerkkejä malleista tässä yhteydessä. Itse asiassa useat viitearkkitehtuurit samalle verkkotunnukselle ovat sallittuja ja varsin hyödyllisiä. Referenssiarkkitehtuurit voivat olla toisiaan täydentäviä, jolloin ne ohjaavat yhtä arkkitehtuuria, kuten SOA: ta, monesta näkökulmasta.
Soa-Referenssiarkkitehtuurin arvo
monin tavoin SOA-projektit tarvitsevat kipeästi harkittuja referenssiarkkitehtuureja. ZapThink näkee SOA: n hankkeissa suurta vaihtelua. Jotkut kukoistavat ja onnistuvat, kun taas toiset kampeavat ja epäonnistuvat. Epäonnistumisen syy voidaan monesti jäljittää huonoihin arkkitehtonisiin käytäntöihin, infrastruktuurin ennenaikaiseen hankintaan sekä puutteelliseen hallintoon ja johtamiseen. Muina aikoina epäonnistuminen on ensisijaisesti organisatorista. Kuitenkin, mikä on yhteistä useimmissa onnistumisissa on hyvin dokumentoitu ja / tai kommunikoitu arkkitehtonisia käytäntöjä ja systemaattinen menetelmä oppia oman virheitä ja joilla on alhainen hinta epäonnistumisesta.
lisäksi huomaamme, että monet arkkitehdit käyttävät huomattavan osan ajastaan arkkitehtonisten päätösten tutkimiseen, tutkimiseen, (uudelleen)määrittelemiseen, pohtimiseen ja väittelyyn. Monesti nämä arkkitehdit ovat keksimässä pyörää uudelleen, kun heidän vertaisensa muissa yrityksissä tai jopa samassa yrityksessä ovat jo käyttäneet tuon ajan ja vaivan omien arkkitehtuurikäytäntöjensä määrittelyyn. Tämä ylimääräinen ponnistelu ei ole ainoastaan tehotonta, vaan myös estää yritystä oppimasta omista kokemuksistaan ja soveltamasta tätä tietoa tehokkuuden lisäämiseksi.
tästä näkökulmasta Soa-referenssiarkkitehtuurit voivat tarjota apua niille, jotka kamppailevat SOA-pyrkimystensä kanssa tai harkitsevat uuden käynnistämistä. Soa-referenssiarkkitehtuurien avulla organisaatiot voivat oppia muiden arkkitehtien onnistumisista ja epäonnistumisista ja periä hyväksi havaittuja käytäntöjä. Referenssiarkkitehtuurit voivat tarjota puuttuvia arkkitehtonisia tietoja, jotka voidaan antaa etukäteen projektiryhmän jäsenille, jotta arkkitehtoniset parhaat käytännöt olisivat yhdenmukaisia. Näin SOA: n referenssiarkkitehtuuri tarjoaa perustan, jota SOA voi hyödyntää hankkeen koko elinkaaren ajan.
yritysten on sovellettava tarkastuslausuman mukaisia ponnistelujaan johdonmukaisella tavalla, jotta ne voivat saada tarkastuslausuman luvatut uudelleenkäytön edut, vähentää irtisanomisia, vähentää integraation kustannuksia sekä lisätä näkyvyyttä ja hallintoa. Tämä tarkoittaa enemmän kuin ostaa ja perustaa joitakin toimittajan infrastruktuurin yrityksen standardi tai kiinni uusimmat ws-* standardit pinoon. Soa-referenssiarkkitehtuurit voivat toimia perustana SOA: n eri toimille koko organisaatiossa, vaikka ne käyttävätkin erilaisia työkaluja ja teknologioita. Hyvät Soa-referenssiarkkitehtuurit tarjoavat SOA: n parhaita käytäntöjä ja lähestymistapoja myyjästä, teknologiasta ja standardeista riippumattomalla tavalla. Siksi, älä mene metsästämään yksi suosikki myyjä valinta. Itse asiassa, jos sait SOA-viitearkkitehtuurisi kyseiseltä myyjältä, kannattaa harkita sen pudottamista jonkin myyjäneutraalimman sijasta.
erityisesti OASIS tarjoaa SOA-Referenssiarkkitehtuurin (RA), joka ”mallintaa abstrakteja arkkitehtonisia elementtejä SOA: lle riippumatta teknologioista, protokollista ja tuotteista, joita käytetään SOA: n toteuttamiseen. Joissakin RA: n osissa käytetään yhteisiä abstrakteja elementtejä, jotka on johdettu useista standardeista.”Heidän lähestymistapansa käyttää käsitettä ”kuviot” tunnistamaan erilaisia menetelmiä ja lähestymistapoja arkkitehtuurikuvan eri osien toteuttamiseksi. Vaikka OASIS SOA Reference Architecture ei varmasti ole ainoa kelvollinen korttelin, se on varmasti hyvä lähtökohta niille, jotka etsivät myyjäneutraalia SOA reference architecture, johon perustaa oman arkkitehtonisia ponnisteluja.
Zapthink Take
Yritysarkkitehdit tarvitsevat kaiken mahdollisen avun varmistaakseen, että he toimittavat organisaatiolleen luotettavia, ketteriä, joustavia, myyjäneutraaleja arkkitehtuureja, jotka täyttävät jatkuvasti muuttuvat liiketoiminnan vaatimukset. Vaikka yritysarkkitehtuurin taiteet ja käytännöt varmasti kypsyvät edelleen, yritysten tulisi etsiä mahdollisimman paljon parhaita käytäntöjä ja oppia muilta, jotka ovat jo kulkeneet EA: n ja SOA: n polkua. Jos aiot oppia SOA: ta, tai mitä tahansa EA: ta, kun menet eteenpäin, tai vielä pahempaa, myyjältä, riskeeraat koko Soa-ponnistelujesi menestyksen. Pikemminkin hyödyntää (ilmaiseksi) SOA viittaus arkkitehtuurit, jotta voit edetä nopeammin ja pienempi riski. Bernard Chartresista esitti sen parhaiten tunnetussa sanonnassa: ”me olemme kuin kääpiöt jättiläisten hartioilla, niin että voimme nähdä enemmän kuin he ja asiat kauempana, ei minkään näkökykymme terävyyden tai fyysisen eron vuoksi, vaan siksi, että niiden jättiläiskoko nostaa meidät korkealle ja kohottaa meidät.”Seiso muiden yritysarkkitehtuurin jättiläisten harteilla ja anna heidän kasvattaa visiotasi ja menestystäsi.