Service Orientation is said to bridge the gap between Business and ICT. In Archimate, the Architecture language, the concrete result of this can be seen. Services is a core element of the language. And this core element bridges the gap between different architecture levels. External business services bridge the gap to the outside world and external application services bridge the gap between business architecture and information architecture. Technical services do the same between information architecture and technology architecture.
Can services be drawn between the horizontal Zachman layers aswell, I wonder?
Sunday, March 25, 2007
Monday, March 12, 2007
Remodularizing Heritage Systems
Some people might think that to fit heritage systems (nicer term than legacy) into service oriented architecture, you only need to create services on top of them. My opinion however is that, to acquire real flexibility, the decomposition of the heritage systems is at stake aswell.
As Harry Pierson writes here:
"SOA is a way of implementing IT systems as a web of interconnected yet independent loosely coupled subsystems (typically called services) instead of as big honking systems we have traditionally built that tend to be unwieldy, in-agile, difficult to change and probably obsolete by the time they were deployed."
and I totally agree with that. Simply putting services on top of heritage systems is good for integration and reuse, but not for flexibility.
As Harry Pierson writes here:
"SOA is a way of implementing IT systems as a web of interconnected yet independent loosely coupled subsystems (typically called services) instead of as big honking systems we have traditionally built that tend to be unwieldy, in-agile, difficult to change and probably obsolete by the time they were deployed."
and I totally agree with that. Simply putting services on top of heritage systems is good for integration and reuse, but not for flexibility.
Wednesday, March 7, 2007
Service Normal Form
Today I was working on finding relevant business services. As normal I used criteria like good abstractions, good separation of concerns, maximum cohesion and minimum coupling, added value of a cohesive set, in the numbers 7 +/- 2 for any level and a relevant service requestor could be found. But the design decisions I made did not completely satisfy me. Suddenly a thought struck me: just as in database theory there should be service normal forms, with standard rules to get to, validate and optimize the correct services.
Surfing internet it turned out that others had already had the same thought. They are researching "what kind of properties a "good" service should have". I will read it and come back on this subject later.
Surfing internet it turned out that others had already had the same thought. They are researching "what kind of properties a "good" service should have". I will read it and come back on this subject later.
Monday, March 5, 2007
Initiative in an SOA architecture
I am charmed of the figure below (originally by BEA). Most of the layered SOA models put the GUI layer on top, near the user. Then follows the proceslayer, business logic layer and data layer.
I always wondered which layer had the initiative. It always seemed that initiative coming from the user had to come from the GUI layer and had to pass all layers.
In this figure however it seems (if the user is on top of the figure) that this composite applications layer wil have the initiative. Only after some action in that layer, the user will get a presentation. Presentation is not first. This seems a logical order to me. The Composite Applications layer also can access all other layers, without going through the others. That is the second thing I like. I am still wondering whether accessing Information Services directly is a wise thing to do, without going through Business logic. I can imagine that is ok when just accessing and viewing information.
I always wondered which layer had the initiative. It always seemed that initiative coming from the user had to come from the GUI layer and had to pass all layers.In this figure however it seems (if the user is on top of the figure) that this composite applications layer wil have the initiative. Only after some action in that layer, the user will get a presentation. Presentation is not first. This seems a logical order to me. The Composite Applications layer also can access all other layers, without going through the others. That is the second thing I like. I am still wondering whether accessing Information Services directly is a wise thing to do, without going through Business logic. I can imagine that is ok when just accessing and viewing information.
Thursday, March 1, 2007
SOA, the two speed architecture
I was in a discussion today with Ruud van Vliet about the two worlds that SOA seems to deliver.
We noted that SOA delivers a slower world of core competences, core services, that need to have high quality and robustness. Typically these services are delivered in cycles or releases of 3 months+. In most enterprises these services are hidden in heritage (nicer term than legacy) systems currently and must be freed gradually.
And we noted a fast world of Mashing up, Composing, Integration and Process Flow, in which changes can be done by the day. This is especially seen in the Web 2.0 world, where mashing up (combining and remixing) existing data and services on the web is a trend. Typically new services are and can be delivered in minutes or days.
This might result in new roles in the information landscape. On one side communicative, fast business analyst that can configure new experiences for the business in short periods of time, reusing existing services from a service repository. And techies, that deliver new core services on a longer timeframe.
We noted that SOA delivers a slower world of core competences, core services, that need to have high quality and robustness. Typically these services are delivered in cycles or releases of 3 months+. In most enterprises these services are hidden in heritage (nicer term than legacy) systems currently and must be freed gradually.
And we noted a fast world of Mashing up, Composing, Integration and Process Flow, in which changes can be done by the day. This is especially seen in the Web 2.0 world, where mashing up (combining and remixing) existing data and services on the web is a trend. Typically new services are and can be delivered in minutes or days.
This might result in new roles in the information landscape. On one side communicative, fast business analyst that can configure new experiences for the business in short periods of time, reusing existing services from a service repository. And techies, that deliver new core services on a longer timeframe.
Subscribe to:
Posts (Atom)
