I read a CIO article called "The Truth About SOA" by Christopher Koch. Overall it is a good article but just as you would expect from anyone who claims to know the truth about SOA, there are many debatable points. He openly states that SOA is far from a proven concept then goes on to say that a significant number of companies have two years experience experience with SOA and that large companies have had success. He is right, many companies have had success. Doesn't this mean that SOA is a proven concept? I think it is. Ask Amazon and eBay who's business model pretty much is founded on SOA concepts. However, just because SOA is proven doesn't mean that it can be used by any organization to do anything. A hammer is proven to drive nails into lumber. Using only a hammer to build an entire house may not be proven.
A fundamental underpinning of his argument seems to be that SOA requires a large, top down, enterprise architecture approach to building cross-organizational systems. Admittedly, that is one way to do it, however, it probably is not the best way. I don't believe that you can design and build a portfolio of services. You design and build services. You grow a portfolio of services. I espouse the market approach to SOA. Who sits down to design and build a market?
If you set out to re-design your companies business processes as part of your SOA effort then pack your bags for the train to failure. You will never get past go. In my experience any significant change is driven from the bottom-up (with senior level support) and momentum dictates success. Use SOA to create more flexible and open systems to allow the organization to evolve its business processes. Don't set out to transform your business. Enable transformation to occur by solving real problems with an eye towards creating value not only for your primary "customer" systems but to the larger organization. The old adage, "Think globally, act locally" is key to SOA effectiveness. SOA efforts should be held to no more than 180 day delivery cycles.
SOA is best accomplished by examining your current and future systems interoperability needs against your current interoperability capability (including maintenance costs). If there is no mismatch, then don't do SOA. Well, it isn't that simple but it certainly isn't as hard as transforming your organization. You should also look at the need for distributability of systems and your requirement for more modular systems that need to evolve quickly and maybe even in unanticipated directions. The power of SOA is that I can use it to build something to meet a need that I know I have (or better yet, that I know the "market" has) and yet build it in a manner that facilitates its utilization in ways I did not foresee or by users I would not otherwise be able to reach.
I agree with Mr. Koch that SOA requires more architecture and design rigor, however, the reason for that rigor is to facilitate distribution of effort. This means that because I have taken the time to design this service I now have more options in how I source its fulfillment whether I build, buy, or leverage. Therefore, I strongly disagree with his assertion that SOA requires a "centralized development methodology" and a centralized staff. We are building SOA design packages that we ship out to industry as part of an RFP. Industry can propose a solution that is built from scratch or one that leverages a current existing system or one that involves a packaged application. This is Net-Centric systems delivery.
As far as ROI goes. Of course it is difficult to calculate the ROI of transforming your business. If you set this as your goal then the risk of failure is extremely high and probably will have little to do with SOA technology and more to do with culture and politics. However, if you have a system that interfaces with multiple other systems and integration maintenance costs are killing you, then an ROI might be easier to calculate.
It is also interesting how people seem to treat SOA investment as a new problem. The dilemma has existed since the first time a human being built anything. Do I build it quick and cheap realizing it will only last for a short time or do I spend a little more time and money for something that will last longer and require less maintenance. Nothing new here.
I could go on and on here but I need to get back to building something.
Bottom line: Don't ask SOA to transform your business.
Comments