Service-oriented architecture (SOA) is a method for linking business and IT resources on demand so that desired services can be provided for customers. The objective is that, when SOA is properly implemented, businesses can respond relatively quickly and cost-effectively to changing market conditions.
Principally, SOA is intended to connect applications across networks through a common communications protocol, allowing organisations to reuse old software, often with the help of Web services.
There are certainly examples of enterprises succeeding with SOA, building services that can be shared across business units, and lowering long-term expenses. SOA is intended to make it easier to do compliance reporting, software-as-a-service, legacy modernisation, unified communications, business intelligence, and various other important tasks.
But does this really work in practice? Even more importantly, does it pay off?
SOA is architecture and is thus applied across the business, not project-by-project.
For SOA to work it must be applied uniformly across the enterprise. Furthermore, any changes or additions to underlying systems must also undergo the additional work required to bring them into the SOA compliant framework.
SOA needs to prove itself to the business. They need to know not only what the ROI is, but when it will happen. So, what is the potential return to the business to justify the usually very high costs?
Many companies would look to use SOA in order to service enable legacy systems. SOA is a big up-front cost and should be justified. SOA should be thought of as an enabling software infrastructure. In other words SOA cannot in itself be cost justified as no particular ROI could ver be attributed to it.
Therefore, you have to look at future individual projects and their tangible benefits to cost justify the underlying SOA infrastructure. IT departments have been calculating the cost and benefits of infrastructure for years, such that a single project cannot be expected to cover the initial cost of any corporate-wide change to its systems infrastructure.
Reuse is the most important metric by which large companies will be measuring the success of their SOA efforts – but most don’t expect high levels of reuse to happen any time soon.
A new survey commissioned by BEA Systems finds that a majority of the largest global organizations (61%) expect no more than 30 percent of their SOA services to be eventually reused or shared across business units. In fact, only five percent expect to see more than half of their services to be reused.
However, despite the management support and inflow of new money, Sara Hepner, senior director of services marketing for BEA, observed that 40% of these enterprises said their “SOA projects were impeded due to justifying the investment financially. They’re having a hard time building strong ROIs.” Software infrastructure was the most significant cost involved in SOA projects, she said.
So how much will an SOA project will really cost the business? Dave Linthicum recently posted some guidelines on estimating the cost of a service-oriented architecture project.
Dave offers the following formula:
Cost of SOA = (Cost of Data Complexity + Cost of Service Complexity + Cost of Process Complexity + Enabling Technology Solution)
How do you measure the cost of complexity? Here's how Dave says the calculation is done, for example, to arrive at the first variable, the cost of data complexity:
Cost of Data Complexity = (((Number of Data Elements) x Complexity of the Data Storage Technology) x Labor Units))
- The "Number of Data Elements" is the number of semantics you're tracking in your domain, new or derived.
- Express the "Complexity of the Data Storage Technology" as a decimal between 0 and 1. (For instance, Relational is a .3, Object-Oriented is a .6, and ISAM is a .8.)
- "Labor Unit" is the amount of money it takes to understand and refine one data element, e.g. £100
As an example, you could arrive at a solution such as this:
Cost of Data Complexity = (((5,000) x .5) x £100) This equals £250,000 for this portion of your SOA costs.
The next step is to apply the same formulas to determine the costs of other variables, including Cost of Service Complexity, Cost of Process Complexity, and Enabling Technology Solution.
Conclusion
Inevitably it would be prudent to allow a generous contingency for both cost and time in any estimate.
From this you will see that costs are likely to escalate into the £M's and that timescales are also likely to be measured in years and months, not weeks and days. IT system designs sometimes overlook the desirability of modifying systems readily.
Many systems, including SOA-based systems, hard-code the operations, goods and services of the organisation, thus - once again - restricting their online service and business agility in the global marketplace.
Conclusion
Inevitably it would be prudent to allow a generous contingency for both cost and time in any estimate.
From this you will see that costs are likely to escalate into the £M's and that timescales are also likely to be measured in years and months, not weeks and days. IT system designs sometimes overlook the desirability of modifying systems readily.
Many systems, including SOA-based systems, hard-code the operations, goods and services of the organisation, thus - once again - restricting their online service and business agility in the global marketplace.