Tien jaar geleden maakten we met service oriented architecture (soa) voortvarend een einde aan de spaghetti van systemen. Wist men vóór het soa-denken nauwelijks welke applicaties waar draaiden en hoe die onderling gekoppeld waren; in het cloud-tijdperk dreigt nu een vergelijkbare situatie.
Misschien nog wel erger, omdat door de laagdrempelige aanschaf en uitrol alles mogelijk is – met name voor businessgebruikers. De architect en architectuurdenken zijn hard nodig om een nieuwe systeemchaos te voorkomen. Daarbij zijn vier verschillende elementen essentieel: integratie, service management, in-control blijven en het stimuleren van businessgedreven it-ontwikkeling.
1 – Werk maken van integratie
Denk na over hoe de diverse diensten met elkaar worden gekoppeld en waar de data staat. Tevens dienen de processen rondom de it te worden aangepast, opdat een nieuwe dienst snel kan worden opgenomen binnen het grotere geheel. Tevens moet het duidelijk zijn hoe en in welke vorm je als klant de data weer in bezit krijgt bij een eventuele exit.
2 – Zo veel mogelijk automatiseren van service management
Omdat in een cloudsituatie veelal sprake zal zijn van een groeiend aantal cloud-leveranciers, ieder met een eigen dienstverlening en contractvorm, moet de monitoring van services en sla’s zoveel mogelijk worden geautomatiseerd. Het handmatig managen van een uitgebreid landschap van cloud-diensten zal namelijk contraproductief werken; handmatige processen zullen de bottleneck zijn bij gebruik van cloud-diensten.
3 – In controle blijven
Binnen veel sectoren is sprake van zware eisen ten aanzien van data-beveiliging en privacy, vaak opgelegd door toezichthouders. Het is belangrijk om ook bij een dynamisch, snel veranderend landschap van cloud-diensten geheel in controle te blijven. Een schijnbare tegenstelling waarmee de architect als geen ander raad weet.
4 – Businessgedreven it-ontwikkeling aanjagen
Een groot voordeel ten opzichte van standaard pakketsoftware is dat het combineren van cloud-diensten businessgerichte innovatie mogelijk maakt. Developers moeten in staat gesteld worden om services uit de cloud ‘aan elkaar te plakken’ om zo onderscheidende producten, diensten en zelfs businessmodellen te ontwikkelen.
Al deze vier elementen spelen een rol bij het managen van de ‘nieuwe chaos’: de waarschijnlijk continue verandering van het it-landschap op basis van cloud-diensten. Een chaos van waaruit zogezegd geweldige nieuwe dingen met een hoge businessrelevantie kunnen ontstaan. Want dat is misschien wel het belangrijkste: het nieuwe cloud-gebaseerde it-landschap is niet langer een doel op zichzelf, maar cruciaal voor de verdere ontwikkeling van de organisatie. Nog nooit eerder was de architect zo relevant voor de business.
Genesis. In den beginne was er chaos.
Later zou het goed komen door SOA denken, lezen we.
Door die architectuur, kun je weer eenvoudig die Services in de Cloud afnemen, maareeee dan dus weer chaos..
Business moet nu ineens heterogene dienstverlening en contractvormen managen. Service en SLA monitoring ipv ff de ICT afdeling raadplegen.
Artikel eindigt ermee dat de architect nog nooit zo belangrijk zou zijn voor de business.
Dus als ik het goed begrijp komt het erop neer dat er met Business altijd chaos zal zijn en WC eenden die zichzelf als oplossing verkopen En dan natuurlijk de IT afdeling die aangejaagd moet worden, anders gaan ze natuurlijk die chaos proberen te voorkomen 😉
Architecten zijn belangrijk, maar goede principes zijn belangrijker in een SOA wereld + regie + goede tools.
Breng de gebruikte services in kaart en gebruik tools die de services in de gaten houden (bereikbaar / werkend / performance) zorg voor een goed begrip over wat er gebruikt wordt en zorg voor een goede “discovery” service.
SOA als term is onhandig, als principe is het cruciaal en een volstrekt dominant model. Al (het goede) draait om services (en scripting), ofwel interoperabiliteit.
Architecten zijn erg belangrijk uiteraard, maar in die vermaledijde praktijk kom je toch meestal weer uit bij een techneut met een spreadsheet.
Ik kan me wel iets voorstellen bij dit artikel maar meer nog bij de respondenten. Vanuit de basis IT keten is er geen chaos wanneer mensen de lijnen van die keten bewaken. Dat is overigens niets nieuws maar blijkt wat makkelijk vergeten door de hausse aan allerlei ‘ vernieuwingen.
Wat mij betreft is die keten nog steesd onverabnderd. Groot problem, ik ervaar dat verbazend genoeg nog dagelijks, dan men klaarblijkelijk het maar steed niet voor elkaar krijgt twee verschillende werelden te ‘ overbruggen’ waaroor chaos ontstaat en in stand word gehouden.
Misschien ook wel het overdenken waard?
In de ene wereld is men druk met het volgen van processen, waarbij er ruimte is voor creativiteit, in de andere wereld is men bezig met het automatiseren van diezelfde processen, waarbij de creatieve ruimte steeds verder wordt beperkt.
Creativiteit kun je namelijk niet automatiseren.
Hier zal altijd een discrepantie zijn tussen business en ICT, in elk geval waar het processen betreft die enige creatieve ruimte nodig hebben om een optimaal resultaat te halen.
Hoe lossen we dat dan op?
Misschien moeten we eerst die stap terug maar eens maken en de vraag stellen: waar ging het ook al weer om? Wat is het doel van dit bedrijf? Hoe gaan we dat doel bereiken? Welke delen van het werk zijn herhaalbaar en welke delen vragen om creatieve ruimte?
Laat daar eens een architect op los. Eentje die eerst naar de business kijkt. Want architecten die afdelingen met overlappende werkzaamheden en (de vaak daar uit voortkomende) botsende belangen naast elkaar laten bestaan en dit trachten op te lossen door alleen de automatisering (her) in te richten, gaan niet in hun opzet slagen.
Misschien moeten we voor die S in SOA de service of dienst die de business levert eens als uitgangspunt nemen. Komen we denk ik een stuk verder mee.
Edwin,
Een tijd geleden heb ik in een artikel verwezen naar de chaos in de cloud:
SaaS: Het oerwoud van de toekomst
https://www.computable.nl/artikel/opinie/infrastructuur/4923342/2379248/saas-het-oerwoud-van-de-toekomst.html
In een ander artikel heb ik een nieuw term 🙂 bedacht:
Wegwerp Architectuur!
https://www.computable.nl/artikel/opinie/management/5209658/2379250/koerst-je-onderneming-af-op-een-ramp.html
Ik zie wat overeenkomsten tussen het idee “Wegwerparchitectuur” en je punt 1,2 en 4.
Moeten we niet (traditionele)SOA verder aanpassen aan de nieuwe mogelijkheden en technologieën?
In dat laatste artikel staat een leuke discussie tussen Ewout en Jack, omtrent EA (Enterprise Architecture)
@Reza
Ik heb – ondanks dat ik een officieel gecertificeerde EA-architect ben – mijn twijfels over de discipline door abstracties die gehanteerd worden. Tussen de SOLL van Jack en de IST waar ik mee te maken heb zit nog een schaduw waar moeilijk over heen te springen is. Mogelijk komt dat ook doordat de Enterprise als een organisatie entiteit eigenlijk niet bestaat, tot op heden ben ik alleen maar multi-nationals tegen gekomen met grotere ambities dan dat organisatorisch haalbaar was.
Betreffende idee van een wegwerp-architectuur heb ik je al voor gek verklaard omdat inwisselbare principes net zo opportunistisch zijn als Fred Teeven, tussen zeggen wat je doet en doen wat je zegt zit verwachting van vertrouwen. Fantastisch dat een master IT architect ongeveer een jaar of 3 na mij met dus de dezelfde conclusie komt die ik al riep in round-table sessie van Computable, de cloud biedt mogelijkheden maar geen wonderen.
Let wel dat dit alleen de infrastructuur betreft en nog niets zegt over de regie in de vorm van GQM-loop, de chaos met een proces beheersen geloof ik ook niet in. Want alleen het genie beheerst de choas en tot op heden ben ik hier dus nog niemand tegen gekomen die genialer is dan mij;-)
@Ewout: zolang je “genialer is dan mij” blijft schrijven, in plaats van “genialer is dan ik” hoef je daar niet heel erg lang naar te zoeken, lijkt mij 😉
Wat blijft IT toch een mooi vak; door de enorme diversiteit zal er nooit één waarheid zijn, maar altijd vakgenoten met verschillende meningen. Daarbij komt nog eens dat het IT landschap continue in beweging is, en zal blijven. Niet makkelijk voor de afnemers van IT, maar zo blijkt helaas onvermijdelijk. We zitten in de transitie van “build to last” naar “build to change” (Edward E. Lawler, III).
@Henri; Helemaal eens, architectuur is belangrijk maar niet het enige dat telt. Duidelijke afspraken, enige mate van standaardisatie, regievoering, maar wel met behoud van flexibiliteit zijn zeker niet minder belangrijk. Het is het totaal dat telt.
@Kj; Tja, dat herken ik soms ook. Echter, we schaffen stoplichten ook niet al omdat er soms toch nog iemand door rood rijd.
@NumoQuest; Like your thinking. We hebben in realiteit ook niet één IT wereld, maar een landschap IT oplossingen die verschillend op de schaal statisch (system of record) en dynamisch (system of engagement/innovation) liggen. Deze werelden complementair maken en houden is wat mij betreft DE uitdaging.
@HK; Creativiteit is juist een belangrijk aspect van de system of engagement/innovation werelden.
@Reza/@Ewout; Ben ook geen fan van wegwerp architectuur. Denk dat we dit juist te vaak doen in IT, niet leren van onze fouten. Ben wel fan van dynamische architectuur, die het toestaat om lessen uit het verleden mee te nemen, uitzonderingen op de architectuur standaard (tijdelijk) toe te staan en continue aan verbetering onderhevig is.
Architectuur is wat mij betreft om het IT-landschap in kaart te blijven houden, waarom hebben we bepaalde besluiten genomen en welke principes liggen ten grondslag aan het ontwerp, om op basis daarvan snel en gefundeerd veranderingen door te kunnen voeren.
Dank voor jullie reacties!
@Edwin
Idee van een dynamische architectuur zul je specifieker moet definieren in tijd, dat je schoenen makkelijker wisselt dan de infrastructuur van wandelpaden zal hopelijk niemand verbazen. Architectuur is naar mijn opinie namelijk meer dan het IT-landschap, meer dus het geheel van samenwerkende en -hangende componenten.
Sommige filosoferen aangaande architectuur misschien wel 3-dimensionaal maar zolang we de paarden nog steeds achter de wagen blijven spannen is dat dromen over Pegasus, meer een religie dan een realiteit dus.