SOA


In my opinion one of the things that are holding back the wide adoption of SOA is the abstract concept of service. It conveys really vague meaning that you are asking someone to do something for you. But, what is that? Most of the people interpret the service as Remote Procedure Call (RPC) or sending a message.
I believe that we are going to make a breakthrough in SOA adoption if replace the term service with concrete service types that developers and business people can relate to. For example we build applications:
– data;
– operations – programming logic;
– presentation component;
We can define standard interfaces for data service, operation service and presentation component service.

It is much easier to approach the business saying:
– Which data do you want to standardize? Customer, Order, etc. We do not need to discuss specific methods (like how to search for customers). It is handled by data service interface. At some point we need to define the access control to data for different user roles.
– Which business operations do you to standardize? Check customer credit, address validation, etc.
– Which presentation functionality do you want to standardize? Those are coarse-grain presentation components that implement certain workflow like: Make payment, Select cell phone plan, etc.

Conceptually every enterprise application can be a client or server of such services, but it also may make sense to deploy the services in specialized enterprise repositories.

The benefits are really obvious when coupled with an application-level architecture that is based on the same service types. For example it gives developers the flexibility to get a data object from locally implemented data service (using access to DB), another application or Enterprise Data Repository.

SOA like any other term is good only when used in the right context. When used with IT people it allows you to communicate meaning in a condensed form. When used with business people or CEO it is bad term, because it does convey any meaning to them.

Business people will invest money in projects that either deliver ROI or solve important business problem. When IT people go to the business with a proposal for SOA project, they are asking money to replace the existing IT infrastructure with a vague promise of future ROI. That is not good enough for most businesses even in a good time, much less in today environment.

When I started my career as software developer, Borland came up with great suites of software developer tools, Turbo C, Turbo Pascal, etc. They were about to overtake Microsoft in this market. Borland were one of the first to jump on the object-oriented bandwagon. Unfortunately they made the decision to rewrite all their tools using object-oriented technology. By the time they did that Microsoft was a lightning years ahead of them and Borland lost most of the market share they had.

We should learn from this lesson and not kill the business with expenses that do not produce immediate ROI or provide competitive advantage. We should use SOA to deliver business value.

It is our term and we should keep it for ourselves. After all even we cannot agree on a single SOA definition. I see ‘big SOA’ and ‘little SOA’ terms proliferating and that is troubling. If SOA is an architectural approach you either use or not. There is nothing wrong in applying it iteratively. A company may be in an early phase of SOA adoption, but I would not call that ‘little SOA’.