Best practices bij het ontwerpen van een blockchain-gebaseerde enterprise-architectuur

In dit artikel worden richtlijnen gegeven voor het ontwerpen van enterprise-architectuur, in dit geval met blockchain en andere technologieën.

Enterprise-architectuur is een raamwerk of model dat de structuur en functie van een onderneming beschrijft. Het helpt ons architectuurcomponenten te analyseren, ontwerpen, plannen, implementeren en onderhouden. Wat we definiëren is een logische architectuur, geen fysieke architectuur. Dat is de architectuur die beschrijft wat de componenten doen, niet hoe ze in de praktijk worden geïmplementeerd.

Architecturen kunnen verschillende soorten componenten omvatten, zoals bedrijfsprocessen, organisatie-eenheden, mensen, apparaten, systemen en IT-infrastructuur. Meestal richten ze zich op systemen en ondersteunende infrastructuur, in kaart gebracht op een achtergrond die bedrijfseenheden of logische lagen toont.

Hieronder ziet u als voorbeeld de OEL Foundation Enterprise Architecture. De OEL Foundation is een organisatie zonder winstoogmerk die governance en middelen biedt voor de ontwikkeling van het blockchain-ecosysteem van Open Enterprise Logistics. De architectuur toont de componenten die worden gebruikt bij de levering van logistieke producten en diensten aan, of door, ecosysteemdeelnemers.

Hoe gaan we over het ontwerpen van een enterprise-architectuur die blockchain-technologie omvat?

Er is geen fundamenteel verschil met het ontwerpen van een architectuur - een blockchain is gewoon een ander technisch onderdeel. Er zijn echter enkele aspecten van blockchain-technologie, zoals slimme contracten, die als componenten in de architectuur moeten voorkomen.

Dus, hoe gaan we over het ontwerpen van enterprise-architectuur in het algemeen?

Er zijn geen goede of foute antwoorden, hoewel sommige benaderingen nuttiger zijn dan andere. Vergeet niet dat enterprise-architectuur ook iets leeft dat in de loop van de tijd zal veranderen en evolueren.

Er zijn een paar algemene richtlijnen die nuttig zijn bij het ontwerpen van architectuur:

1. Houd het simpel

2. Raadpleeg voorbeelden uit de branche en best practices

3. Begrijp relevante ontwikkelingen in de industrie

4. Definieer een architectuurgrens

5. Kies een organisatieprincipe (s) om te gebruiken

6. Vul de architectuur in met relevante componenten

7. Verwijs naar uw uiteindelijke architectuur met voorbeelden uit de branche

8. Bekijk en baseer de architectuur

Hou het simpel

Als iets niet eenvoudig is, komt dit meestal omdat de complexiteit een of meer factoren weerspiegelt, zoals: onvolledige analyse en ontwerp, werken op een te laag detailniveau of proberen te veel dingen in het model op te nemen.

Proberen om een ​​uitgebreide architectuurstandaard zoals het Open Group Architecture Framework (TOGAF) volledig te gebruiken, kan ook ongepast zijn, behalve voor zeer grote organisaties.

Enterprise-architectuur kan worden ontworpen met behulp van verschillende niveaus van complexiteit. Sommige enterprise-architecturen zijn erg ingewikkeld en moeilijk te begrijpen, zelfs door de mensen die ze zouden moeten gebruiken. Het is beter om de architectuur zo eenvoudig mogelijk te houden, zonder belangrijke informatie te verliezen. Dit helpt mensen de architectuur en de componenten ervan te begrijpen en te gebruiken.

Een blokdiagram is een goede basis voor een eenvoudige architectuur. Hierdoor kunnen we de belangrijkste componenten en hun brede relatie tot elkaar zien, zonder hun functie of verbindingen in detail te beschrijven.

Raadpleeg voorbeelden uit de branche en best practices

Er zijn veel voorbeelden van architecturen, met verschillende complexiteit, verschillende benaderingen en organiserende principes, en met een groot aantal verschillende soorten componenten.

Er is vaak geen standaard architectuurraamwerk of model dat als referentie kan worden gebruikt. Bij afwezigheid hiervan moeten we op zoek gaan naar voorbeelden van architectuur van toonaangevende deelnemers uit de industrie of van academici. Deze kunnen ons laten zien hoe anderen architectuuranalyse en -ontwerp hebben benaderd en kunnen dienen als basis voor onze eigen architectuur.

Het is soms gemakkelijk om zeer verschillende benaderingen te vinden, wat verwarrend kan zijn.

Een nuttige techniek is om afbeeldingen te zoeken met behulp van geschikte trefwoorden en een idee te krijgen welke modellen visueel u aanspreken. Bekijk deze op een hoog niveau, zonder in de details te verdwalen. Selecteer er vier tot vijf die voor u bijzonder relevant lijken voor verdere beoordeling en referentie.

Kijk wat ze gemeen hebben en welke verschillen er zijn. Wat zit er in de architectuur en wat niet? Probeer na te denken over de organisatieprincipes die in hun constructie worden gebruikt. Welke componenten worden vermeld? Maak je geen zorgen als je ze niet volledig begrijpt of als ze elementen bevatten die voor jou niet relevant lijken. Vergeet niet dat er geen 'goed' of 'fout' antwoord is.

Voor de OEL Foundation Enterprise Architecture hebben we architectuurmodellen van Ethereum, Ontology, CSCC / IBM, Tibco en geselecteerde industriële deelnemers als referentie gebruikt.

Begrijp relevante ontwikkelingen in de branche

We werken op elk moment in de context van een industrie en een reeks technologieën die allemaal continu veranderen. Hierdoor kunnen benaderingen die al relatief recent zijn gebruikt, irrelevant en verouderd lijken.

We moeten proberen de huidige toestand van deze context te begrijpen en ook vooruit te kijken en waarschijnlijke toekomstige ontwikkelingen in de industrie, de economie en technologieën te identificeren. Dit is erg moeilijk om te doen. De beste aanpak is om te proberen brede ontwikkelingen te identificeren die relevant worden.

Voor een op blockchain gebaseerde architectuur hebben we hier een groter nadeel dan normaal, gezien de relatieve onvolwassenheid van de technologie en het snelle tempo van verandering.

Voor de OEL Foundation Enterprise Architecture hebben we vier categorieën van ontwikkeling in de markt en technologie geïdentificeerd die naar onze mening bijzonder relevant zijn voor het ecosysteem van de OEL Foundation:

1. Digitale bedrijfsmodellen

2. Ontwikkelingen van blockchain-technologie (met name ondersteuning van opkomende ecosystemen)

3. De convergentie van blockchain- en berichtentechnologieën

4. Het toenemende gebruik en belang van cloud-gebaseerde services, zoals Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) en Infrastructure-as-a-Service (IaaS).

Definieer een architectuurgrens

Zoals elk systeem, moeten we de systeemgrens voor onze architectuur definiëren, waarbij wordt gescheiden wat zich binnen het systeem bevindt en wat zich buiten het systeem bevindt.

Soms wordt de grens niet op de juiste plaats getekend. Mogelijk zien we veel externe actoren en componenten van derden (die niet worden gebruikt om de architectuur rechtstreeks te implementeren) in een architectuur. Dit helpt ons niet om de essentiële interne componenten te identificeren die zullen worden gebruikt voor de architectuur.

Als het nuttig is om te kijken naar de relatie tussen de architectuur en de omgeving, moet dit worden gedaan met behulp van een grafisch resultaat, zoals een contextdiagram. Dit bevindt zich op een hoger abstractieniveau dan de architectuur zelf.

Voor de OEL Foundation Enterprise Architecture gebruiken we technologie en standaarden van derden in de architectuur, en maken we ook verbinding met externe partijen en systemen met behulp van architectuurcomponenten zoals API's, middleware voor berichten en interketen-integratiecomponenten. We kunnen al deze dingen beschouwen als binnen de architectuurgrens.

Ecosysteemdeelnemers, externe systemen of apparaten, of de middelen die worden gebruikt om deze met de architectuur te integreren, vallen buiten de architectuurgrens.

Kies een organisatieprincipe (s) om te gebruiken

Het organiserende principe (s) helpt ons om de architectuur te structureren en vormt een basis voor de toewijzing van architectuurcomponenten aan verschillende delen van de architectuur.

Er zijn een aantal benaderingen die we hier kunnen nemen, waaronder een of meer van de volgende:

1. End-to-end bedrijfsprocesstroom

2. Interne bedrijfsstructuur van de onderneming (met of zonder externe relaties)

3. Een standaard referentiemodel

We kunnen proberen een end-to-end bedrijfsprocesstroom te gebruiken om componenten te organiseren, zoals van leverancier naar klant gaan. Architectuurcomponenten worden vervolgens georganiseerd langs de impliciete processtroom tussen deze partijen.

Vaak weerspiegelt de architectuur de interne organisatiestructuur, die bestaat uit organisatiefuncties (of organisatie-eenheden) zoals marketing, verkoop, operations, financiën, enz. Dit kan al dan niet ook verbindingen met externe systemen of partijen omvatten.

Voor de OEL Foundation Enterprise Architecture gebruiken we een variatie van het ISO Open Systems Interconnection-model (OSI-model) als het organiserende principe. Het OSI-model is een conceptueel model dat de communicatiefuncties van een telecommunicatie- of computersysteem beschrijft.

Het OSI-model gebruikt zeven lagen, maar een aantal blockchain-gebaseerde architecturen gebruiken een drielaags model. Deze worden soms verschillend genoemd, maar omvatten meestal een laag Platform (of Toepassing), een protocollaag en een netwerklaag. De term "protocol" kan zelf verwarrend, dubbelzinnig en open voor interpretatie zijn. Het kan nuttig zijn om overeenstemming te bereiken over wat dergelijke termen betekenen, wat helpt om componenten te identificeren die in die context relevant zijn.

Vul de architectuur in met relevante componenten

Wanneer we de algemene architectuurstructuur hebben, kunnen we vervolgens beslissen welke componenten de architectuur moet bevatten en deze toewijzen aan het relevante deel van de architectuur.

We kunnen componenten gebruiken die we in referentiearchitecturen hebben geïdentificeerd, maar ook componenten die we van plan zijn op te nemen en die bekende of veronderstelde technologische ontwikkelingen of vereisten van ecosysteemdeelnemers weerspiegelen.

Dit is erg branche- en zelfs organisatie-specifiek, dus het is moeilijk om algemeen advies te geven.

Er zijn echter twee algemene principes van toepassing:

1. Componenten moeten in grote lijnen hetzelfde resolutieniveau hebben

2. Beperk het aantal componenten

We willen niet dat componenten qua grootte aanzienlijk verschillen van andere. Dit is vaak duidelijk wanneer een component zoiets als "kern" wordt genoemd, wat impliceert dat het een hoger resolutieniveau heeft dan andere componenten en mogelijk in logische delen moet worden ontbonden.

Het is handig om een ​​vuistregel te gebruiken voor het aantal componenten dat in de architectuur wordt weergegeven. Voor een grote, complexe multinationale organisatie kan dit mogelijk moeilijk zijn omdat er honderden afzonderlijke toepassingen bij betrokken kunnen zijn. Deze kunnen echter nog steeds logisch worden gegroepeerd in toepassingscategorieën. Een gebruikelijke aanpak is om zeven plus of min twee componenten per laag te gebruiken en niet meer dan twintig componenten in de hele architectuur te hebben.

Kruis uw uiteindelijke architectuur aan industriële voorbeelden

Ten slotte kunt u de architectuur vergelijken met de referentiemodellen die u in eerste instantie hebt geïdentificeerd, en deze gebruiken om uw architectuur te controleren op volledigheid en consistentie.

Controleer elk van de referentiemodellen op basis van uw architectuur en kijk of de componenten van uw referentiemodel aanwezig zijn. Als dat niet het geval is, vraag dan waarom dat zo is en of ze moeten worden opgenomen. Als uw architectuur aanvullende componenten heeft, vraag dan of deze nodig zijn en probeer te begrijpen waarom ze niet aanwezig zijn in het referentiemodel. Ze zijn mogelijk niet relevant voor de context van dat model.

Dit is een goede verstandigheidscontrole dat uw architectuur een relatie heeft met andere modellen die u in de praktijk kunt zien worden gebruikt.

Bekijk en baseer de architectuur

Op dit punt heb je een werkend model van je architectuur. U kunt het nu ter beoordeling verspreiden door collega's en andere belanghebbenden en proberen het in de praktijk te gebruiken. U zult waarschijnlijk merken dat sommige wijzigingen nodig zijn, wat normaal is. Wees niet bang om componenten te verplaatsen als u denkt dat ze niet op de juiste plaats staan, of om nieuwe componenten te verwijderen of te plaatsen.

Vergeet niet dat Enterprise-architectuur een levend wezen is dat in de loop van de tijd zal veranderen als gevolg van veranderende behoeften van de organisatie of externe veranderingen in de industrie of technologie.

Het enterprise-architectuurmodel kan nu worden geplaatst onder versiebeheer en verantwoordelijkheid voor het lopende onderhoud toegewezen aan een relevante functie of partij. In een grote organisatie kan dit een formele architectuurfunctie zijn of een individuele architect. In kleinere organisaties kan de functie worden overgenomen door een of meer personen die doorgaans bedrijfsanalisten of systeemontwerpers zijn.

We hopen dat dit artikel nuttig is om u enkele tips te geven over hoe u analyse- en ontwerpwerk voor uw eigen bedrijfsarchitectuur kunt benaderen en wensen u hierbij veel succes.

Mark Nelson is de CTO van de OEL Foundation. Als je meer wilt weten over de OEL Foundation, ga dan naar https://oel.foundation of neem rechtstreeks contact op met de auteur op mark.nelson@oel.foundation

U kunt ook lid worden van de Foundation op Telegram.