Some industry experts believe that SOA is out of vogue -- it's too expensive, or not delivering on promises such as business agility. I think that some of those things are very true. The problem is, organisations aren’t given the funding. They want to use SOA to tie information systems, but a lot of times they can’t get off the SOA treadmill to implement SOA-based technology. There are schedule and cost concerns, absolutely, but I think that SOA is more than just evolutionary, perhaps revolutionary, design principles that are going to be met with opposition and resistance at first, but the goals of SOA are clearly beneficial: better information sharing and collaboration.

SOA interfaces can expose information from legacy systems, where those legacy systems are often 10, maybe 20, years old; they don't communicate well with other systems, and an SOA-type interface is the best way to expose mission-critical data. It hides all the ugly implementation details of that 20-year-old system.

SOA provides a layer of abstraction from the underlying technology and systems. For example, systems that are written in the Ada programming language, which first came out in the early '80s, or even the Assembly programming language. Those are difficult software programs to interface with directly. Without an SOA-based interface it would be a lot more labour-intensive and error-prone to collect information that's generated from those systems. SOA often provides a new life for that legacy system too. You don't have to do a wholesale pull and replace of that legacy system if you can put an SOA wrapper around it. That legacy system will still have life in a modern cloud computing environment, for example. 

It doesn't make sense to expose everything via an SOA interface. One of the first things is to decide what subsystems or specific functionality will be exposed. SOA is best implemented when it's a very atomic, single-purpose service, and those services can be orchestrated or combined at a higher level to produce more complex applications.

Why is it best to use SOA for a single purpose when SOA has been hyped as a way to share services across departments and for reusability? There are cases where it makes sense for each department to have their own service or own capability, because each department has its own mission. So, it might not make sense to combine all of those departments' logistics systems. That's just not feasible. You would never get the community or, in the case of a corporation, all departments with that similar service as a whole to agree on what that service would be.

Advice for CIOs approaching the business about using SOA solutions is that you better allocate the cost and schedule for it. It's not free, but certainly the long-term benefits are good. It's definitely something that's going to evolve over time. You're not going to have SOA overnight throughout your architecture. I would say the best way to implement it is to identify the most key services, offerings or capabilities that your organization provides, and look to those areas for providing SOA services.

Another key question is how can you justify the cost of an SOA implementation? What are the SOA ROI and potential benefits?
It takes a visionary within the company to see that the benefits are probably going to be longer-term, and they're probably going to be in the form of better information sharing and collaboration, but also increased maintainability of the legacy systems. If my systems have this open-standard, SOA-based interface, and I adhere to that contract, I can do whatever I need under the hood in terms of technology refreshes over time. As long as I'm adhering to that SOA contract to my consumers. So, maybe the ROI angle is from a technology refresh and modernisation of the underlying systems point of view, without the impact to information consumers.

Everybody is looking to get a competitive advantage and no CIO is going to sell the idea unless there is a tangible business benefit. So, how does SOA can give companies a competitive advantage? Information sharing is the way ahead to achieve dominance, and what SOA can provide is advanced levels of data fusion. Then you have all this heterogeneous information and services being exposed to one network, one system. Then that information is being aggregated and fused. That level of fusion is really the holy grail of intelligence. That Holy Grail is the ability to manage the business more effectively and profitably.

Clearly there must be difficulties with legacy modernization using SOA solutions? One of the problems is you have this legacy system operating in a stove piped environment. That system is operating independently, and it interfaces with the outside world maybe through human interaction or a text report. That's how it gets its data out. With SOA, you provide a direct connection to that legacy system. As a result of that, that legacy system may see a lot more use, and that system may not have been designed to handle that type of load. So, the underlying system that is being "SOA-tized" has to be able to handle the increase in performance that it may see. You can cache information, which stores a lot of data in memory, since memory access is very fast. You can also do multiprocessing, or multithreading, where you create a couple different instances of the underlying system virtually. That also helps alleviate some of the bandwidth concerns. But increased system demand is a hard problem. Those old IBM mainframes might not have been designed to accommodate dozens, or even hundreds of users.