Can SOA pick up where ERP leaves off?

Can SOA pick up where ERP leaves off?

Summary: Construction management company finds multiple ERP systems aren't enough; turns to SOA


Last month, I ran a piece that generated a lot of discussion, quoting Bruce Richardson's prediction that SOA would usurp many of the functions that now sit at the application level in ERP systems

Sometimes, ERP may seem like too much, but other times, believe it or not, it's not enough. Recently, I had the chance to talk with Rich Colton, application integration manager with Washington Group International, who has spent a good part of his career around ERP systems.  (A summary of the interview and Washington's SOA effort is posted over at my blog at ebizQ, which presents SOA success stories.)

The interesting thing about the SOA effort at Washington Group -- a construction management company -- is that there really wasn't a single ERP system that could handle the firm's wide range of projects and needs. The company does everything from building dams and bridges to demilitarizing weapons stockpiles. Washington has an array of legacy systems and silos resulting from mergers, and even the big systems such as SAP and Oracle had all the capabilities that were needed.

"We have not found an ERP system that meets the engineering/construction industry's requirements," Colton says. "Several have tried, including both Oracle and SAP. We found they really didn't offer the kinds of products that we need in different areas, such as project management, project controls, estimating, or materials management. We ended up having to use the best of breed in different areas. Up until now, it's required a lot of duplication, triplication, and more, of information from one system to another."

The only effective solution was to abstract a lot of the various functions into a common service layer, built mainly with Java EE running in Oracle Fusion middleware.  However, while Colton believes that SOA can augment ERP, he doesn't see it as a replacement for ERP. In fact, companies with enterprise ERP deployments may not need SOA. "I have a long history of managing and maintaining manufacturing systems," he points out. "I think there are some very good ERP systems for some companies that will never really need SOA capabilities. By and large, their ERP system is meeting their needs."

But, he adds, some complex operations will need SOA to bring diverse environments together, he adds. "There certainly are companies that have different kinds of requirements in terms of their manufacturing environments, and no single ERP system is going to manage them across the breadth of their markets."

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Less system is still better


    SOA will not take over ERP. SOA just make integration much easy and affordable.
  • We do not need SOA, ERP, ....

    I have managed ERP for three years now. I can tell you it does not fit well with our business processes, and it never will. Neither does any other system I have reviewed (I have reviewed many, many other systems). To say I am frustrated with the whole situation is an understatement. So what do I think we really need?

    SOA is not the answer. Perpetually adding more and more middleware is not the answer either. At some point it becomes basically unmanageable and the data becomes suspect after triplication etc..

    We really need a company to step up and create something which focuses on users abilities to create, alter, simplify, and effectively manage their business processes. Can software ever be created which does this? Not yet. Hopefully it will be available in the future.

    Until then we will all spend just as much time dorking with our current ERP, SOA, or whatever and trying to keep good data and information in it as we do getting real work done.

    I have seen from experience that ERP causes as many problems as it solves for most businesses.

    The only industries I have seen which seem to have really benefited from ERP are those which mass manufacture a small amount of items and whose processes rarely change.

    Most businesses are not setup this way. Most places experience change in their business process model weekly, if not daily in a constant effort to stay ahead of the competition. Changes happen often, and the ERP model simply cannot account for this.

    So, IMHO ERP is simply bloatware, and SOA is bloatware stacked upon bloatware. Show me something which allows a company to (change, improve, and alter their business processes fast, effectively, and accurately) and I will be sold.
    • ERPs and SOA

      IMHO SOA is the concept for virtualization of functionality. The concept includes web services as an enabler, governance for organisation, composition for processes management, policies for trust, and managability for operation.

      I've read about how well SAP NetWeaver fits into the SOA world. I think NetWeaver is an example of a SOA Ready application (possible to be virtualized) but not a Full SOA application following the concepts of SOA. The application boundaries are static and not dynamic, based on policies.
    • ERPs inflexibility

      One might expect ERP to more flexible than it actually is.

      All major ERP packages are based on SQL-DBMSs. One of the central principles of the relational model (on which SQL-DBMSs are somewhat based) is that data is represented in a non-application specific manner.

      In addition all validation and consistency checks should be in the database itself. This means that users and programmers shouldn't have to worry about entering data that corrupts the consistency of the data.

      In practice all ERPs have almost all the validation and consistency checking in their applications, thus throwing away some of the key flexibility advantages of having the SQL-DBMS sitting behind them.

      It should be fairly clear that SOA, web-services or "component based architectures" are only going to make this situation even worse rather than resulting in any improvement.

      Currently programming languages are very poorly integrated with RDBMSs, they make only minimal use of the metadata in the DBMS and generally making a change to the database involves hunting through a lot of code to make the code conform with the database. If the RDBMS and programming languages were better integrated this would cease to be a problem. Once you stop thinking about the "tables" in an RDBMS as being something analogous to files and start thinking about them correctly - as variables - then this integration becomes much simpler.

      Programming languages that are more closely integrated with the DBMS will I think give greater flexibility but this isn't the whole story. The DBMS has to change too. In particular to incorporate key parts of the relational model that current products largely lack - view updateability and closure for example.
  • What is needed is better ERP abstraction