It’s my belief that well implemented SOA eliminates the need for any enterprise to deploy an ERP system. If you already have an ERP system, then a well implemented SOA will begin to break the vendor’s shackles.

What is an ERP system?

According to Wikipedia:

The initials ERP originated as an extension of MRP (material requirements planning; later manufacturing resource planning) and CIM (Computer Integrated Manufacturing). It was introduced by research and analysis firm Gartner in 1990. ERP systems now attempt to cover all core functions of an enterprise, regardless of the organization’s business or charter. These systems can now be found in non-manufacturing businesses, non-profit organizations and governments.

In fact, today ERP systems cut across most business domains and try (and in my opinion fail) to be all things to all people. ERP systems typically include modules such as, Manufacturing, Supply Chain Management, Financials, Human Resource Management, Customer Relationship Management and others.

ERP is sometimes referred to as EAS (Enterprise Application Suite) a new name used when the system covers almost all segments of business.

Integrated – but often poorly

Most ERP systems have evolved from a collection of applications, acquired over time by the incumbent vendor as they sought to broaden their reach and strengthen their stranglehold on their clients. Selling this mismatched collection of applications as a single system required that the various pieces be integrated.

Historically this was done via a mishmash of integration technologies. Mostly, integration tended to be point-to-point between applications. As more “modules” were added, so the spider’s web of integration became more tangled.

Mediocre collections of domain specific applications

Even where vendors have taken a centralized approach to integration and used an ESB or Broker, one core problem remains.

The applications in the suite tend to be a collection of mediocrity, at least from the perspective of functional fit, if not overall quality. Many people in our industry are familiar with typical ERP system implementation. These tend to be 3+ year long projects involving multiple external (partner) consultants, costing many millions, and seldom, if ever, meeting the client’s expectations.

I believe the reason that ERP implementations often fail to live up to expectations is rooted in the fact that each individual module fits only some of the business needs of the client. Large organizations tend to have evolved their own idiosyncrasies within each area, and when new packaged software is introduced to perform core functions two things happen.

1. The package is modified (customized) to fit their needs;
2. The business is forced to change to fit the software.

Neither of these is desirable, but both tend to happen. Historically the degree of customization and the impact of organizational change are greater than what was anticipated (or promised).

The effect of this when multiple modules are introduced is cumulative and cuts across the entire organization, impacting negatively on every domain that must interact with the affected business units. This cost is seldom understood, and normally grossly underestimated. (I suspect that the vendors careful avoid this.)

These cumulative requirements mismatches lead to massive time and cost overruns and result in customizations that make the system much more difficult to upgrade. Effectively, once an organization starts down this road, they are locked in to the ERP vendor. Often they end up facing the stark choice: Force fit their business to the ERP system, or die in customization hell!

What are the key points that ERP systems attempt to address? In my opinion, the most important selling points are:

1. Applications are well integrated;
2. Business Processes across business domains are easy because “it’s all one system”;
3. The same skills can be applied across the business for application maintenance and support;
4. Applications within the suite are “the best there is”.

I believe that ERP systems normally fail on all these points, or at least, fall well short of the vendor’s claims, especially on the final point. The fact is that there is no “one-size-fits-all” solution in any particular domain. The chances of having multiple applications fit your business well are therefore even more unlikely.

How can SOA fix this?

A well implemented Service Oriented Architecture should have some, if not all of the following characteristics:

1. Core business functions are exposed as reusable services;
2. Cross domain processes are supported and implemented;
3. Existing domain specific applications are left unchanged, serving their users as they did before, but also supporting the enterprise through exposed functionality;
4. New domain specific applications can be added with little or no impact on the existing business processes; new processes can be introduced that leverage, but do not alter, existing processes.

In this scenario, we are able to leverage our existing applications in each domain, no need to force change by replacing them until we need to.

We can source “best-of-breed”, or more accurately, “best-of-need” (best fit to our needs) and integrate this into our business and processes with minimal knock-on effect. In fact, we could conceivably run the old and the new side-by-side, gradually phasing out the old system.

In addition, our integrated environment is designed to accommodate disparate systems so adding (or continuing to use) types of systems that are not provided by the ERP vendor, integrated into our business processes, is expected and normal.

SOA implementation is (should be) gradual

Any significant change to operational systems within an enterprise can be painful. Smart implementations of SOA introduce the changes gradually. Once the core infrastructure is in place, gradually service enabling individual applications can begin.

New business processes and improved processes can be implemented one at a time, driving the service enablement process as needed. SOA governance can be introduced gradually and subtly. Through this approach, we are able to keep that which is good about our existing systems, and slowly improve on that which is not so good.

We can sweat our digital assets longer and harder, whilst acquiring new ones and introducing them gently.

SOA eliminates vendor lock-in

One of the negative impacts of ERP systems is that as a business, you end up with a very large part of your existence being dependant on a single systems supplier. This has got to be uncomfortable. At first it may be ok, but the vendor may choose to develop their suite of applications along lines that are not good for your business.

Since the ERP vendors make extensive use of consultants (their own and partners), all your core business IP ends up in the public domain and sooner or later, ends up as new features in the vendor’s products that all your competitors can benefit from. Non-disclosure agreements are extremely difficult to enforce, and probably would not be enforceable in the majority of situations.

ERP systems tend to level the playing field by reducing or eliminating systems derived competitive advantage. SOA enables total flexibility and enables business agility where ERP systems tend to constrain business agility due to the cost and time required to make changes.

SOA will change the ERP game

Many ERP vendors claim to be embracing SOA (and some actually are), but for those merely paying lip service, I predict a bleak future. If the ERP vendors embrace SOA fully, we will begin to see a different ERP landscape.

Should this happen, ERP vendors will end up with application suites where the individual applications (or modules) are fully service enabled. This benefits them directly since it makes integration within their suite simpler and more effective. It also benefits their customers, since it breaks down integration barriers and enables them to choose the best applications from across multiple vendors and integrate them into their SOA.

This effectively breaks the vendor lock-in shackles and should lead to a much more competitive landscape where “one-size-fits-all” is a non-starter. If clients have the capability to mix and match, vendors will need to improve their overall value proposition and especially the TCO (total cost of ownership) of their systems.

Some (if not all) ERP systems will (and already do) ship with an ESB in the box, and most of the tools needed to support a SOA. In fact, when they embrace SOA themselves, this is a natural side-effect. The impact of this is that, they themselves are helping to implement SOA, and in so doing, opening the door to their own competition! Should be an interesting ride…

My advice, if you’re interested. Don’t start down the ERP path, rather look to SOA. If you have already started and you do not have a SOA, get your SOA in place anyway. It will enable far greater flexibility and business agility and allow you greater freedom of choice when new ERP “modules” need to be added.