Ik lees veel artikelen over het Service Oriented Computing paradigma. Ik heb OO zien "slagen", in die zin dat het wereldwijd omarmd wordt. Ik heb Component Based Development toch al een stuk minder zien slagen. SOA gaat weer een stapje verder (enterprise wide) en ik ben benieuwd of deze vorm van architectuur kunst gaat slagen. OO is nog goed te overzien omdat het vaak binnen een applicatie blijft. Met herbruikbare componenten werken binnen je afdeling of zelfs binnen de organisatie vergt toch een hele andere vorm van samenwerken. Ditzelfde geldt ook voor SOA. Er is niet voor niets zoveel te lezen over Governance.
Net als de overgang van structured analysis/design (SA/SD) naar OO werd aangenomen dat dat alles zou oplossen. Dit is natuurlijk niet zo, je kunt er nog steeds een puinhoop van maken. Dit geldt ook voor de overgang naar een SOA, alleen dan nog een paar gradaties erger. Daarom denk ik dat het een zeer goede practice is om kleinschalig te beginnnen en eerst maar eens proberen om een enkele applicatie (Silo) te "SOAliseren". Dus verticaal i.p.v. horizontaal en dan beetje bij beetje meer zaken gaan toevoegen. Maar op deze manier doe je al ervaring op met Services en het herbruikmaar definieren van de Services. Ook kom je er dan achter dat er verschillende Service levels zijn (Entity, Task en Utility Services). Entity is een service die een business term omvat (dus zeer herbruikbaar), een task service is meer expliciet voor een stukje van een specifiek business process bedoeld (dus vaak ook minder herbruikbaar) en een utility service is meer een horizontale service zoals bijvoorbeeld voor logging of error handling.
Dus eerst maar eens terug naar de basis en een nette 3-tier applicatie bouwen dat is denk ik voor veel organisatie al een uitdaging op zich.
Net als de overgang van structured analysis/design (SA/SD) naar OO werd aangenomen dat dat alles zou oplossen. Dit is natuurlijk niet zo, je kunt er nog steeds een puinhoop van maken. Dit geldt ook voor de overgang naar een SOA, alleen dan nog een paar gradaties erger. Daarom denk ik dat het een zeer goede practice is om kleinschalig te beginnnen en eerst maar eens proberen om een enkele applicatie (Silo) te "SOAliseren". Dus verticaal i.p.v. horizontaal en dan beetje bij beetje meer zaken gaan toevoegen. Maar op deze manier doe je al ervaring op met Services en het herbruikmaar definieren van de Services. Ook kom je er dan achter dat er verschillende Service levels zijn (Entity, Task en Utility Services). Entity is een service die een business term omvat (dus zeer herbruikbaar), een task service is meer expliciet voor een stukje van een specifiek business process bedoeld (dus vaak ook minder herbruikbaar) en een utility service is meer een horizontale service zoals bijvoorbeeld voor logging of error handling.
Dus eerst maar eens terug naar de basis en een nette 3-tier applicatie bouwen dat is denk ik voor veel organisatie al een uitdaging op zich.
Reacties
Een reactie posten