Terugkijkend op de jarenlange evolutie van it-systemen, van de ponskaart tot internet of things (IoT) blijf ik mij verbazen over één ding: Elke cio en it-manager weet dat de aanschafprijs van software of cloud diensten maar een klein gedeelte van de totale kosten is. Het in de lucht houden kost vele malen meer. Waarom kan dit niet beter en dus goedkoper?
Omdat it-oplossingen ook steeds complexer worden, wordt het in de lucht houden van deze oplossingen ook steeds complexer. De introductie van service oriëntatie, cloud computing, apps, micro services en IoT maakt het allemaal niet makkelijker. Waar je voorheen nog gewoon een erp- systeem implementeerde, wat alle functionaliteiten in één mooie monolitische applicatie biedt, bestaat ‘de applicatie’ (is dat nog een valide concept?) tegenwoordig uit vele bewegende onderdelen en aan elkaar ‘geknoopte’ componenten. Sommige delen draaien in je eigen datacentrum, sommige in de cloud en sommige op je mobiele device. Hoe houdt je zulke complexe omgevingen beheerbaar, veilig en voorspelbaar?
Tijdens een traject bij een groot Nederlands oliebedrijf leerde ik voor het eerst de term ‘supportability’ kennen. Later kwam die term zelfs terug in de tijdelijke functie die ik daar vervulde: sr. supportability consultant. Wow, mooie titel! Weliswaar vervulde ik die rol alleen in de wereldwijde ‘integration services’-afdeling, maar dat maakte het juist ook cruciaal. Want, hoe worden alle bewegende onderdelen in een complexe ‘applicatie’ aan elkaar geknoopt? Juist, door middel van integratietechnologie. En wat gebeurt er als dat niet feilloos werkt? Juist, dan dondert alles om.
Hybride
Die integratietechnologie is tegenwoordig ook niet meer één product dat je even installeert (of aanzet, in het geval van PaaS of SaaS integratie). De integratietechnologie is ook hybride geworden, en bestaat uit zaken als api-management tot en met een service bus met eventueel bijbehorende master data services, enzovoort.
Het valt mij op dat alle grote leveranciers van software en clouddiensten nog veel te weinig aandacht besteden aan de end-to-end governance en application lifecycle management van dit soort complexe, hybride ‘applicaties’. Elk onderdeel op zich kan (meestal) prima gemonitord en beheerd worden, maar helemaal end-to-end? Nee, niet echt.
Supportability is een term die gebruikt wordt om aan te geven welke aspecten rond het ontwikkelen van oplossingen te maken hebben met het supportable maken van deze oplossingen. Dat wil zeggen, bij het bedenken van de architectuur moet direct al aandacht zijn voor supportability. Bij het maken van een functioneel ontwerp moet daar ook gelijk al aandacht voor zijn. Dat betekent dat er direct vanaf het begin mensen van beheer en support betrokken moeten worden bij het traject. Los daarvan zou het fijn zijn als de leveranciers van software en clouddiensten verder kijken dan hun eigen ‘containers’. Een end-to-end visie op governance en application lifecycle management is zeer gewenst. Open standaarden op dit gebied zouden erg welkom zijn!
Oproep
Mijn oproep aan de leveranciers is: in plaats van de zoveelste nieuwe functionaliteit toe te voegen aan de software of clouddienst (ook cool hoor, daar niet van) wordt het tijd om met oplossingen te komen voor het creëren van supportable hybride ‘applicaties’, liefst op basis van een mooie open standaard. Een oplossing die aansluit op bestaande standaarden en beheerprocessen als ITIL, maar die ook mooi ingeplugd kan worden in zowel Eclipse, Visual Studio, VMware, Hyper-V, Docker als Xamarin (om maar een paar kandidaten te noemen). Pas als we op deze manier complexe, hybride ‘applicaties’ kunnen gaan ontwikkelen met een uitvoerbare supportability strategie én de daarbij behorende bruikbare tools, bereiken we een volgende niveau van volwassenheid in de it. En dat is hard nodig.
@Ewout – totdat de kosten van downtime of torenhoge supportkosten echt inzichtelijk worden gemaakt.
@Ewout,
Dan kan ik Gijs alleen maar aanraden om bij het, http://www.sienainitiative.eu/
te rade te gaan en vooral mee te denken [programmeren?] aan de noodzakelijke API architectuur…ik denk dat men daar nog wel wat “onafhankelijke” meedenkers kan gebruiken! 😉
Grappig, ze kunnen bij Siena niet eens een responsive website ontwikkelen…
Wat is er toch gebeurd met de A in SOA; ook hier wordt weer gesproken van service oriëntatie in plaats van service gebaseerde architectuur of Service Oriented Architecture.
Ook de suggestie dat “Applicatie” tegenwoordig geen valide concept meer zou zijn past in de tendens om het aandeel van menselijke arbeid in de dienstverlening tot een absoluut minimum te beperken. De opmerking van Felix: “End-to-end as a Service? En wat doe je zelf dan nog? “
is dus zeer gevat en de kern van de zaak.
In mijn optiek is applicatie juist een zeer valide concept. Een applicatie is een toepassingsprogramma, geschikt voor menselijk gebruik. Dankzij SOA worden applicatie’s niet tussen aanhalingstekens gezet, maar juist mogelijk gemaakt: gebruikersapplicaties aan de voorkant (voor zowel bedrijfsmedewerkers als klanten), en functionele- en basisapplicaties aan de achterkant.
Het verbaast mij niet dat Ewout hier met een architectuurloze definitie van SO(A) op de proppen komt. Laat ik eens een poging wagen hier een definitie van SOA tegenover te zetten.
Als uitgangspunt neem ik een mijns inziens sterk verouderde definitie van SOA, die echter wel de nodige architectuur bevat; een definitie die ik aantrof in het (mi. nog altijd uitstekende):
http://www.bol.com/nl/p/service-oriented-architecture/1001004002626939/ (blz. 63):
“SOA is een applicatiearchitectuur waarin alle functionaliteit en gegevens ter beschikking worden gesteld via services met gestandaardiseerde interfaces die diverse bedrijfsprocessen kunnen ondersteunen en daarmee tevens de flexibiliteit van die bedrijfsprocessen kunnen vergroten. “
Als ik nu even aan deze definitie sleutel, dan wordt het:
SOA is een applicatiearchitectuur waarin afgebakende delen van bedrijfsfunctionaliteit en bedrijfsobjecten door middel van selfservice ter beschikking worden gesteld aan bedrijfsmedewerkers en klanten.
Als eerste opzetje. En daarmee zet ik de nodige vraagtekens bij het hele idee van “end-to-end”.
Ofwel: denk niet in ketens maar in applicaties/domeinen.
@Jack “A critical success factor to achieving the goals of an SOA adoption project is to ensure that a formal and well-defined system be in place to ensure the regulated evolution of the services, solutions, and other resources and assets that comprise the planned SOA ecosystem. Without such a system in place, there is constant and ever-increasing risk that the IT enterprise will lose its alignment with the business and therefore become progressively less effective and more burdensome.”
Uit “Next Generation SOA”.
Gijs, hierbij toch mijn twee centen. Allereerst vind ik dit wederom een goed en relevant artikel wat niet dwingend is en vooral een onderwerp in de groep gooit waar grote behoefte aan is. Dingen maken waarop je integrale ondersteuning op kunt leveren, een lastig concept omdat end-to-end door “cloud” vaak niet mogelijk is. Jouw startpunt -de plek waarop de service jouw bedrijf binnenkomt, ofwel endpoint- is niet het beginpunt waar de service zijn oorsprong vind. In feite is een service die je over de cloud afneemt het front-end van de service.
Het lijkt mij wel duidelijk dat er in praktisch alle gevallen van organisaties niet alle IT zaken meer vanuit de organisatie zelf komen, “cloud is here to stay” en dit zou een basis acceptatie moeten zijn: We kunnen niet meer volledig end-to-end een single point of support realiseren.
Dit is het slechte nieuws. Het goede nieuws is dat veel services in de vorm komen van webservices en dat hierin steeds meer gelijkenissen komen. We communiceren over HTTP(S), op basis van REST architectuur en het formaat van de berichten is in zeer groot deel van de gevallen XML of JSON. Nu zegt dit niets over de interne werking, maar ik merk in de praktijk dat het adopteren van weer een nieuwe webservice steeds makkelijker wordt.
Architectuur is niet een 1 dimensionaal iets en kent vele lagen en plekken. Zo is een belangrijk onderdeel in de service architectuur de IAM : Identity Access Management. Dit is de AORTA waarover alle integratie met services zou moeten plaatsvinden. Om een goede architectuur te bouwen en handhaven zou de scheidslijn tussen on-premises en cloud over 1 en hetzelfde kanaal moeten lopen. Ofwel: Hoe men vanaf buiten met data opslag (databases en files) om gaat zou gelijk moeten zijn over hoe er binnen met dataopslag wordt omgegaan. En hier wringt onder andere de schoen. De software en connecties van software naar de data (databases en bestanden) is vaak al jaren oud en zal niet zo snel een services architectuur omarmen. En laten we wel wezen: OAUTH 2.0 en schaalbare performante webservices beginnen nu pas realiteit te worden. OpenID wat jarenlang geneuzel was begint nu ineens eenvoudige te worden doordat hiervoor steeds meer “middleware” voor ontstaat.
Maar goed, om het niet te lang te maken, services komen niet meer van 1 plek vandaan. IAM lijkt mij een onvermijdelijkheid om enigzins controle te verkrijgen over je architectuur. Legacy en uitzonderingen zullen nog jarenlang de realiteit blijven en end-to-end supportability zal per definitie niet echt meer mogelijk zijn.
Er is dus geen eenduidige oplossing, er zijn hooguit een paar goede gewoontes die kunnen helpen, of rigide beslissingen zoals voor een monolitische keten te kiezen al zul je hiermee veel “cloud” ontwikkelingen uitsluiten of als geaccepteerde afwijkingen toelaten.
Ik denk dat SOA een onvermijdelijk is, en het zou mijn route zijn als ik mag kiezen. Door het hanteren van goede principes, architectuur, vasthouden aan IAM als Aorta, kun je in ieder geval tactische beslissingen maken om het zo supportable als mogelijk te houden. Door voorwaarden te stellen aan alle bestaande en toekomstige services kun je al een hoop ellende mitigeren. Daarnaast denk ik dat dit ook een mindshift is bij je medewerkers en dat je als onderdeel van strategie mensen continu moet blijven trainen op het begrijpen, adopteren en beheren van services. Als je dit goed doet bouw je in mijn ogen een bedrijf van de toekomst. Want als je architectuur up-to-date is (ook een nieuw soort CMDB) en blijft, dan kun je uiteindelijk je processen beter ondersteunen door switchen mogelijk te maken. In deze tijd is het kunnen aanpassen aan veranderingen nog belangrijker geworden. Juist omdat internet veel transparant maakt.
Het mooie van de discussie is dat er geen echt goed of fout is.
@Henri dank voor deze uitgebreide bijdrage. I&AM is inderdaad een zeer belangrijk onderdeel. Bestond er maar iets vergelijkbaars als OAuth voor runtime SOA governance en ALM.
@Jack
SOA is grotendeels theorie, zolang services afhankelijk zijn van technische componenten heb je te maken met ‘fact-of-life’ van veroudering. De platform agnostic applicatiearchitectuur is dan ook meer een filosofische benadering dan een pragmatische. SOA architecten bouwen dus voornamelijk luchtkastelen, als eerdere principes niet werken passen ze deze even opportuun als een politicus aan waarbij focus vooral ligt op de gebruiker en dus niet op de klant. Met de roep om een participatiemaatschappij wordt het dus tijd voor POA, een Privacy Oriented Architecture want ook de data heeft een lifecycle, tenminste in onze recht om vergeten te worden zou dat wel het geval moeten zijn.
Henri haalt hier puntje authenticatie aan maar als deze niet onlosmakkelijk aan de data is gebonden hebben we hier te maken met een informatielek omdat implementaties van SOA zijn verworden tot een architectuur van ‘disconnected silos’ waarmee hype als Big data gevoed wordt. Het is tenslotte vrij simpel om een van de applicatie losgekoppelde dataset te gebruiken om zodoende de nimmer te bevredigende behoefte van gebruiker te bevredigen, idee van SOA heeft veel weg van een oncontroleerbare kettingreactie die nu in rap tempo voor een ‘meltdown’ aan vertrouwen zorgt. De uitwisseling van data is met ontwikkelingen zoals IoT namelijk niet het probleem maar de governance dus wel.
Helaas houden maar weinig SOA architecten zich aan het CIA principe dat voor data geldt: Confidentiality, Integrity and Availability laten ze telkens weer over aan het implementatieniveau. Let met name dan ook even op de non-functional requirements in blokje Service Contract Template in prachtige grafische weergave van Zapthink aangaande de SOA roadmap:
http://www.zapthink.com/2008/09/15/zapthink-soa-implementation-roadmap-30/?file_id=ZapthinkSOARoadMap-2008-reduced-ZTS-GI104-1.pdf
Scrol vanaf daar naar beneden om te kijken wat er nog meer aan misleiding in SOA denken zit, met name dat stukje ‘event-driven’ is een hele aardige als we overwegen dat Visibility & Control toch vooral verkregen wordt vanuit de capaciteiten van de infrastructuur. SOA is tot op heden nog sterk ‘incident-driven’ door dus met name de sterke focus op gebruikers wat zich laat vertalen in een behoefte aan agility doordat er vooral reactief gestuurd wordt als gevolg van de vele ‘disconnected processen’ binnen een organisatie. Meer dan 20 jaar wordt met idee van ERP (lees ESB) geprobeerd dit euvel op te lossen met teleurstellende resultaten als ik overweeg dat nu kanon van Big Data ingezet moet worden, de rapportgenerator on steroïds zullen we maar zeggen.
Kortom Jack, net als in eerdere discussie ligt er nog een verschil tussen denken en een lege maag. Want hoewel ik veel SOA aan de bovenkant van de keten zie blijkt het aan de onderkant allemaal dus nog niet zo mooi te zijn als sommigen ons willen doen laten geloven. Het modelgedreven business process-platform Be Informed was een regelrechte mislukking als ik de verhalen mag geloven die in de krant staan. En dit is niet de enige architectuur die met ‘magic strings’ aan elkaar geknoopt was omdat er inderdaad geen sprake is van ketens maar matrixen, uiterst complex doordat er wat dingen achterwege zijn gelaten:
“This is your last chance. After this, there is no turning back. You take the blue pill—the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in SOA Wonderland, and I show you how deep the rabbit hole goes. Remember: all I’m offering is the truth. Nothing more.” – Morpheus to Neo in the Matrix.
Goed verhaal Ewout en de laatste quote is een echte klassieker met een twist 🙂
Er is genoeg werk aan de winkel en erken ik de punten die je aanhaalt. Zelf zie ik SOA als een onvermijdelijkheid, dus dan is mijn vraag: Welke vaardigheden, competenties, technologie en diensten hebben we nodig om de bezwaren het hoofd te bieden en wat zijn de alternatieven?
Goed betoog Ewout.
Natuurlijk is SOA nog niet volwassen en klopt het dat service contracts nog wat zaken rond non-functionals missen zoals correct weergegeven in de ZapThink poster.
Maar het is denk ik beter om verder te bouwen op deze juiste uitgangspunten en de 8 principes van service ontwerp, dan om alles in de vuilnisbak te gooien en opnieuw te beginnen.
Microservices gaat ons probleem in ieder geval niet oplossen als het ontwerp van services (en de draak van een legacy applicatie die daar vaak onder hangt) niet de juiste aandacht gaat krijgen.
En verder is Master Data Management en SOA een mooi onderwerp op zich!