Een samenvatting van Top 10 soa-valkuilen. Ze zijn verspreid over meerdere aspecten, te weten organisatorische, architectuur en ontwerp en implementatie.
Het is een lijst van tien vaak voorkomende valkuilen bij een introductie van een soa die mijn Xebia collega’s (Vincent Partington, Rik de Groot en Gero Vermaas) en ik in de praktijk tegenkomen. Per valkuil zijn gelijk oplossingsmogelijkheden aangedragen. Tijdens het samenstellen van deze lijst hebben we al vrij snel een groepering per type ontdekt. Nummers #1 en #2 zijn gerelateerd aan organisatorische aspecten. Dit zijn typische valkuilen die wij tegenkomen gerelateerd aan organisatiecultuur en mentaliteit. De volgende groep: #3 tot en met #7 heeft te maken met architecturale en ontwerp vaardigheden. En uiteindelijk het laatste groep, nummer #8 tot en met #10, zijn de implementatie gerelateerde kwesties. Dit is het complete lijst en ieder titel is aanklikbaar.
#10 – Not invented here syndroom
Een van de soa-doelen is servicehergebruik. Echter, als de afdelingen binnen een bedrijf services nodig hebben, zijn ze vaak geneigd deze zelf te bouwen in plaats van bestaande van iemand anders te hergebruiken.
Een ander typisch verschijnsel zijn de bedrijven die een eigen Enterprise Service Bus bouwen. Dit zijn vooral bedrijven die heel vroeg met soa zijn begonnen, toen ESB’s onvolwassen waren of niet bestonden. Er zijn echter nog steeds organisaties die zelfs vandaag nog besluiten om een eigen ESB te gaan bouwen, vaak zonder dat ze dit beseffen.
#9 – Versioning
Het uitbrengen van een nieuwe versie van een service heeft effect op de aangesloten afnemers. Impact verschilt echter per type wijziging en men kan er verschillend mee omgaan.
#8 – Security
Soa kan grote beveiligingsproblemen introduceren. Het vraagt ook vaak een andere kijk naar de beveiliging. We komen bedrijven tegen die dit aspect van soa volledig passeren of op een traditionele manier benaderen.
#7 – Incorrect Granularity of Services
Het kiezen van de juiste service granulariteit is bijzonder lastig en het zou veel inspanning moeten kosten. Hier zijn geen kant-en-klare recepten voor, maar een aantal valkuilen.
#6 – SOA does not solve complexity automatically
Sommige organisaties introduceren soa om de complexiteit van hun heterogene omgevingen te reduceren. Echter, soa brengt slechts de middelen om de complexiteit gestructureerd aan te kunnen pakken. De complexiteitsproblemen zijn in het begin, door de introductie van integratielagen, vaak nog groter.
#5 – Big Design Up Front (BDUF)
Een oude discussie uit de wereld van projectmanagement methodieken: Agile vs. Waterval duikt in de soa-wereld ook op. Moeten we bij introductie van een soa een volledige architectuur en ontwerp hebben voordat we met implementatie beginnen? In deze blog item worden een aantal cruciale nadelen en consequenties van 'Big Bang' benadering genoemd.
#4 – Incorrectly applied Canonical Data Model (CDM)
We komen klanten tegen die proberen één grote CDM te maken met alle entiteiten en velden van het complete bedrijf. Hier zou iedereen zich dan aan moeten houden. Een andere valkuil is dat men probeert zelf modellen te bedenken, terwijl de benodigde (sub)datamodellen in hun industrie al lang bestaan. Zo zijn er nog een aantal valkuilen en erbij behorende tips.
#3 – Missing skills
Bedrijven starten met introductie en implementatie van soa vaak zonder de nodige competenties, zowel op de werkvloer als in de management.
#2 – Unclear ownership / Project based funding
De eigenaarschap en bekostiging van services en middleware die ontwikkeld en beheerd moeten worden is veel complexer dan bij zelfstandige applicaties. Men komt hier laat achter. De gevolgen zijn een dozijn aan stuurgroepen en overlegorganen of een willekeurige afdeling die zelfstandig een soa voor iedereen introduceert. De blog item beschrijft een aantal situaties en de mogelijke oplossingsrichtingen.
#1 – Ignoring culture when introducing SOA
Er is weinig besef wat introductie van soa met zich meebrengt met betrekking tot organisatiecultuur aspecten. Tegelijkertijd introduceert men soa ook soms om de cultuur te veranderen. Dit vindt vaak onbewust plaats. Het grote probleem is dat er geen expliciete aandacht voor is en dat alle focus naar middelen in plaats van mensen gaat.
Dit is natuurlijk geen complete lijst van alle soa-valkuilen, maar voor ons de meest opvallende. We horen heel graag wat je van ieder punt afzonderlijk en de complete lijst vindt.
In het verlengde van #3 – Missing Skills, breng ik graag de beheeraspecten onder de aandacht. Beheer van soa-systemen is lang niet uitgekristalliseerd en is dus nog onvoldoende geformaliseerd. Dit vereist een andere aanpak: organiseer het beheer op een adhocratische wijze (multidisciplinair team met hoogwaardige expertise, veel onderlinge afstemming en weinig formele procedures). Zodra de spelregels van dit nieuwe beheer zijn ontdekt, kan het geformaliseerd worden en worden gepromoveerd tot normaal beheer bij de reguliere beheerorganisatie.
Meer hierover op: https://www.computable.nl/artikel/ict_topics/beheer/2591606/1277800/de-blinde-monnik-smalley-en-de-olifant-soam.html