Will SOA kill the idea of applications?
Let’s get real
As SOA begins to gather momentum in the market, there has been a great deal of speculation about whether we will see the concept of an application disappear.
The reasoning goes that a natural consequence of SOA is that systems will no longer be implemented as single monolithic structures, but as a series of component parts that work together to deliver whatever functionality is required.
With such a development, you no longer have to take all of the pieces from one application vendor. What you do instead is select the best bits from each and assemble a system in which every component is best of breed. The net result is an end to the kind of compromises that have traditionally been associated with packaged applications in which some bits work really well for you, while others you have to live with because they are part of the overall solution.
The argument then goes on to say that this obviously marks the end of the application paradigm as we know it, as everyone will be assembling far superior systems by pulling together the optimum mix of components and services in an SOA environment.
Well it sounds good in theory, but back in the real world, this is a load of idealistic sensationalist claptrap.
SOA is no more going to destroy the concept of an application than the evolution of standards-based plug and play components have destroyed the concept of a PC. The idea is just silly.
As discussed in a previous article, too many people are getting themselves all wrapped up in the enabling layers of technology and business processes and are forgetting that at the end of the day it is the business objective that really matters.
If we take a simple example, dealing with the company's accounting requirements in an accurate, compliant, coherent and convenient manner, is that objective really best served by stitching together the world's best general ledger component with the world's best accounts receivable component and the world's best accounts payable component, all from different sources, then having to check that everything really does work together as seamlessly as the standards say it should?
Of course not, and the same goes for most of the other types of application that businesses depend upon to operate. When buyers use language such as "total solution", "integrated system ", "single point of accountability", etc, when defining requirements during the procurement process, it's because they just want someone to solve the problem for them so they can get on with running and developing their businesses.
The reality is that those who want to assemble their own PC, car or business administration system are in the minority. The vast majority of us just want to buy something that works, and know that if it doesn't, we can go back to who sold us it and get them to fix it.
To focus our minds a bit on this one, let's remember how painful it is already when we have two applications from different vendors that are not working together in the way they should, and the frustration of having to deal with the fragmented knowledge, finger-pointing and other issues that commonly arise in this kind of situation. Then multiply this pain by one or two orders of magnitude if the world moves to the false nirvana that the SOA theorists would have us believe we are going to be living in.
So does this mean that the concept of SOA and composite applications is of no relevance in the real world?
Again, of course not. These ideas and approaches will have a huge impact on the ease with which systems can be integrated, the level of reuse and coherency in our IT infrastructures, and the freedom offered to end users to assemble their own front ends in a portal environment. Modern software architectures and approaches to software development and construction will deliver benefits in all of these areas, and more. But arguing that this goes hand-in-hand with the application paradigm dying is just nonsense.
Sponsored: DevOps and continuous delivery