Beste praksis for utforming av en blockchain-basert bedriftsarkitektur

I denne artikkelen er det gitt retningslinjer for hvordan du designer bedriftsarkitektur, i dette tilfellet som involverer blockchain og andre teknologier.

Enterprise arkitektur er et rammeverk eller modell som beskriver strukturen og funksjonen til en bedrift. Det hjelper oss med å analysere, designe, planlegge, implementere og vedlikeholde arkitekturkomponenter. Det vi definerer er en logisk arkitektur, ikke en fysisk arkitektur. Det er arkitekturen som beskriver hva komponentene gjør, ikke hvordan de implementeres i praksis.

Arkitekturer kan omfatte forskjellige typer komponenter, for eksempel forretningsprosesser, organisasjonsenheter, personer, enheter, systemer og IT-infrastruktur. Vanligvis fokuserer de på systemer og støttende infrastruktur, kartlagt på en bakgrunn av det som viser forretningsenheter eller logiske lag.

Som et eksempel er OEL Foundation Enterprise Architecture nedenfor. OEL Foundation er en ideell organisasjon som gir styring og ressurser for utvikling av Open Enterprise Logistics blockchain-økosystemet. Arkitekturen viser komponentene som brukes i levering av logistikkprodukter og tjenester til, eller av økosystemdeltakere.

Hvordan kan vi utforme en bedriftsarkitektur som inkluderer blockchain-teknologi?

Det er ingen grunnleggende forskjell med å designe noen arkitektur - en blockchain er bare en annen teknisk komponent. Imidlertid er det noen aspekter ved blockchain-teknologi, for eksempel smarte kontrakter, som skal vises i arkitekturen som komponenter.

Så, hvordan skal vi utforme bedriftsarkitektur generelt?

Det er ingen "riktige" eller "gale" svar, selv om noen tilnærminger er mer nyttige enn andre. Husk at virksomhetsarkitektur også er en levende ting som vil endre seg og utvikle seg over tid.

Det er noen generelle retningslinjer som er nyttige i arkitekturdesign:

1. Hold det enkelt

2. Se bransjeeksempler og beste praksis

3. Forstå relevant industriutvikling

4. Definer en arkitekturgrense

5. Bestem deg for et (e) organisasjonsprinsipp (er) som skal brukes

6. Populere arkitekturen med relevante komponenter

7. Kryssreferanse den endelige arkitekturen din med bransjeeksempler

8. Gjennomgå og baseline arkitekturen

Hold det enkelt

Generelt, hvis noe ikke er enkelt, skyldes det vanligvis at kompleksiteten reflekterer en eller flere faktorer som: ufullstendig analyse og design, arbeider på et for lite detaljnivå eller prøver å inkludere for mange ting i modellen.

Det kan også være upassende å prøve å bruke en omfattende arkitekturstandard som The Open Group Architecture Framework (TOGAF), annet enn for veldig store organisasjoner.

Bedriftsarkitektur kan utformes ved bruk av forskjellige grader av kompleksitet. Noen bedriftsarkitekturer er veldig kompliserte og vanskelig å forstå, selv av menneskene som skal bruke dem. Det er bedre å holde arkitekturen så enkel som mulig, uten å miste nøkkelinformasjon. Dette hjelper folk til å forstå og bruke arkitekturen og dens komponenter.

Et blokkskjema er et godt grunnlag for en enkel arkitektur. Dette lar oss se hovedkomponentene og deres brede forhold til hverandre, uten å beskrive detaljert deres funksjon eller forbindelser.

Se bransjeeksempler og beste praksis

Det er mange eksempler på arkitekturer, med varierende kompleksitet, forskjellige tilnærminger og organiseringsprinsipper, og med et stort antall forskjellige typer komponenter.

Det er ofte ingen standard arkitekturramme eller modell som kan brukes som referanse. I mangel av dette, bør vi se etter arkitektureksempler fra ledende industrideltakere eller fra akademikere. Disse kan vise oss hvordan andre har nærmet seg arkitekturanalyse og design, og kan tjene som grunnlag for vår egen arkitektur.

Noen ganger er det lett å finne vidt forskjellige fremgangsmåter, noe som kan være forvirrende.

En nyttig teknikk er å søke etter bilder ved hjelp av passende nøkkelord og få en følelse av hvilke modeller som appellerer til deg visuelt. Gjennomgå disse på et høyt nivå, uten å gå deg vill i detaljene. Velg fire til fem av dem som virker spesielt relevante for deg for videre gjennomgang og referanse.

Se hva de har til felles og hvilke forskjeller det er. Hva er inkludert i arkitekturen, og hva er ikke? Prøv å tenke på organiseringsprinsippet som brukes i konstruksjonen. Hvilke komponenter er oppført? Ikke bekymre deg hvis du ikke helt forstår dem, eller hvis de inneholder elementer som virker irrelevante for deg. Husk at det ikke er noe "riktig" eller "galt" svar.

For OEL Foundation Enterprise Architecture brukte vi arkitekturmodeller fra Ethereum, Ontology, CSCC / IBM, Tibco og utvalgte bransjedeltakere som referanser.

Forstå relevant industriutvikling

Vi jobber når som helst innenfor en industri og et sett av teknologier som alle endres kontinuerlig. Dette kan gjøre at tilnærminger som ble brukt til og med relativt nylig virker irrelevante og utdaterte.

Vi må prøve å forstå dagens tilstand i denne sammenhengen og også prøve å se fremover og identifisere sannsynlig fremtidig utvikling i industrien, økonomien og teknologiene. Dette er veldig vanskelig å gjøre. Den beste tilnærmingen er å prøve å identifisere en bred utvikling som kommer til å være relevant.

For en blockchain-basert arkitektur er vi mer en ulempe her enn vanlig, gitt teknologiens relative umodenhet og den raske endringen.

For OEL Foundation Enterprise Architecture identifiserte vi fire kategorier av utvikling i markedet og teknologi som vi mener er spesielt relevante for OEL Foundation økosystem:

1. Digitale forretningsmodeller

2. Blockchain-teknologiutviklingen (spesielt økende økosystemstøtte)

3. Konvergens av blockchain- og meldingsteknologier

4. Den økende bruken og viktigheten av skybaserte tjenester, for eksempel Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) og Infrastructure-as-a-Service (IaaS).

Definer en arkitekturgrense

Som ethvert system, må vi definere systemgrensen for vår arkitektur, skille hva som er inne i systemet og hva som er utenfor systemet.

Noen ganger trekkes ikke grensen på rett sted. Vi kan se mange eksterne aktører og tredjepartskomponenter (som ikke brukes til å implementere arkitekturen direkte) i en arkitektur. Dette hjelper oss ikke med å identifisere de essensielle interne komponentene som vil bli brukt for arkitekturen.

Hvis det er nyttig å se på arkitekturens forhold til omgivelsene, bør dette gjøres ved hjelp av en grafisk leverbar for eksempel et kontekstdiagram. Dette er på et høyere abstraksjonsnivå enn selve arkitekturen.

For OEL Foundation Enterprise Architecture bruker vi tredjeparts teknologi og standarder i arkitekturen, og kobler også til eksterne parter og systemer ved bruk av arkitekturkomponenter som API-er, messaging-mellomvare og inter-chain integrasjonskomponenter. Vi kan betrakte alle disse tingene som å være innenfor arkitekturgrensen.

Økosystemdeltakere, eksterne systemer eller enheter eller midlene som brukes for å integrere disse med arkitekturen ligger utenfor arkitekturgrensen.

Bestem deg for et (e) organisasjonsprinsipp (er) som skal brukes

Organiseringsprinsippet hjelper oss med å strukturere arkitekturen og danner et grunnlag for tildelingen av arkitekturkomponenter til forskjellige deler av arkitekturen.

Det er en rekke tilnærminger som vi kan ta her, inkludert en eller flere av følgende:

1. Endel til ende forretningsprosessflyt

2. Enterprise intern organisasjonsstruktur (med eller uten eksterne relasjoner)

3. En standard referansemodell

Vi kan prøve å bruke en ende-til-ende forretningsprosessflyt for å organisere komponenter, for eksempel å gå fra en leverandør til en kunde. Arkitekturkomponenter blir deretter organisert langs den underforståtte prosessflyten mellom disse partiene.

Ofte reflekterer arkitekturen den interne organisasjonsstrukturen, som er sammensatt av organisasjonsfunksjoner (eller organisasjonsenheter) som markedsføring, salg, drift, økonomi osv. Dette kan også omfatte forbindelser med eksterne systemer eller parter.

For OEL Foundation Enterprise Architecture bruker vi en variant av ISO Open Systems Interconnection-modellen (OSI-modellen) som organisasjonsprinsipp. OSI-modellen er en konseptuell modell som beskriver kommunikasjonsfunksjonene til et telekommunikasjons- eller datasystem.

OSI-modellen bruker syv lag, men en rekke blockchain-baserte arkitekturer bruker en trelags modell. Disse er noen ganger navngitt på forskjellige måter, men består vanligvis av et plattform (eller applikasjons) lag, et protokollag og et nettverkslag. Begrepet "protokoll" kan i seg selv være forvirrende, tvetydig og åpent for tolkning. Det kan være nyttig å bli enige om hva slike begreper betyr, noe som er med på å identifisere komponenter som er relevante i den sammenhengen.

Befolk arkitekturen med relevante komponenter

Når vi har den overordnede arkitekturstrukturen, kan vi deretter bestemme hvilke komponenter arkitekturen skal inneholde og tilordne disse til den relevante delen av arkitekturen.

Vi kan bruke komponenter som vi identifiserte i referansearkitekturer, så vel som komponenter som vi har til hensikt å innlemme som gjenspeiler kjent eller antatt teknologisk utvikling eller krav fra økosystemdeltakere.

Dette er veldig bransje- og til og med organisasjonsspesifikt, så det er vanskelig å gi generelle råd.

To generelle prinsipper bør gjelde:

1. Komponenter skal stort sett være i samme oppløsningsnivå

2. Begrens antall komponenter

Vi ønsker ikke at komponenter skal være vesentlig forskjellige fra andre når det gjelder størrelse. Dette er ofte tydelig når en komponent kalles noe som "kjerne", noe som innebærer at den kan ha et høyere oppløsningsnivå enn andre komponenter, og kan trenge å bli dekomponert til logiske deler.

Det er nyttig å bruke en tommelfingerregel om antall komponenter som vises i arkitekturen. For en stor, kompleks flernasjonal organisasjon kan dette potensielt være vanskelig ettersom det kan være hundrevis av separate applikasjoner involvert. Disse kan imidlertid fortsatt logisk grupperes i applikasjonskategorier. En vanlig tilnærming er å bruke syv pluss eller minus to komponenter per lag, og å ikke ha mer enn tjue komponenter i hele arkitekturen.

Kryssreferanse den endelige arkitekturen med bransjeeksempler

Til slutt kan du gå gjennom arkitekturen mot referansemodellene du opprinnelig identifiserte, ved å bruke disse til å krysse av arkitekturen for fullstendighet og konsistens.

Gå gjennom hver av referansemodellene mot din arkitektur og se om referansemodellkomponentene er til stede i din egen. Hvis de ikke er det, spør hvorfor det er og om de trenger å bli inkludert. Hvis arkitekturen din har flere komponenter, kan du spørre om disse er nødvendige og prøve å forstå hvorfor de ikke er til stede i referansemodellen. De er kanskje ikke relevante for den modellens kontekst.

Dette er en god fornuftskontroll om at arkitekturen din har et forhold til andre modeller som du kan se å bli brukt i praksis.

Gjennomgå og baseline arkitekturen

På dette tidspunktet har du en fungerende modell av arkitekturen din. Du kan nå sirkulere den til vurdering av kolleger og andre interessenter, og prøve å bruke den i praksis. Du vil sannsynligvis finne at noen endringer er nødvendige, noe som er normalt. Ikke vær redd for å flytte komponenter rundt hvis du tror at de ikke er på rett sted, eller for å fjerne eller sette inn nye komponenter.

Ikke glem at Enterprise-arkitektur er en levende ting som vil endres over tid og gjenspeiler organisasjonens endrede behov eller eksterne endringer i industrien eller teknologien.

Foretaksarkitekturmodellen kan nå plasseres under versjonskontroll og ansvar for det pågående vedlikeholdet som er tildelt en relevant funksjon eller parti. I en stor organisasjon kan dette være en formell arkitekturfunksjon eller en individuell arkitekt. I mindre organisasjoner kan funksjonen antas av en eller flere personer som vanligvis er forretningsanalytikere eller systemdesignere.

Vi håper at denne artikkelen er nyttig for å gi deg noen tips til hvordan du tilnærmer deg analyse- og designarbeid for din egen virksomhetsarkitektur, og ønsker deg lykke til med dette.

Mark Nelson er CTO for OEL Foundation. Hvis du vil lære mer om OEL Foundation, kan du gå til https://oel.foundation eller kontakte forfatteren direkte på mark.nelson@oel.foundation

Du kan også bli med på Foundation on Telegram.