de waarde van referentiearchitecturen begrijpen
er is niets meer dat architecten graag doen dan discussiëren over definities. Als je ooit merkt dat je met inactieve tijd in een kamer van architecten, probeer dan te vragen voor een definitie van “Service” of “architectuur” en zie wat voor soort creatieve melee je kunt beginnen. Dat gezegd hebbende, zijn definities inderdaad erg belangrijk, zodat we een gemeenschappelijke taal kunnen hebben om de intentie en het voordeel te communiceren van de dingen die we het bedrijfsleven proberen te overtuigen om in te investeren. Vanuit dat perspectief zijn in de afgelopen tien jaar een aantal concepten ontstaan die top of mind zijn geworden voor zelfstylende enterprise architectures: architecture frameworks en reference architectures. In eerdere ZapFlashes bespraken we architectuurkaders, waardoor het onderwerp van referentiearchitecturen onaangetast blijft bij ZapThink. Aangezien we geen goed argument achter kunnen laten, gaan we deze ZapFlash gebruiken om te onderzoeken waar referentiearchitecturen over gaan en welke waarde ze hebben toe te voegen aan het Service-Oriented Architecture (SOA) verhaal.
Wat is een referentiearchitectuur?
een algemeen aanvaarde definitie voor referentiearchitectuur is dat zij een methodologie en/of reeks praktijken en templates verschaft die gebaseerd zijn op de generalisatie van een reeks succesvolle oplossingen voor een bepaalde categorie oplossingen. Referentiearchitecturen bieden richtsnoeren voor het toepassen van specifieke patronen en / of praktijken om bepaalde klassen van problemen op te lossen. Op deze manier dient het als een “referentie” voor de specifieke architecturen die bedrijven zullen implementeren om hun eigen problemen op te lossen. Het is nooit de bedoeling dat een referentiearchitectuur in de huidige staat wordt geïmplementeerd, maar wordt eerder gebruikt als vergelijkingspunt of als uitgangspunt voor de architectonische inspanningen van individuele bedrijven.
anderen verfijnen de definitie van referentiearchitectuur als een beschrijving van hoe een klasse artefacten te bouwen. Deze artefacten kunnen worden belichaamd in vele vormen, waaronder ontwerppatronen, methodologieën, standaarden, metadata en documenten van alle soorten. Om een lang verhaal kort te maken, als je begeleiding nodig hebt over hoe je een specifieke architectuur moet ontwikkelen op basis van best practices of gezaghebbende sets van potentiële artefacten, moet je kijken naar een referentiearchitectuur die de reikwijdte dekt van de architectuur die je wilt bouwen.
een van de meest populaire voorbeelden van referentiearchitecturen is de Java Platform Enterprise Edition (Java EE) architecture, die een gelaagde referentiearchitectuur en sjablonen biedt die een reeks technologie-en bedrijfskwesties aanpakken die vele op Java gebaseerde bedrijfssystemen hebben geleid.
referentiearchitecturen vs. Architectuurkaders
hoewel de bovenstaande definitie (en) vrij kort lijkt (lijken), is er veel gemeen tussen de concepten referentiearchitecturen en architectuurkaders. Voor sommigen, dit is waar dingen worden riskant en definities wazig. Architecture frameworks, zoals het Zachman Framework, het Open Group Architecture Framework (TOGAF), en Department of Defense Architecture Framework (DoDAF) bieden benaderingen om noodzakelijke input voor een bepaalde architectuur te beschrijven en te identificeren, evenals middelen om die architectuur te beschrijven. Als een bepaalde architectuur een kookboek is dat richtlijnen geeft over hoe te gaan over het oplossen van een bepaalde reeks problemen met een bepaalde aanpak, is een architectuurkader een boek over hoe kookboeken te schrijven. Architectuurkaders geven enterprise architects dus de tools die ze nodig hebben om de vereisten adequaat te beschrijven en te verzamelen, zonder enig specifiek architectuurtype op te leggen. Meer specifiek beschrijven architectuurkaders een voorbeeld taxonomie van de soorten architectonische “opvattingen” die een architect zou kunnen ontwikkelen, en waarom, en geeft richtlijnen voor het maken van de keuze voor het ontwikkelen van bepaalde standpunten.
dit verschilt van het bovenstaande concept van een referentiearchitectuur in die zin dat een referentiearchitectuur een stap verder gaat door het proces voor een bepaald type architectuur te versnellen, door te helpen bepalen welke architecturale benaderingen aan bepaalde eisen zullen voldoen, en uit te zoeken welke minimaal aanvaardbare set architecturale artefacten nodig zijn om aan de “best practices” – eisen voor een bepaalde architectuur te voldoen. Om onze analogie met kookboeken voort te zetten, als een architectuurkader een boek is over hoe kookboeken te schrijven, dan is een referentiearchitectuur een boek dat richtlijnen en best practices biedt over hoe kookboeken te schrijven die gericht zijn op gewichtsverlies, bijvoorbeeld. Dit zou dan betekenen dat de bijzondere architectuur die u ontwikkelt voor uw organisatie een specifiek kookboek dat gewichtsverlies recepten gericht op uw organisatie biedt zou zijn. Inderdaad, als je verward raakt met de definities, is het vervangen van de term “architectuur ” door” kookboek ” nuttig: kookboek frameworks, referentie kookboeken, en uw specifieke kookboek.
bovendien benadrukken de meeste referentiearchitecturen het “template” – deel van de definitie van een referentiearchitectuur. Zowel kaders als RAs ’s bieden best practices, en hoewel kan worden gesteld dat RAs’ s meer een methodologie bieden dan een kader, worden RAs ‘ s nog steeds niet echt gekenmerkt door hun methodologische component. De meeste kunnen echter worden gekenmerkt door hun template component. Vanuit dit perspectief zijn patronen voorbeelden van sjablonen in deze context. In feite zijn meerdere referentiearchitecturen voor hetzelfde domein toegestaan en heel nuttig. Referentiearchitecturen kunnen complementair zijn en een leidraad bieden voor een enkele architectuur, zoals SOA, vanuit meerdere gezichtspunten.
de waarde van een SOA-referentiearchitectuur
in veel opzichten hebben SOA-projecten dringend behoefte aan goed doordachte referentiearchitecturen. ZapThink ziet een hoge mate van variabiliteit in SOA-projecten. Sommigen floreren en slagen, terwijl anderen botten en falen. Vaak is de oorzaak van het falen te wijten aan slechte architectuurpraktijken, voortijdige aankoop van infrastructuur en onvoldoende bestuur en beheer. Andere keren is het falen vooral organisatorisch. Echter, wat gebruikelijk is in de meeste successen zijn goed gedocumenteerde en/of gecommuniceerde architecturale praktijken en een systematische methode om te leren van iemands fouten en het hebben van een lage kosten van mislukking.Bovendien vinden we dat veel architecten een aanzienlijk deel van hun tijd besteden aan het onderzoeken, onderzoeken, (her)definiëren, overwegen en beargumenteren van architectonische beslissingen. In veel gevallen vinden deze architecten het wiel opnieuw uit, omdat hun collega ‘ s in andere bedrijven, of zelfs hetzelfde bedrijf, al die tijd en moeite hebben besteed aan het definiëren van hun eigen architectuurpraktijken. Deze extra inspanning is niet alleen inefficiënt, maar voorkomt ook dat het bedrijf leert van zijn eigen ervaringen en die kennis toepast voor meer effectiviteit.
vanuit dit perspectief kunnen de referentiearchitecturen van de SOA enige hulp bieden aan degenen die worstelen met hun SOA-inspanningen of die overwegen een nieuwe te lanceren. Soa referentiearchitecturen stellen organisaties in staat om te leren van de successen en mislukkingen van andere architecten en erven bewezen best practices. Referentiearchitecturen kunnen ontbrekende architecturale informatie bieden die vooraf aan de leden van het projectteam kan worden verstrekt om consistente architecturale best practices mogelijk te maken. Op deze manier biedt de soa-referentiearchitectuur een basis van activa waaruit SOA-inspanningen gedurende de gehele projectcyclus kunnen putten.
om de beloofde SOA-voordelen van hergebruik, minder redundantie, lagere integratiekosten en meer zichtbaarheid en governance te behalen, moeten bedrijven hun soa-inspanningen op een consistente manier toepassen. Dit betekent meer dan het kopen en tot stand brengen van de infrastructuur van sommige leveranciers als een zakelijke standaard of het voldoen aan de nieuwste ws-* standaarden stack. Soa-referentiearchitecturen kunnen dienen als basis voor uiteenlopende soa-inspanningen in de hele organisatie, zelfs als ze verschillende tools en technologieën gebruiken. Goede soa referentiearchitecturen bieden SOA best practices en benaderingen op een leverancier-, technologie-en standardonafhankelijke manier. Daarom, ga niet op jacht naar een van uw favoriete leverancier van keuze. In feite, als je je soa referentiearchitectuur van die leverancier, je zou willen overwegen om het te laten vallen in plaats van iets meer leverancier-neutraal.In het bijzonder biedt OASIS een SOA-referentiearchitectuur (RA) aan die “de abstracte architectonische elementen voor een SOA modelleert, onafhankelijk van de technologieën, protocollen en producten die worden gebruikt om een SOA te implementeren. Sommige delen van de RA zullen gebruik maken van gemeenschappelijke geabstraheerde elementen die zijn afgeleid van verschillende normen.”Hun aanpak maakt gebruik van het concept van “patronen” om verschillende methoden en benaderingen te identificeren voor het implementeren van verschillende delen van het architectonische beeld. Hoewel de Oasis SOA referentiearchitectuur zeker niet de enige geldige op het blok is, is het zeker een goed uitgangspunt voor diegenen die op zoek zijn naar een vendor-neutrale soa referentiearchitectuur waarop zij hun eigen architectonische inspanningen kunnen baseren.
de Zapthink Take
Enterprise architects heeft alle hulp nodig die ze kunnen krijgen om ervoor te zorgen dat ze betrouwbare, flexibele, veerkrachtige, leverancier-neutrale architecturen leveren aan hun organisatie die voldoen aan de voortdurend veranderende eisen van het bedrijf. Hoewel de kunst en praktijk van enterprise architecture zeker blijft rijpen, moeten bedrijven kijken naar zoveel best practices als ze kunnen lenen en leren van anderen die al zijn gegaan op de EA en SOA pad. Als je van plan bent om SOA, of welke vorm van EA dan ook, te leren, of erger nog, van een leverancier, dan riskeer je het volledige succes van je soa-inspanningen. In plaats daarvan, gebruik maken (gratis) SOA referentiearchitecturen, zodat u kunt vooruit in een sneller tempo en lager risico. Bernard van Chartres zei het het beste in het bekende gezegde: “We zijn als dwergen op de schouders van reuzen, zodat we meer kunnen zien dan zij, en dingen op een grotere afstand, niet op grond van een scherpte van het zicht van onze kant, of een fysieke onderscheid, maar omdat we worden gedragen hoog en verhoogd door hun gigantische grootte.”Sta op de schouders van andere bedrijfsarchitectuurreuzen en laat ze uw visie en succes vergroten.