Thursday, 14 January 2010

Does SOA really deliver flexible business process management?

To keep customers purchasing services and products, continuous improvement of processes must be an ever-evolving strategy for most organisations. The more flexible that business processes are, the more agile an organisation can be in responding to market demands and customer needs.


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.

Monday, 2 November 2009

Trends in the use of ERP in Europe

It has been estimated that annual spend on maintenance and process customisation in the ERP and CRM market represents around 20% to 33% of the overall market spend – indicating an annual spend on maintenance and process customisation of between £1.75 and £2.75bn.

Today, however, ERP systems face serious problems.  Many companies are abandoning traditional ERP systems and are looking for more effective options to meet their business requirements – including software-as-a-service and hosted solutions.

According to Upside Research Inc., almost all enterprise organisations have made significant investments in ERP, CRM, and other packaged applications. Yet in many cases, business drivers are requiring an ever-increasing stream of process changes and additional functionality (or simply integrations) that need to leverage ERP capabilities.

However, these systems are also costly to maintain. Companies spend between 20% and 33% of their implementation costs every year on maintaining the systems (Forrester Research). Customisation increases ownership costs, as the applications become more difficult to upgrade.

Once installed ERP systems become quite rigid and are very difficult to change - "It's like concrete," says Julie Smith David, an associate professor of information systems at the W. P. Carey School of Business, "Pour it out, and you can form it to any shape you want. Once it settles, getting it into a different shape is almost impossible."

ERP systems are powerful but don’t deliver the flexibility and agility needed for true competitive advantage