Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Supportability is broodnodig

 

Computable Expert

Gijs in ‘t Veld
CTO bij Motion10, Motion10. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5199438). © Jaarbeurs IT Media.

6,2


Lees meer over


 

Reacties

Helemaal juist Gijs, topartikel.

Waar ik me telkens weer over blijf verbazen is dat het maar door gaat met hijgerig hypen. Is het niet over een zg nieuwe werk of ziens wijze, dan wel de implementatie van een nieuwe tool of manier van implementeren.

Men blijkt maar niet te willen kijken naar de wetmatigheden die IT als vehikel met zich mee brengt waardoor 'een rode draad' van Gijs hier hoogst waarschijnlijk een wetmatigheid van IT zelf is.

Less is more
Sta je werkelijk eens een keer stil bij het feit dat je IT ook kunt downsizen, goedkoper maken, sterker maken door en met minder, dan doe je die wetmatigheden voor jezelf eer aan en maak je ook supportability nog sterker en meer een standaard.

Neen, voor mij is IT niet verder door ontwikkelen 'cout ce cout'. IT voor mij blijft nog steeds 'Het Vehikel' besparingen en winst tegelijkertijd te kunnen bewerkstelligen en dat aspect sterker maken door verdere standaardisatie en versterken.

Het laatste te voorziene debacle, bij de gemeente Amsterdam deze keer, toont eens te meer maar weer eens aan. Als je een aantal Standaarden in je manier van werken en processen veronachtzaamd, doordat .... doordat ... doordat... dan krijg je dus dat. Met alle schadelijke gevolgen van dien.

Kan IT veel beter en goedkoper? Jazeker. Maar dan moet je twee hele grote vijanden van IT eens durven laten vallen. Commercie en Politiek.

I dare You!

Bij het lezen van de eerste zin kon ik geen grimlachje onderdrukken.

Maar is de auto-industrie geen goed voorbeeld? Daar werken ze allemaal samen en ondanks verschillen en vooral verschillende standaarden kunnen ze het wel opvallen vaak eens worden over gezamenlijke standaarden. Menig auto is een verzameling van onderdelen die niet van de eigen fabrikant hoeven te komen en soms zelfs van de concurrent.

De software industrie is wat dat betreft nog relatief jong en is eigenlijk verpest door de vendor lockin boys. En zien we nog steeds mankerende open standaarden zoals SOAP,HTML(5) en database exports.
Dwing de industrie tot het gebruik van goede open standaarden!

Gaat nogal in tegen lean en focus on core-business als je service providers in de hele keten betrekt. End-to-end as a Service ? En wat doe je zelf dan nog ?

Tot het zover is gewoon Henri en Ewout inhuren, dat ze een oplossing bedenken waar beide een handtekening op zetten. Ruud en Reza evt het Storage performance en IAM/IDM deel laten reviewen.

Beetje vreemd verhaal want supportability valt uiteen in een aantal aspecten waarvan operability er één is terwijl we daar met name aangaande de hardware kunnen constateren dat er al lang enige standaardisatie in management interfaces heeft plaats gevonden als we kijken naar het volgende diagram:

http://www.dmtf.org/componentsdiagram

Dat deze non-functionele aspecten vaak niet meegenomen worden door Enterprise Architectuur is niet zo zeer te wijten aan leveranciers, architecten vergeten nu eenmaal nog vaak dat er naast een businessarchitectuur (die inderdaad opmerkelijk eenzijdig ingevuld wordt met applicaties) ook nog zoiets is als een IT-architectuur waardoor architectuurplaten wel de functionaliteiten laten zien maar niet door welke technische componenten (met versie) deze nu precies geleverd worden.

Deze 'Governance-as-a-Service' is mede te wijten aan het feit dat de IT verantwoordelijk is gemaakt voor de levering van allerlei IT services want bij SERVICEABILITY gaat het dus niet alleen om de software upgrades - correctief of adaptief - maar ook alle gebruikelijk hardware vervangingen, monitoring van zowel de events als de belasting en het oplossen van alle incidenten tot aan de uiteindelijk uitfasering die niet zelden voorbij de contracten van allerlei leveranciers gaat.

End-to-end governance betekent namelijk dat je bij het begin al rekening houdt met het einde aangezien het niet echt nieuw is dat soft- en hardware een uiterste houdbaarheidsdatum krijgen. De wetmatigheid van NumoQuest is even sleets als idee dat markt stilstaat omdat je het als klant niet bij kan benen, stilstand is met name in de ICT sector nu eenmaal achteruitgang door niet de wet van Moore maar die van de remmende voorsprong die er nog in allerlei processen zit.

Lekker makkelijk dus om leveranciers de schuld te geven van het feit dat je zelf de processen niet op orde hebt, ITIL is net als Enterprise Architectuur namelijk geen product waar je met plugins even de problemen met governance of intergratie mee op kunt lossen.

Bedankt voor de feedback.

@Ewout: ik ben het niet met je eens. Het verhaal draait met name om hybride. Heb jij wel eens end-to-end ALM, monitoring en run-time governance geprobeerd in een omgeving met meerdere clouds of on-prem / cloud combinaties? Van verschillende leveranciers? Ik heb het niet over governance-as-a-service, maar over de juiste, gestandaardiseerde instrumentatie en APIs om ongeacht de tools (SCOM, Tivoli, HP OpenView, Visual Studio TFS, Eclipse, etc.) toch een end-to-end, cross platform view en management mogelijkheid te hebben.

"Ewout, dat is toch `Work in progress`
`The CMWG will develop a set of prescriptive specifications and sample implementations that deliver architectural semantics as well as implementation details to achieve interoperable management of clouds between service requestors/developers and providers.`

Gijs zal alleen even geduld moeten hebben, men is nog niet zover!
Je bent niet alleen hoor...
http://www.pipelinepub.com/cloud_technology/cloud_standards

En dan verwacht je dat de Directie van een organisatie na het lezen van dit stuk (en de commentaren) nu eindelijk door hebben wat er moet gebeuren?

Het probleem is (en dat geldt voor meerdere artikelen) dat ITers niet duidelijk kunnen maken wat het probleem is (tot en met CIO's). ITers duiken voor argumentatie te snel de inhoud in en dan is de Directie completely "lost".

@Gijs
De cloud is gebaseerd op het principe van 'loosely coupled storage, network and processing' wat inderdaad voor afstemmingsproblemen in de keten kan zorgen, heb hier meer dan 2 jaar geleden al wat over geschreven in opinie: 'De cloud beheersbaar maar niet beheerbaar' als geprobeerd wordt om twee onverenigbare wensen te combineren. Als je functionaliteit onlosmakkelijk koppelt aan bepaalde technische componenten dan ontstaat een directe afhankelijkheid en dit geldt meestal ook voor allerlei drivers, functionaliteit en prestatie is uiteindelijk de som der delen. Je constatering is trouwens niet nieuw als ik kijk naar de governance van SOA, Enterprise Architectuur heeft wat dat betreft nog een blinde vlek voor service support:

A service-oriented architecture can be defined as a way of designing and implementing enterprise applications that deals with the intercommunication of loosely coupled, coarse grained (business level), reusable artifacts (services).”

Vraag is of we stap op de plaats moeten maken in afwachting van leveranciers om probleem op te lossen of juist harder moeten gaan lopen om de 'Legacy-to-SOA' uitdagingen in processen op te lossen, betreffende je opmerking hybride stel ik dat de cloud maar één 'execution environment' is en probleem van lifecycle management heel wat langer speelt. Vorige week kwam dit trouwens nog ter sprake bij onze oosterburen toen niet alleen geconstateerd werd dat de governance van SOA nog in de kinderschoenen stond maar dat de wijze van implementatie te beschrijven was als 0.9 als we even kijken naar roadmap van Zapthink:

http://www.zapthink.com/2008/09/15/zapthink-soa-implementation-roadmap-30/?file_id=ZapthinkSOARoadMap-2008-reduced-ZTS-GI104-1.pdf

Overwegend dat veel Enterprise cloud oplossingen dezelfde 'stove pipe' aanpak is van de jaren 90 waar middels server virtualisatie service delivery versneld is en fysieke footprint verkleind maar uitdaging in service support nimmer opgelost zijn dan heet ik je naar aanleiding van je nieuw opgedane ervaringen welkom in de wereld van de weerbarstige praktijk. Allianz Business Risk Monitor onderkend trouwens ook de 'Rise of interconnected risk' welke ontstaan is door het veronachtzamen van de governance doordat er in directiekamers geen belangstelling meer was voor IT omdat enige wat telde kostenverlaging was. Deze week nog een leuk gesprek gehad over support naar gebruikers, tegenwoordig verwijzen ze je in India naar een website en gooien direct daarna de telefoon erop.

@Ewout - kijk nu komen we ergens. Volgens mij zitten we op de zelfde pagina hoor. Nu nog proberen uit te leggen aan "de business" waarom dit zo belangrijk is. En de business vervolgens de leveranciers onder druk laten zetten. Of... bottom-up approach en nu eens een keer de leveranciers in non-functionals laten denken? Tijd voor volwassenschoenen. Leuke opmerking van iemand pas gehoord "jullie (de cloud leveranciers) zeggen wel dat alles goedkoper wordt, maar waarom wordt de rekening dan toch telkens hoger?".

@Gijs
We zitten misschien in hetzelfde boek maar nog niet op de dezelfde bladzijde, het laisser faire principe aangaande supportability heeft vooral te maken met het feit dat non-functionele processen gezien worden als een kostenpost en niet een besparing. Zoals jezelf al zegt zijn nieuwe functionaliteiten cool en zolang de business niet de pijn voelt van slechte 'supportability' zal er dus niet veel veranderen waardoor het dweilen met de kraan open blijft zoals we zien met ontwikkelingen zoals BYO. En zoals ik al stelde maakt directie zich helemaal niet druk om 'supportability' op de lange termijn en kijkt alleen naar de kostenbesparingen op de korte termijn.

@RJBuitenhuis
Binnen de IT is uiteindelijk alles Work in Progress, stilstand is zeker in deze sector nu eenmaal achteruitgang. Nu wees ik vooral op initiatief van DMTF naar aanleiding van de roep om standaards aangaande de non-functionele requirements waar dus al internationaal aangewerkt wordt. Natuurlijk kun je ook nog even wachten tot leverancier met een product komt om je processen in te richten met gebruikelijke modulaire licentiestructuur maar dat lijkt me dus een herhaling van fouten, de denkwijze van de jaren 90 die ons nu juist zo opbreekt.

@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!

Ewout,
We zijn het gewoon eens met elkaar: SOA+BPM werkt niet.

De Zapthink–poster laat heel fraai zien hoe SOA *niet* gaat werken; hier druipt het procesdenken gewoon vanaf.

En ook Be Informed is een heel duidelijk voorbeeld; niet hoe SOA niet werkt, maar hoe BPM niet werkt. Mooi dat je dat nog even expliciet aangeeft in de omschrijving: modelgedreven business process-platform.

Wat betreft de filosofische benadering: ik wou dat het waar was. Aan mij zal het niet liggen :-)

SOA Wonderland houd ik erin. Heb je niet eens pillen voor nodig.

Henri,
Gaaf geformuleerd:
“In feite is een service die je over de cloud afneemt het front-end van de service.”

Waar zijn de back-ends van zo’n service te vinden?

Gijs,
Vertel je het goede nieuws dat in Next Generation SOA afscheid is genomen van het procesdenken?

:-)

@Jack
Het is mooi dat we het eens zijn maar nog mooier zou het zijn als je aangeeft wat er precies mist of fout is in het verfoeide procesdenken. Want om het simpel samen te vatten, het genie beheerst de chaos en orde en netheid is voor de dommen dus maak ons slimmer;-)

NoProcess. KI. Steven Hawkin zegt dat we dan naar een andere planeet moeten vluchten.

Ewout,

Het gaat niet om slimheid maar om wijsheid.

In het bekende DIKW-model dus opschuiven van DI naar KW.

Wat ik tegen heb op procesdenken is te lezen in het opiniestuk
http://www.computable.nl/artikel/opinie/logistiek/5186714/2380646/supply-chainprocessen-zijn-weinig-transparant.html#5201621
en mijn reactie hierop. Zal je bekend voorkomen :-)

Wel even een nuancering ten aanzien van het “verfoeide procesdenken”: in het alledaags leven maken we voortdurend, veelvuldig en ook met plezier (of ergernis) gebruik van processen, maar dat wil nog niet zeggen dat onze dienstverlening ook procesmatig tot stand komt.


Gijs,
Je reactie is vers van de pers, want als ik even zoek op “Stephen Hawking kunstmatige intelligentie” dan zijn veel berichten hierover de afgelopen dagen verschenen.

Persoonlijk vind ik dit soort berichten regelrechte flauwekul. Wie beweert dat machines, robots, etc. een vorm van bewustzijn en denkvermogen zullen krijgen heeft niet het minste benul wat menselijk bewustzijn en denken eigenlijk inhoudt. Hawking mag dan een briljant natuurkundige zijn; filosofisch is hij ver beneden de maat.

@Jack
Wijsheid (en ervaring) komt met de jaren, je DIKW model gaat hier volgens mij al scheef als ik de term 'voortschrijdend inzicht' even bij de hoorns vat. Aangaande Stephen Hawking toon je dus een filosofische eigenwijsheid als ik de 'Six Honest Servingmen' van Rudyard Kipling er even bij haal. Maar dat is dan ook het mooie van filosofie, als de tijd leert dat opvattingen onjuist waren dan pas je gewoon het theoretisch kader aan.

Nu wijken we ontzettend af van het onderwerp - supportability - hoewel ik in het body & mind dualisme denken eerder al een overeenkomst zag met de discussie over business-IT alignment. Alweer twee (licht)jaren geleden heb ik een presentatie online gezet waarin ik het DIKW model gebruikt want uiteindelijk heb je data en processen nodig hebt om tot informatie te komen, vervolgens zullen de patronen en ervaringen je inzichten geven en kom je pas tot wijsheid als je weet wat de vraag precies is.

http://www.slideshare.net/edekkinga/building-a-service-knowledge-dashboard

Stephen Hawking is namelijk niet de eerste of de enige die het dogma van the 'Ghost in the machine' ter discussie stelt. Betreffende je opmerking aangaande het menselijke bewustzijn en denken wijs ik je graag op idee van 'behaviorism' en dan met name de Pavlov hondjes hierin. Empirisch al zo vaak tot uiting gekomen op dit platform, roep iets wat de meute niet zint en de 'sterren-maffia' zal je straffen;-)

@Jack. Watch and learn zou ik zeggen. Laten we over 20 jaar nog eens terugkijken op deze opmerking en constateren dat er wel degelijk machines zijn met een bewustzijn en misschien zelfs wel een spiritueel leider waarin ze geloven :-) Maar we dwalen nu wel wat ver van supportability af.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×