Iedereen wil tegenwoordig een service oriented architecture (soa). Ook de Belastingdienst wil er een, zo zei staatssecretaris Jan Kees de Jager eind vorig jaar in een interview met Computable. Zou dat helpen?
Ene Erik reageert op onze site kort en bondig: "Soa is weer eens de Haarlemmerolie. Inzetten op governance lijkt me zinvoller, architectuur volgt dan vanzelf." Zo is dat.
Soa's raken behoorlijk ingeburgerd en daarmee komen de eerste soa-‘uitdagingen' aan het licht. Zo moeten business managers leren meedenken over services. En moeten er 'eigenaren' komen van services, zodat onderlinge afhankelijkheden vroeg worden gesignaleerd. "Voor je het weet zit je namelijk in een stuurgroep voor het managen van allerlei onvoorziene afhankelijkheden tussen projecten die dezelfde service willen aanpassen", zegt een lead architect bij KLM hierover.
Legoblokjes
Een soa wordt wel eens vergeleken met een doos vol legoblokjes. Helaas gaat die metafoor in de praktijk vaak mank. De soa-technologie is nog niet op alle vlakken volwassen en integratiemogelijkheden tussen soa-standaarden van verschillende leveranciers worden vaak mooier voorgespiegeld dan ze zijn, zo meldt dezelfde architect.
En dat is nog niet alles. Stel je bent een gemeente en gebruikt zo'n driehonderd verschillende applicaties, grotendeels afkomstig van verschillende leveranciers. Dat komt voor. Hoe neem je dat ratjetoe aan toepassingen dan op in je nieuwe architectuur? Dan moeten er toch echt connectoren komen, geschreven door de leveranciers van je legacysystemen, om te kunnen communiceren met je gloednieuwe Enterprise Service Bus.
Nieuwe spelers
Dat is gemakkelijker gezegd dan geregeld. Dus kun je twee wegen bewandelen. Ofwel je probeert het toch en gaat aan de slag met je leveranciers. Ofwel je kiest voor nieuwe spelers, die toepassingen bouwen die meer 'soa ready' zijn.
Hoe dan ook: wie voor een soa kiest, heeft genoeg om handen. Een soa is namelijk geen Haarlemmerolie, hoe graag we dat ook zouden willen geloven.
| Dossier: Service Oriented Architecture Een Service Oriented Architecture is dè hype in ict-land. Maar een soa verzuipt soms in zijn eigen succes. Daarom komt Computable met een dossier over soa, dat onder andere tips biedt voor een succesvolle soa-implementatie. Het Kadaster, Zwitserleven, een aantal Brabantse gemeenten, KLM, E.ON en het NICTIZ hebben wisselende ervaringen met het implementeren van een SOA. Bezoek ook ons seminar op 27 maart. |
Al die systemen, sorry het is gewoon kull.
Als je echt iets wilt, bouw het zelf, een eigen SQL server, en een interne programeur. Alles past perfect en dan ben je echt af van die 3th parties.
Data informatie is zo simpel, maar we kunnen er zoooo moeilijk over doen.
Meestal verzuipt men omdat men alles teglijk wil men verschillende paketten gezien heeft, die toch weer net niet passen.
Het voordeel van inhouse ontwikkeling, geen afhankelijkheden van derden. Je kunt altijd de code naar wens aanpassen. Grotere bedrijven hebben doorgaans voldoende personeel hiervoor indienst. Belasting diensten etc..
Alleen bij kleinere bedrijven daarbij gaat dat wat moeilijker, die kopen wat er op de markt bestaat.
Maar er zijn helaas veel grote ICT bedrijven die te klein denken in Nederland.
Nog een tip toe, richt je bij het ontwikkelen vooral op de eindgebruikers.
En je zult wel moeten want je intern ontwikkeld, zijn dat je klanten.
Heel anders dan bij 3th partys die ontwikkelen en luisteren meer naar management (wat vervolgens weer het probleem heeft dat het onwerkbaar is voor de werkvloer). Intern ontwikkelen, is anti tijdelijke projecties die op niets uitlopen. Intern ontwikkelen staat garant aan langdurige duurzame ontwikkeling. Met evt nog de optie om de software te verkopen..
Het moest maar eens gezegd worden, als die floppende externe project experts.. ’t konst ons allen al zoveel geld.