SOA: Looking inside IT

Usually when we talk about SOA, we talk about two distinct groups: Business and IT. With that, we discuss how SOA impacts and applies to each of these groups and further go on to try and figure out who is more accepting or less accepting etc. The more I see SOA initiatives first hand, the more I start to wonder if these groups are too course grained.

Its very natural for us to settle on only two categories. Its easier to talk about things as if they were black and white, on or off, your fault or my fault. Most of the time this is done to simplify a problem so we don't get bogged down in the minutia of the gray area. For this topic though, I feel that polarizing the participants into two categories obscures a very important piece of the puzzle.

We use the term "Business" to refer to all non-technical functions and resources and "IT" for everything and everyone else. While Jeff Schneider did a good job of breaking down the Business for the purposes of SOA interaction, I feel that IT needs some breaking down of its own.

Within the IT category we have two distinct roles. The first role is that of the enterprise architect although they need not have this title to be in this role. The folks in this role typically see the big picture. They understand the value of design and architecture and strive for consistency and foresight. This group usually sees the value of SOA much in the same way the Business does, although they see it with technical goggles on.

The second role is that of the project teams. This usually consists of project architects, project managers and developers. This group is firmly based in reality and even if they see or could be made to see the value of SOA, they would point to the 3 projects they have going that all have to be done yesterday, shrug their shoulders and laugh about the crazy SOA guys over a beer.

Of course it takes both of these groups working together in some fashion to make any progress towards a Service Oriented Enterprise. It means nothing to have your EA group creating SOA strategies and processes if they don't have the means with which to realize any of it. Implementing registries and documenting business processes are a great start, but unless the project teams are integrated into the process, all you'll be left with are nice diagrams and a bad case of ERS.

So when you are addressing the issues of your SOA initiative, don't blindly look at IT as one big group that needs to get their act together. Rather you need to focus on how you can facilitate the coordination of these two distinct IT roles.

Component or Service?

What exactly is the difference between a component and a service?

This is a question that popped into my head when reading a response to Todd Biske's blog entry Challenge of Data Services. In the response, Udi Dahan comments that access to data should be done through components and not services. But what exactly is the distiction that Udi is making here?

After trolling a bit for a definition of a component, I came across the following on wikipedia:

A software component is a system element offering a predefined service and able to communicate with other components.

Clemens Szyperski and David Messerschmitt give the following five criteria for what a software component shall be to fulfill the definition:

• Multiple-use


• Non-context-specific


• Composable with other components


• Encapsulated i.e., non-investigable through its interfaces


• A unit of independent deployment and versioning

A component is an object written to a specification.

A definition of service comes from ServiceOriented.org:

A Service is a callable routine that is made available over a network. Services have well defined interfaces (inbound and outbound).

While you may argue the exactitude of all these definitions, its pretty easy to see that a service and a component are very similiar if not indistinguishable. In fact it might be that the only difference between a service and a component is its accessibility via a network.

One might argue that a service is nothing more than the manifestation of a component on a network. To make this point I ask the following question: Does a component, written as a Java class, suddenly become a service when it is made accessible via an EJB or a Servlet or a Web Service? Or does it remain a component which is now offered as a service?

Of course you could still argue that the component was always a service from the point of view of other local Java classes.

I believe the Service Component Architecture puts its best:

SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces called services...

Given all of this, if data should only be accessed via components and not services, then what happens when my Java implemented service needs access to data that is exposed via a .NET component? Do I re-write the component in Java and maintain both implementations? Or would I make that component a service and be done with it?

Thus I see no reason why data access can't be done via services.