Nigel Bakker's SOA Soapbox

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.

As is usual in the software industry, there is an incredible amount of hype and noise around this thing called SOA – otherwise known as Service Oriented Architecture.

But business is weary and sceptical of hype, and rightly so. Over the years the IT industry (software in particular) has made many promises but very rarely do these promises get met. Why should SOA be different?

Probably the biggest thing in favour of SOA being different is the fact that SOA is not in fact a product, or even a technology! Rather it’s a mindset, or an approach to actually leveraging some of the value locked into the rat’s nest of software applications foisted on an enterprise by vendors and even their own IT department.

The first rule of succeeding with SOA when you start down the SOA road (when not if!) is do not believe the vendors. They lie. All of them! (So what’s new?). I have had many dealings with various vendors of so called SOA software products, ranging from governance tools, to ESBs (Enterprise Service Bus), and have been lied to by all of them. Oh, they believe what they are saying – which in their minds means they are not lying! But, they all over-promise and under deliver.

Don’t let my vendor rant dissuade you though, there is real value to be had in the tools and products dispensed by the various vendors. It is up to you to find the value and leverage it however.

Back to the real question though, what is the value proposition behind SOA? Haven’t we heard it all before?

Yes we have, but until now, we had not reached a point of maturity that would allow us to really exploit and realize the potential of SOA. Several things have happened, most notably the standardizations that have been driven by the rush to the web. These standardizations have not only happened, but are actually in widespread use. Finally it is genuinely possible to expose functionality from legacy systems as services. Not necessarily easy, but definitely doable for a reasonable cost.

In fact, the current recessionary climate is likely to be a boost to SOA adoption. In simple terms, businesses are looking to sweat their digital assets longer and harder, and SOA is just the approach to enable this. Rather than automatically upgrading to the next version of this or that, businesses are asking themselves the question: “Do I really need the new version? Can I use what I have differently?” Perhaps somewhat surprisingly, the answers are coming up: “No” and “Yes” respectively. The question that follows is then: “How do I use what I have better?”

Part of the answer is SOA. Not the whole answer, but certainly a significant share of the answer lies in enabling the business to leverage what they have, better. SOA provides us with a mental framework for leveraging existing assets. But, there is a caveat. SOA is NOT simple. It is NOT easy. And, most definitely, it is not a silver bullet! (Done without care it may well be a lead bullet to the CIO’s head.)

Adopting SOA is a journey, first you need to understand that it will ultimately change the way you do business. Everything you do in the business needs to be reviewed and weighed and measured to see if it can be leveraged as a service. To do this, you need to revisit all your business processes, and look for automation opportunities within each process. Start with the processes that are fundamental to your day-to-day business and expose the common elements as services. Immediately, these will become available to be used in different contexts. If done correctly, it will not only be possible, but relatively simple to combine existing services in new ways and in so doing, drive innovation in your business.

As you progress down this road, delivering new functionality increasingly becomes a matter of leveraging what you already have whilst only adding new bits to fill the gaps. At this point your business has become truelly agile, and SOA has become a way of life.

As I’ve already said though, this is not easy. Beware the salesman who says “we’ll install so-and-so ESB and SOA suite and you’ll be done!”

The fact is, you probably do need some new technology to make this magic happen, but be sure that you have a clear idea of what you need before you embark on a spending spree. SOA is still a relatively immature area in the software vendor stack. A significant amount of consolidation has happened with big vendors buying smaller vendors to get their hands on bits they don’t have. Most of these acquisitions are still being digested.

If you already have an ESB in your environment, keep it until it reaches the point of becoming a hindrance. At that point you will have a better idea of what your real needs are. Most importantly, employ the services of a vendor neutral SOA specialist to help you get started and to lay the foundation of your own approach. Only then, bring the vendors in and make them fit their tools to your vision, if they can!