Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 30. september 2005.
Erfaren konsulent maner til omtanke ved implementering af SOA.
"Der bliver løjet og fordrejet kendsgerninger langt ud over det anstændige om fordelene ved SOA (serviceorienteret arkitektur, red.)".
Bemærkningen blev fremprovokeret i mandags på JAOO-konferencen, da den erfarne konsulent Nicolai M. Josuttis fortalte om sine erfaringer med at implementere en serviceorienteret arkitektur i et stort telefonselskab. Hans bemærkning udløste et spontant bifald fra tilhørererne til hans indlæg "SOA - fra hype til virkelighed".
Nicolai M. Josuttis er slet ikke afvisende over for fordelene og mulighederne i serviceorienterede arkitekturer; han ønsker blot, at forventningerne afstemmes med virkeligheden.
Konsulenten blev provokeret af en tilhører, der bemærkede, at hans forretningsfolk vil have en serviceorienteret arkitektur "fordi det skaber fleksibilitet og gør dem i stand til hurtigt at tilpasse it til nye forretningsmuligheder".
Tilhørernes bifald tyder på, at de deler Nicolai M. Josuttis' opfattelse. SOA er blevet oversolgt og har givet nogle forretningsfolk urealistiske forventninger.
Erfaringerne fra Nicolai M. Josuttis' projekt er blandt andet, at udrulning af nye versioner af services ikke er så fleksibel, som det ellers ofte bliver beskrevet. I projektet fik man kun lov til at udrulle nye serviceversioner hver tredje måned, da der var afhængighed mellem de forskellige services i arkitekturen.
SOA nævnes ofte sammen med de såkaldte agile udviklingsmetoder, men også her måtte Nicolai M. Josuttis skuffe tilhørerne.
- Vandfaldsmodellen kommer tilbage i de tilfælde, hvor man har systemer i produktion, sagde Nicolai M. Josuttis. Med de agile metoder opererer man med en iterativ udviklingsproces, hvor man løbende designer, koder og tester. Vandfaldsmodellen er derimod en mere skarpt opdelt udviklingsmodel med klar afgrænsning mellem analyse, design, udvikling og test.
Performance er et andet område, som man skal være meget opmærksom på når man planlægger en serviceorienteret arkitektur. Selvom hver enkelt service har en acceptabel svartid, eksempelvis et sekund, vil en forretningstransaktion der involverer flere services hurtigt få en uacceptabel svartid på flere sekunder.
Nicolai M. Josuttis ville ikke afvise, at nogle af de dårlige erfaringer fra projektet skyldtes forkerte arkitekturbeslutninger. Blandt andet havde projektet valgt at benytte stærk typebinding. I modsætning til svag typebinding giver det mulighed for at finde flere fejl ved kompileringstidspunktet, men til gengæld betyder det, at de enkelte services ikke er så løst koblede; der opstår afhængigheder mellem services, hvilket giver mindre fleksibilitet. En anden arkitekturbeslutning var at skabe et dataabstraktionslag. Det fik alvorlig indflydelse på svartider. Et dataabstraktionslag gør det populært sagt muligt at udskifte den underliggende database, uden at der skal ændres i programlogikken. Til gengæld koster det ekstra lag en reduktion i performance.
I dag ville Nicolai M. Josuttis have valgt at implementere datatilgang som stored procedures [programlogik i selve databasen] for de vigtigste services.
Nicolai M. Josuttis, der er medlem af C++ standardkomiteen og forfatter til en række bøger om programmering, advarede om, at SOA er i fare for at gentage, hvad der overgik objektorientering, da det var det nye og hotte. Dengang var objektorientering svaret på alt. Nu bliver SOA alt for ofte brugt ukritisk.
- Det vil tage år, før vi har en fornuftig forståelse af SOA, mener Nicolai M. Josuttis.
Billedtekst:
Sund skepsis - Tro ikke på alt, I hører om SOA, sagde Nicolai M. Josuttis på JAOO-konferencen.