Bij Vault Health begint CTO Steve Shi met enterprise-architectuur (EA) met een site-enquête van de volledige IT-, applicatie-, systeem- en data-infrastructuur, maar beperkt dit tot twee weken met interviews van een uur over elke functie.
Klanten, of het nu werknemers zijn of degenen die voor een product of dienst betalen, moeten het resultaat van deze minimaal haalbare benadering van EA ‘liefhebben’, zegt Shi. “Als je de klant niet koopt, verlies je momentum, en als je het momentum verliest, is het moeilijker om door te gaan met herhalen na de minimaal haalbare lancering”, zegt hij.
Net als veel IT-leiders probeert Shi een evenwicht te vinden tussen complexe architectuurstudies die ongebruikt blijven en kale EA-rapporten die onvoldoende reikwijdte en diepgang hebben om blijvende waarde te bieden. Om die balans te vinden, moet je dicht bij de zakelijke behoeften blijven, het drukke werk verminderen, het project goed afbakenen en de juiste architecturale normen en principes vaststellen en handhaven. Hier zijn vijf stappen die CIO’s die ervaren zijn in het proces aanbevelen.
Blijf dicht bij het bedrijf
Het onderhouden van nauwe communicatie met zakelijke belanghebbenden is de enige manier om te weten waar een minimaal levensvatbare enterprise-architectuur het bedrijf het beste kan helpen en financiering kan genereren voor voortdurende EA-beoordelingen naarmate de bedrijfsbehoeften veranderen.
Bij Carrier Global Corp. meet CIO Joe Schulz EA-succes aan de hand van bedrijfsstatistieken, zoals hoe de productiviteit van werknemers wordt beïnvloed door de kwaliteit van applicaties of serviceonderbrekingen.
“We zien enterprise-architectuur niet als een enkele groep mensen die de poortwachters zijn, die meer theoretisch van aard zijn over hoe iets zou moeten werken”, zegt Schulz. Hij gebruikt rapporten en inzichten die zijn gegenereerd door EA-tool Lean IX om de interconnectiviteit van het ecosysteem en de systeemmogelijkheden in de hele portfolio te beschrijven om overtolligheden of hiaten te identificeren. Hierdoor kan de wereldwijde leverancier van intelligente bouw- en koelketenoplossingen “een groot deel van de besluitvorming democratiseren … (om) het beste denk- en investeringsvermogen in onze hele organisatie te benutten.”
George Tsounis, chief technology officer bij het faillissementstechnologie- en servicebedrijf Stretto, raadt aan EA te gebruiken om “vertrouwen en transparantie te vestigen” door bedrijfsleiders te informeren over huidige IT-uitgaven en gebieden waar platforms niet zijn afgestemd op de bedrijfsstrategie. Dat maakt toekomstige EA-gerelateerde gesprekken “veel gemakkelijker dan wanneer de enterprise architect in een silo werkt en die relatie niet heeft”, zegt hij.
Snijd de administratieve rompslomp af
Lange vragenlijsten en op sjablonen gebaseerde interviews zijn een bekend en vaak ongewenst onderdeel van de inspanningen van EA. Minimaal levensvatbare EA-beoefenaars stellen voor om alle vragen die geen essentiële informatie opleveren te elimineren en feedback van gebruikers mogelijk te maken.
Gregor Hohpe, directeur ondernemingsstrategie bij cloud hyperscaler Amazon Web Services, raadt aan om over te stappen van “zware, grotendeels eenrichtings” EA-processen naar eenvoudigere, snellere en iteratieve gesprekken met zakelijke gebruikers.
Bij financiële dienstverlener State Street probeert Global Chief Architect Aman Thind het EA-proces te stroomlijnen door alleen precieze en relevante vragen te stellen, in plaats van alles in een EA-sjabloon. Door zich te concentreren op de meest essentiële vragen, kan de tijd die nodig is voor het beoordelen en indienen van architectuur met ten minste de helft worden verkort en wordt het proces veel effectiever, zegt hij. Het raamwerk dat een SaaS-toepassing gebruikt om de gebruikersinterface te leveren, is bijvoorbeeld minder belangrijk dan de procedures voor identiteits- en toegangsbeheer die bepalen hoe gebruikers ermee omgaan.
Naast het gebruik van geautomatiseerde nalevingscontroles en zelfbedieningsplatforms, raadt Hohpe aan om “eindeloze lijsten met standaarden die grotendeels worden genegeerd” te elimineren, beoordelingsvergaderingen te houden waarbij alle documenten worden aangepast aan de gewenste uitkomst van het respectieve team, “afstemmings”-vergaderingen over niet- onderwerpen die waarde toevoegen en “gigantische wandtapijten genereren van zware EA-tools die nooit worden gebruikt voor besluitvorming.”
Steve Shi
Kluisgezondheid
Bij Vault, een bedrijf in de digitale gezondheidszorg, vindt Shi dat de applicatie-observatietool New Relic waardevol is bij het versnellen van het werk van EA door direct inzicht te bieden in de hele architectuur.
Hij gebruikt ook nieuwe termen en processen om veelvoorkomende vertragingen te voorkomen en bewustzijn te creëren voor zijn nieuwe aanpak. Een voorbeeld is een “siterapport” waarin gebruikers worden gevraagd zich het uiteindelijke EA-product voor te stellen. Dit helpt bij het definiëren van kritieke vereisten, zoals het aantal transacties en soorten processen die een applicatie moet ondersteunen, “van de kant van de klant en achteruit werkend”. In plaats van een “eenmalig” proces te gebruiken waarbij gebruikers worden gevraagd om vooraf overeenstemming te bereiken over een cruciale technologische beslissing, daagt Shi hen uit om “ontwikkelingshypothesen” te bevestigen of te herzien, zoals het aantal databaseoproepen dat een systeem elke dag moet ondersteunen. Deze aanpak versnelt overeenstemming over keuzes van componenten zoals databases, zegt hij.
Tijdens de uitrol van de applicatie vermijdt Shi een generiek projectplan ten gunste van wat hij noemt “een specifiek macro-sequencingplan” van stappen die zijn opgebouwd rond mijlpalen zoals alfa- en bètatests en de bijbehorende validatiemijlpalen. Dit definieert, voor elke fase van de implementatie, succes in zakelijke termen, zoals omzet of gebruikersacceptatie en lessen die zijn geleerd uit het ondersteuningsproces die de doorlopende ondersteuningskosten verlagen. Het herinnert iedereen er ook aan, zegt hij, dat “het project niet eindigt totdat we weten dat de architectuur meetbare klantwaarde heeft opgeleverd.”
Bereik het goed
Neem te veel op zich in een minimaal levensvatbaar EA-project en het zal achterhaald zijn voordat het klaar is, en levert te laat resultaten op om toekomstige financiering van bedrijfsleiders tevreden te stellen en te ontvangen. Beperk het te veel en het zal niet het alomvattende beeld van technologie en het bedrijf opleveren dat nodig is om het meeste uit IT-investeringen te halen. Om het juiste evenwicht te bereiken, moet u zich vaak concentreren op één toepassing of pijnpunt in het bedrijf of op een gebied waar vereisten snel veranderen als gevolg van nieuwe zakelijke of regelgevende behoeften.
Gartner Inc. Associate Principal Analyst Nolan Hart noemt de juiste EA-scope “het minste aantal deliverables, zoals gezichtspunten, referentiemodellen en ontwerppatronen, die helpen zorgen voor tijdige, conforme levering van producten en oplossingen.” In plaats van te veel tijd te besteden aan het begrijpen van de huidige architectuur, raadt hij aan om “eerst uw gewenste resultaten te begrijpen”. Het heeft volgens hem geen zin om “verdwaald te raken bij het documenteren van je huidige disfunctionele architectuur voor altijd en altijd.”
Shi beveelt aan dat een minimaal haalbare EA rekening houdt met “alles, van de gebruikersinterface tot de API’s die systemen koppelen aan de data-architectuur, in plaats van een enkele component of service in silo’s.” De voorgestelde architectuur moet ook testbaar zijn op productieschaal, zegt hij, en dezelfde piekvereisten aankunnen als het systeem dat het vervangt.
De juiste scope geldt ook voor de EA-organisatie. In plaats van een toegewijde EA-groep, creëerde Carrier expertisecentra voor belangrijke behoeften zoals CRM, buitendienst, ERP, analyse en digitale fabrieksmogelijkheden. Deze centra bieden een vereenvoudigde basis van kerncomponenten waarmee het snel kan innoveren zonder dat er een EA-oefening nodig is om afzonderlijke platforms voor elke bedrijfseenheid te evalueren, zegt Schulz.
Als een groep binnen een bedrijf niet geïnteresseerd is in een minimaal levensvatbaar EA-project, “zijn er genoeg andere mensen die je tijd zullen nemen”, zegt Hart. Koppel die vraag aan de vaardigheden van een EA-groep om te bepalen “drie tot vijf soorten services die u kunt aanbieden om die bedrijfsresultaten te leveren met een minimaal haalbare aanpak.”
Normen instellen en handhaven
Gregor Hohpe
Amazon-webservices
Het afdwingen van ontwerpprincipes, samen met een focus op zakelijke behoeften, kan helpen om “religieuze discussies over welke oplossing de beste is”, te verkorten, zegt Tsounis. De principes die hij aanmoedigt, zijn onder meer “probeer altijd de eenvoudigst mogelijke oplossing te creëren, niet te veel te ontwerpen, maximaal hergebruik in de hele organisatie mogelijk te maken, gebruik te maken van gevestigde architecturale ontwerppatronen en cloudgebaseerde services voordat u iets nieuws bouwt.”
Referentiearchitecturen en -standaarden op gebieden als cyberbeveiliging, gegevensbeheer, productiebeheer en best practices voor implementatie bieden een “kant-en-klaar draaiboek” om op efficiënte wijze composable applicaties te bouwen die robuust, compliant en veerkrachtig zijn door het ontwerp, zegt Thind. Dergelijke architecturen, gebouwd met microservices die “zeer goed gedefinieerd zijn … in termen van hun API’s, hun schaalbaarheid en hoe ze samenwerken”, stellen een bedrijf in staat elke microservice te vervangen zonder andere te beïnvloeden, waardoor een toekomstbestendig ontwerp ontstaat.
Hohpe zegt dat sommige normen innovatie verstikken, terwijl andere het juist stimuleren. Uniforme interfaces zijn bijvoorbeeld essentieel voor het creëren van eenvoudig aan te passen architecturen. Te strikte normen kunnen echter leiden tot slechte technologiekeuzes. Hij herinnert zich een applicatieteam dat XML verkoos als componentinterface boven snellere communicatieprotocollen. Op de vraag waarom, antwoordde het team dat het architectuurteam dit nodig had, blijkbaar zonder rekening te houden met het nadelige effect van XML-parsing op de applicatieprestaties.
Begin ergens
Als niets anders, zegt Thind, benoemt u een “… een hoofdarchitect, een leidinggevende die de algemene normen, het algemene bestuur, de algemene platforms en de algemene discipline van applicatieontwerp vanaf de top beoordeelt. Alleen al het hebben van die positie geeft het belang van architectuur aan voor het hele bedrijf en zorgt voor het juiste gedrag dat we nodig hebben om efficiënte en innovatieve IT-organisaties te creëren.”
Het starten van een minimaal levensvatbare enterprise-architectuur kan beginnen door simpelweg “de balans op te maken”, zegt Thind, waarbij hij overbestedingen identificeert, zoals “waarom hebben we zes verschillende applicaties voor hetzelfde proces, vijf verschillende contracten (voor) dezelfde BI-tool, meerdere marktgegevenscontracten met dezelfde scope, 24×7 Hadoop-clusters voor maandelijkse rapportage, enzovoort.” Maar zelfs zo’n minimale haalbare inspanning kan grote voordelen opleveren. “Gewoon ervoor zorgen dat de juiste tool voor de juiste taak wordt gebruikt en dat er standaardisatie en best practices zijn rond het gebruik ervan, kan een aanzienlijke impact hebben op het resultaat en leiden tot minder technische schulden, minder ondersteuningsvereisten en snellere innovatie mogelijk maken,” hij zegt.
