Steve Mills heeft er zeker gelijk in dat het er niet toe doet welk buzzword je gebruikt - servicegerichte architectuur (SOA) of enterprise application integration (EAI) - maar goed gestructureerde en geautomatiseerde bedrijfsprocessen zijn nodig om processen te optimaliseren en serviceori?ntatie te verhogen door gebruik te maken van gedeelde services, vaardigheden en bronnen. Mijns inziens moet dit een combinatie zijn met business process management (BPM), waarin SOA ?slechts? de technische enabler is.
 
Door het gedachtegoed van SOA in te zetten in combinatie met BPM, zijn organisaties o.a. in staat snel in te spelen op veranderingen in wet- en regelgeving. De IT-afdeling behoort compliance en risk management mogelijk te maken. Organisaties die zowel compliance als risk management allebei goed georganiseerd hebben, zullen eenvoudiger investeerders, klanten en werknemers kunnen aantrekken. Met als gevolg dat ze belangrijke concurrentievoordelen kunnen behalen. De vraag naar SOA of EAI ontstaat onder andere door de strengere regulering van onder meer de financi?le sector, alhoewel dit natuurlijk ook voor andere branches geldt.
 
Naast het feit dat de markt naar regulering kijkt, verwacht ik ook een stijgend aantal fusies, overnames en desinvesteringen. Hierbij hebben organisaties die draaien op monolithische systemen of omvangrijke ERP-pakketten het veel lastiger om er goed op in te spelen, dan bedrijven die SOA hebben ingevoerd. Het is immers een ingewikkelde klus om grote, logge bedrijfsapplicaties op te splitsen in modules die overdraagbaar en herbruikbaar zijn.
 
Het rechtvaardigen van investeringen in IT-enablers zoals SOA en EAI zijn makkelijker door deze rechtstreeks te linken aan voordelen voor ?de business?, dan puur op technische functionaliteit van SOA of EAI. Zeker in de huidige, terughoudende economie.
 
Ferrie Roelfzema
Software AG

Leuk verhaal Ferry, maar of het nou soa, component oriented of blala architecture is, de basis blijft gelijk; Modulaire Decompositie.

SOA is behoorlijk anders dan 'slechts' modulaire decompositie. In een service oriented architecture heb je te maken met een brooker. De componenten worden niet als programma geduid, maar als service. De brooker verbindt de service met het betreffende programma, eventueel onder voorwaarden. Handig daarin is dat je het nieuwe systeemonderdeel al maanden tevoren in productie hebt gebracht, waarbij een selecte groep gebruikers op een selecte groep klanten (of testklanten, whatever), al met de nieuwe software aan de gang kunnen. De brooker kan eventueel online gestuurd worden om een andere verbinding aan of uit te zetten. De nieuwe software kan automatisch per een bepaalde datum operationeel worden. Die flexibiliteit heb je doorgaans niet bij een standaard modulair opgezet systeem. SOA eigenschappen kunnen door geavanceerde source-conversie aan een systeem worden toegevoegd. Dan vallen de kosten nogal mee. De prijs en kwaliteit bij conversies is aanzienlijk hoger dan bij welke 'OUTS'ourcing ook. Als het betreffende systeem nog niet onder architectuur was gebouwd, profiteer je gelijk van de architectuur-standaards. Zo mag een onderliggend programma nimmer meer dumpen. Zo mogen er tussen subsystemen geen domino-effecten optreden. Oftewel een 24 x 7 upgrade maakt van zo een traject deel uit. Altijd bereid een presentatie te houden hoor.... :-)