Bedste fremgangsmåder i design af en blockchain-baseret virksomhedsarkitektur

I denne artikel gives retningslinjer for, hvordan man designer designarkitektur, i dette tilfælde involverer blockchain og andre teknologier.

Virksomhedsarkitektur er en ramme eller model, der beskriver en virksomheds struktur og funktion. Det hjælper os med at analysere, designe, planlægge, implementere og vedligeholde arkitekturkomponenter. Hvad vi definerer er en logisk arkitektur ikke en fysisk arkitektur. Det er arkitekturen, der beskriver, hvad komponenterne gør, ikke hvordan de implementeres i praksis.

Arkitekturer kan omfatte forskellige typer komponenter, såsom forretningsprocesser, organisationsenheder, mennesker, enheder, systemer og IT-infrastruktur. De fokuserer typisk på systemer og understøttende infrastruktur, der er kortlagt på en baggrund af det, der viser forretningsenheder eller logiske lag.

Som et eksempel nedenfor er OEL Foundation Enterprise Architecture. OEL Foundation er en non-profit organisation, der leverer styring og ressourcer til udvikling af Open Enterprise Logistics blockchain-økosystemet. Arkitekturen viser de komponenter, der bruges til levering af logistikprodukter og -tjenester til eller af økosystemdeltagere.

Hvordan kan vi arbejde med at designe en virksomhedsarkitektur, der inkluderer blockchain-teknologi?

Der er ingen grundlæggende forskel ved at designe nogen arkitektur - en blockchain er bare en anden teknisk komponent. Der er dog nogle aspekter af blockchain-teknologi, såsom smarte kontrakter, der skulle vises i arkitekturen som komponenter.

Så hvordan kan vi arbejde med at designe virksomhedsarkitektur generelt?

Der er ingen "rigtige" eller "forkerte" svar, selvom nogle tilgange er mere nyttige end andre. Husk, at virksomhedsarkitektur også er en levende ting, der vil ændre sig og udvikle sig over tid.

Der er et par generelle retningslinjer, der er nyttige i arkitekturdesign:

1. Hold det enkelt

2. Se brancheeksempler og bedste praksis

3. Forstå relevant industriudvikling

4. Definer en arkitekturgrænse

5. Beslut om et (n) organisatorisk princip (er), der skal bruges

6. Befolk arkitekturen med relevante komponenter

7. Krydshenvisning af din endelige arkitektur med brancheeksempler

8. Gennemgå og baseline arkitekturen

Hold det simpelt

Generelt, hvis noget ikke er enkelt, skyldes det normalt, at kompleksiteten afspejler en eller flere faktorer, såsom: ufuldstændig analyse og design, arbejde på et for lavt detaljeringsniveau eller forsøger at inkludere for mange ting i modellen.

At forsøge at bruge en omfattende arkitekturstandard som f.eks. Open Group Architecture Framework (TOGAF) kan også være upassende, bortset fra for meget store organisationer.

Enterprise arkitektur kan designes ved hjælp af forskellige grader af kompleksitet. Nogle virksomhedsarkitekturer er meget komplicerede og vanskelige at forstå, selv af de mennesker, der skal bruge dem. Det er bedre at holde arkitekturen så enkel som vi kan uden at miste nøgleinformation. Dette hjælper folk med at forstå og bruge arkitekturen og dens komponenter.

Et blokdiagram er et godt grundlag for en enkel arkitektur. Dette giver os mulighed for at se hovedkomponenterne og deres brede forhold til hinanden uden at beskrive deres funktion eller forbindelser i detaljer.

Se brancheeksempler og bedste praksis

Der er mange eksempler på arkitekturer med varierende kompleksitet, forskellige tilgange og organiseringsprincipper og med et stort antal forskellige typer komponenter.

Der er ofte ingen standardarkitekturrammer eller -modeller, der kan bruges som reference. I mangel af dette bør vi kigge efter arkitektureksempler fra førende industrideltagere eller fra akademikere. Disse kan vise os, hvordan andre har henvendt sig til arkitekturanalyse og design og kan tjene som grundlag for vores egen arkitektur.

Det er undertiden let at finde vidt forskellige måder, som kan være forvirrende.

En nyttig teknik er at søge efter billeder ved hjælp af passende søgeord og få en fornemmelse af, hvilke modeller der appellerer til dig visuelt. Gennemgå disse på et højt niveau uden at gå tabt i detaljer. Vælg fire til fem af dem, der synes særligt relevante for dig for yderligere gennemgang og reference.

Se hvad de har til fælles, og hvilke forskelle der er. Hvad er inkluderet i arkitekturen, og hvad er ikke? Prøv at tænke på det eller de organisatoriske principper, der bruges i deres konstruktion. Hvilke komponenter er angivet? Bare rolig, hvis du ikke fuldt ud forstår dem, eller hvis de indeholder elementer, der synes irrelevante for dig. Husk, at der ikke er noget "rigtigt" eller "forkert" svar.

Til OEL Foundation Enterprise Architecture brugte vi arkitekturmodeller fra Ethereum, Ontology, CSCC / IBM, Tibco og udvalgte branchedeltagere som referencer.

Forstå relevant industriudvikling

Vi arbejder til enhver tid inden for rammerne af en branche og et sæt teknologier, der alle ændrer sig kontinuerligt. Dette kan få fremgangsmåder, der blev brugt til og med relativt for nylig, til at virke irrelevante og forældede.

Vi er nødt til at prøve at forstå den aktuelle tilstand i denne sammenhæng og også prøve at se fremad og identificere sandsynlige fremtidige udviklinger i industrien, økonomien og teknologier. Dette er meget vanskeligt at gøre. Den bedste tilgang er at forsøge at identificere en bred udvikling, der vil være relevant.

For en blockchain-baseret arkitektur er vi her mere ulempe end sædvanligt i betragtning af teknologiens relative umodenhed og det hurtige forandringshastighed.

For OEL Foundation Enterprise Architecture identificerede vi fire kategorier af udvikling på markedet og teknologi, som vi mener er særligt relevante for OEL Foundation økosystem:

1. Digitale forretningsmodeller

2. Blockchain-teknologiudvikling (især den voksende økosystemstøtte)

3. Konvergens af blockchain- og messaging-teknologier

4. Den stigende brug og betydning af skybaserede tjenester, såsom Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) og Infrastructure-as-a-Service (IaaS).

Definer en arkitekturgrænse

Som ethvert system er vi nødt til at definere systemgrænsen for vores arkitektur ved at adskille hvad der er inde i systemet og hvad der er uden for systemet.

Undertiden er grænsen ikke trukket på det rigtige sted. Vi kan måske se en masse eksterne skuespillere og tredjepartskomponenter (som ikke bruges til at implementere arkitekturen direkte) i en arkitektur. Dette hjælper os ikke med at identificere de væsentlige interne komponenter, der vil blive brugt til arkitekturen.

Hvis det er nyttigt at se på arkitekturens forhold til dets miljø, skal dette gøres ved hjælp af en grafisk leverbar, f.eks. Et kontekstdiagram. Dette er på et højere abstraktionsniveau end selve arkitekturen.

Til OEL Foundation Enterprise Architecture bruger vi tredjeparts teknologi og standarder i arkitekturen og forbinder også til eksterne parter og systemer ved hjælp af arkitekturkomponenter som API'er, messaging middleware og inter-chain integrationskomponenter. Vi kan betragte alle disse ting som at være inden for arkitekturgrænsen.

Økosystemdeltagere, eksterne systemer eller enheder eller de midler, der bruges til at integrere disse med arkitekturen, ligger uden for arkitekturgrænsen.

Beslut om et (n) organisatorisk princip (er), der skal bruges

Organiseringsprincippet hjælper os med at strukturere arkitekturen og danner et grundlag for tildelingen af ​​arkitekturkomponenter til forskellige dele af arkitekturen.

Der er en række tilgange, som vi kan tage her, herunder en eller flere af følgende:

1. Ende-til-ende forretningsforløb

2. Virksomhedens interne organisationsstruktur (med eller uden eksterne relationer)

3. En standardreferencemodel

Vi kan prøve at bruge en ende-til-ende forretningsprocesstrøm til at organisere komponenter, såsom at gå fra en leverandør til en kunde. Arkitekturkomponenter organiseres derefter langs den underforståede processtrømning mellem disse parter.

Ofte afspejler arkitekturen den interne organisationsstruktur, der er sammensat af organisationsfunktioner (eller organisationsenheder), såsom marketing, salg, drift, økonomi osv. Dette kan muligvis også omfatte forbindelser til eksterne systemer eller parter.

Til OEL Foundation Enterprise Architecture bruger vi en variation af ISO Open Systems Interconnection-modellen (OSI-modellen) som organisationsprincippet. OSI-modellen er en konceptuel model, der beskriver kommunikationsfunktionerne i et telekommunikations- eller computersystem.

OSI-modellen bruger syv lag, men et antal blockchain-baserede arkitekturer bruger en trelags model. Disse benævnes undertiden forskellige, men omfatter normalt et platform (eller applikations) lag, et protokollag og et netværkslag. Udtrykket "protokol" kan i sig selv være forvirrende, tvetydigt og åbent for fortolkning. Det kan være nyttigt at blive enige om, hvad sådanne udtryk betyder, hvilket hjælper med at identificere komponenter, der er relevante i den sammenhæng.

Befolk arkitekturen med relevante komponenter

Når vi har den overordnede arkitekturstruktur, kan vi derefter beslutte, hvilke komponenter arkitekturen skal indeholde og tildele disse til den relevante del af arkitekturen.

Vi kan bruge komponenter, som vi har identificeret i referencearkitekturer såvel som komponenter, som vi har til hensigt at inkorporere, der afspejler kendte eller antagede teknologiske udviklinger eller krav fra økosystemdeltagere.

Dette er meget industrielt og endda organisationsspecifikt, så det er svært at give generelle råd.

To generelle principper bør dog finde anvendelse:

1. Komponenter skal stort set være på samme opløsningsniveau

2. Begræns antallet af komponenter

Vi ønsker ikke, at komponenter skal være væsentligt forskellige fra andre med hensyn til størrelse. Dette fremgår ofte, hvor en komponent kaldes noget i retning af "kerne", hvilket indebærer, at det kan være på et højere opløsningsniveau end andre komponenter, og det kan være nødvendigt at nedbrydes til logiske dele.

Det er nyttigt at bruge en tommelfingerregel om antallet af komponenter, der vises i arkitekturen. For en stor, kompleks multinational organisation kan dette potentielt være vanskeligt, da der kan være hundredvis af separate applikationer involveret. Disse kan dog stadig logisk grupperes i applikationskategorier. En almindelig fremgangsmåde er at bruge syv plus eller minus to komponenter pr. Lag og ikke have mere end tyve komponenter i hele arkitekturen.

Krydshenvisning af din endelige arkitektur med brancheeksempler

Endelig kan du gennemgå arkitekturen mod de referencemodeller, du oprindeligt identificerede, ved hjælp af disse til at krydskontrol af din arkitektur for fuldstændighed og konsistens.

Gennemgå hver af referencemodellerne mod din arkitektur, og se, om referencemodelkomponenterne findes i din egen. Hvis de ikke er det, så spørg, hvorfor det er det, og hvis de skal inkluderes. Hvis din arkitektur har yderligere komponenter, skal du spørge, om disse er nødvendige, og prøv at forstå, hvorfor de ikke er til stede i referencemodellen. De er muligvis ikke relevante for den models kontekst.

Dette er en god sundhedstjek, at din arkitektur har et forhold til andre modeller, som du kan se, at de bliver brugt i praksis.

Gennemgå og baseline arkitekturen

På dette tidspunkt har du en arbejdsmodel for din arkitektur. Du kan nu cirkulere det til gennemgang af kolleger og andre interessenter og prøve at bruge det i praksis. Du vil sandsynligvis opdage, at nogle ændringer er nødvendige, hvilket er normalt. Vær ikke bange for at flytte komponenter rundt, hvis du tror, ​​at de ikke er på det rigtige sted, eller for at fjerne eller indsætte nye komponenter.

Glem ikke, at Enterprise-arkitektur er en levende ting, der vil ændre sig over tid og afspejler ændrede behov i organisationen eller eksterne ændringer i industrien eller teknologien.

Virksomhedsarkitekturmodellen kan nu placeres under versionskontrol og ansvar for dens løbende vedligeholdelse tildelt en relevant funktion eller part. I en stor organisation kan dette være en formel arkitekturfunktion eller en individuel arkitekt. I mindre organisationer kan funktionen antages af en eller flere personer, der typisk er forretningsanalytikere eller systemdesignere.

Vi håber, at denne artikel er nyttig til at give dig nogle tip til, hvordan du nærmer dig analyse- og designarbejde til din egen virksomhedsarkitektur, og ønsker dig held og lykke med det.

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

Du kan også deltage i Foundation on Telegram.