Who needs ERP when you have SOA?

Posted 8 September 2009 By Nigel Bakker and has no comments yet - click to add.

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.

Categories: The Business Case for SOA

Perspectives – SOA vs SOAD

Posted 2 September 2009 By Nigel Bakker and has 1 comment - click to add.

There is a growing trend amongst the developers I work with to take a “service oriented” view of what they are doing. They frequently refer to their efforts as being SOA development. I find this quite disturbing, since they are not actually engaged in SOA.

SOA, like many terms and acronyms in the world of software and computing is heavily overloaded. I thought I’d offer a few perspectives on SOA in an attempt to clarify the differences.

Let’s start by expanding the term SOA as Service Oriented Architecture. It could also be expanded as Service Oriented Applications, but I find this overload to be confusing. For the purposes of this discussion, SOA refers to Service Oriented Architecture.

Scope

First off, there is the question of scope. SOA is intended as an Enterprise Architecture approach. By definition this means that it recognises the existence of all applications and business domains. It is primarily concerned with enabling business processes across these applications and / or domains.

When using service orientation as an approach to application design, an approach I prefer to call Service Oriented Application Design (SOAD), we are generally confining ourselves to a single application, and by implication, the single business domain for which the application is intended. Obviously, some applications do cross business domain boundaries, but the fact remains that the focus is very much at the application scope.

When we apply SOA design principles at an application scope we tend to make tradeoffs that favour the application scope more than the enterprise scope. In his seminal work, SOA: Principles of Service Design, Thomas Erl classifies services in models. These models map (loosely) to layers and form a natural hierarchy. The names he uses are Task Services, Entity Services and Utility Services. Task services encapsulate business process logic. Sometimes these services cut across business domains and applications. This type of task service is often implemented using some form of orchestration technology (such as BEPL). These orchestrated task services, a.k.a. parent business process services or parent task services span application domains, and are squarely in our sights from a SOA perspective.

Service Orientation as an application design approach

If our focus is at the application level and we are applying SOA design principles, then surely we are “doing” SOA? The problem I have with this is that when using the term SOA in this context we are dragging in a bunch of enterprise architecture concepts that may not be appropriate.

Service Orientation at the application level is not new (Inversion of Control frameworks such as Spring tend to be service oriented), only today there are other, more powerful technologies (such as WCF) that make service oriented application development much simpler and more mainstream.

But is this SOA? In my view not directly – purely because the scope is at the level of the application. It does however make it much easier for a business to leverage the functionality of an application when we implement business processes that include its domain. SOAD is a means to service enable new applications from the ground up. This tends to make them first class citizens in a SOA, as opposed to typical legacy applications that may require significant effort to service enable.

Service Orientation as a business process enablement approach

In an enterprise where you have service enabled applications, it becomes common practice to begin leveraging those applications in more complex, cross domain business processes. Several things drive this, including replacing point-to-point integration, eliminating manual recapture of data and of course, supporting new or improved business processes.

At this level we are clearly in the domain of inter-application (or inter-domain) business processes, being processes that cut across more than one area of the business. This is also the domain of EA and therefore of SOA.

When working at this level, we would typically be using business process modelling to define our processes, followed by implementation of the automated sections of the process via some form of orchestration such as BPEL. This tends to result in composite services which use BPEL to implement some or all of their service logic.

Interestingly, these cross domain services tend to be less time sensitive than services within a particular application domain. In order to promote service loose coupling, these services are often implemented as business event sinks, consuming these events as subscribers, and publishing events in their own right where required.

Synchronicity

One of the observations I have made is that the lower down the hierarchy of services one goes, the more likely it is that the service is consumed in a synchronous fashion. Business task services are often not that time sensitive, since typically they involve some form of processing in response to a business event.

For example, if a customer calls into your call centre to update their address, the most likely situation is that the CRM system will be used to capture the changes. The actual process of updating the details is confined within the domain of the CRM application. Once the update is complete, this becomes a business event which other domains may care about. The billing system for example, probably cares about contact details, since it needs to be sure that the bills are sent to the right place. For this to happen, the billing application needs to be told about the change. Does this need to happen while the client is on the phone with our call centre agent? Probably not. We could simply publish the event, and let all interested applications consume and process the event at their leisure.

Within the CRM application itself, things are a little different. Assuming we have implemented CRM using a service oriented design, there would likely be an entity service responsible for managing customer data. When the agent hits the “ok” button on the screen, it’s important that he or she gets feedback immediately confirming that the update has in fact been applied. This update would need to be immediate, and clearly synchronous calls are better suited to this level of usage.

This asynchronous / synchronous differentiation has a profound effect on our overall application design, and is therefore one of the factors that influences the way in which we apply service orientation at the level of the application.

Service Oriented Application Design definitely supports and contributes to a Service Oriented Architecture, but purely on the basis of a too narrow scope, is not itself SOA. This being the case, let’s use the term SOA where it actually applies and call what we do at the application level by a different name… say SOAD?

Categories: Technical SOA