Bringing it back to the old school.

An interesting email came across the SOA yahoo group today.

I was recently involved in a workshop looking at the relationship between “service oriented architecture” (SOA) and “component based architecture” (CBA) as enterprise architecture approaches.
We took, as an example, a hospital and tried developing both SOA and CBA views. This is roughly what emerged:
1. SOA View
In the SOA view the hospital was viewed as a set of services, which could potentially be provided by different suppliers. Example services were: Hospitality, Catering, Pathology, Theatre, Specialist. (Note that we took a “Business” view of services rather than an “IT” view, along the lines suggested by Pat Helland of Microsoft). We derived a IT architecture from this, by aligning the data and functionality to the services. This led to an architecture in which the data/functionality for a given patient was distributed to different services: “Hospitality” owning information about patient accommodation and nursing routine; “Catering” about dietary requirements; “Specialist” owning medical notes; etc.
2. CBA View
The CBA view (loosely based on the approach recommended in the book “UML Components” by Daniels and Cheeseman) drove the architecture from the core business entities and built services around them. In this approach, basic patient data and functionality was not distributed but owned by a single “Patient” component.
This example suggests that SOA and CBA lead to different results when applied to enterprise IT architectures. I would be interested in any views on the following questions:
Is this a valid/useful conclusion?
If so, can SOA be regarded as “superior” to CBA as an architectural approach?
Any views/comments welcome.

My response was as follows:

I think the central idea lies in your clarification after you list your example services.  You state that you took a “Business” view of services, as opposed to a “IT” view.  Though you don’t explicitly state it, I think that a “IT” view was taken when discussing the CBA route.  One could easily take a “Business” view of components, thuse arriving at the same architecture, albeit at a much lower level of grainularity.

In the end, I think that the superior architectural approach will end up being a mixture of both, SOA at a high, corse grained level that wraps a CBA, at a more fine grained level.

This is, of course, nothing that new.  A similar architectural approach was taken in back in the CORBA days, though the the abstraction was not pushed as high as it is today.  It was thought that a coarse CBA could be used to encapsulate a fine grained OOA.


Everyone is going to have to start thinking a few abstractions up if they are to get any sorts of benefits from SOA, services, etc….