Executive Briefings

Should Your ERP Vendor Be Your SOA Vendor?

There is no "right" service-oriented architecture (SOA) technology for every company. Some will be served best by their ERP vendors and others by independent vendors. The answer is in your company's business strategy, rather than the functionality of today's products.
When customers began investing in technology to build out their service-oriented architectures, application vendors were not players in the market. Companies had to buy SOA technology from independent infrastructure vendors like Cape Clear, BEA, IBM, IONA, Progress Software, TIBCO, and webMethods. But since those days, the SOA landscape has changed dramatically. Oracle, SAP, and Microsoft are now counted as among the worlds top SOA vendors. Other ERP vendors like Epicor, Infor, Lawson, and Workday have built or partnered to offer their own SOA products as well.

So, which direction should companies take today? Should they continue to invest in their current SOA technology, or move to what's offered by their primary ERP providers?

Before anything is decided, companies should look less at the technical merits of today's products and more at their business strategies when choosing their SOA technology partners:

1. Companies pursuing a One Company business strategy will see the most benefit in consolidating their SOA investments with their ERP vendors.
2. Diversified companies will find independent SOA vendors a better fit.
3. Companies with more SOA experience validate that the services architecture you create is more important than the technology used to create it.

Companies pursing a One Company vision are some of the heaviest investors in ERP software and are best served by SOA technology from ERP vendors. For these companies, ERP is the software foundation on which common data, processes, and metrics are built, enabling them to standardize and unify core operations. Service-oriented architecture plays a supporting role by linking independent applications to the ERP core and exposing reusable software services to extend ERP applications to support custom processes.

An ERP suite can replace hundreds of independent applications when fully implemented, but most companies still need hundreds of additional applications in order to function optimally. Furthermore, most companies are far from fully implemented--even those with plans to consolidate on a single, global ERP platform. Service-oriented architecture helps companies move to common processes, despite the patchwork of applications in place, by integrating applications together and to the ERP core. New composite applications can also be layered across the patchwork to support new processes unique to the business.

Common processes can also be exposed as reusable software services to ensure they are used throughout the organization. As common processes (sourcing, for example) are standardized and supported in the ERP system, they can be used by all parts of the organization by exposing the edges of the sourcing process as SOA services.

ERP vendor products offer major opportunity. SOA technology from any vendor can be used to enable these benefits, but the SOA products of ERP vendors have some significant advantages.

The Trojan horse: The first advantage is that customers already have, or will soon have, their ERP vendor's SOA technology running in their data centers. Vendors are building SOA technology into the newer versions of their applications so that when customers upgrade, their SOA technology gets around the normal infrastructure selection process and becomes a part of the standard infrastructure--a bit like the Greek warriors in the Trojan Horse.

ERP customers have no choice. Once they upgrade to a current version, they have to learn to support and use their ERP vendor's SOA technology. Over time, all Infor, Microsoft, Oracle, SAP, and Workday application customers will become their SOA customers as well. This makes the ERP vendor an incumbent vendor--one with good connections to the ERP system.

Having the SOA software installed and the skills in house, ERP customers ask, "Why not make my ERP SOA technology my standard SOA technology?" Companies like Arrow Electronics and Schneider Logistics did just that and now use SOA technology from Oracle as their standard SOA infrastructure. Many SAP and Microsoft customers have also already come to the same conclusion. As more customers upgrade, more will ask the same question.

Guaranteed compatibility: The second advantage ERP vendors have is they can deliver application services, technology frameworks, and other SOA content that are guaranteed to be compatible with their ERP suites. Future releases of ERP and SOA software can be unified to ensure compatibility and simplify upgrades. A unified management tool can be offered to simplify administration and operations. The burden of maintaining integrations falls, at least partly, on the ERP vendor, which helps reduce customer cost, time, and risk. Other vendors cannot provide such guarantees.

While this compatibility is more a future than a current feature of ERP vendor service-oriented architectures, it's a compelling vision for ERP customers. It's "one throat to choke," extended as far as it can go.

For Pfizer, Oracle's Application Integration Architecture (AIA) provides a standards-based way to integrate Oracle and non-Oracle applications to the ERP core. The SAP Enterprise Service Repository's tight integration with NetWeaver offers much of the same benefit to its customers. For companies looking for SOA to assist their One Company strategies by extending the reach of their ERP rollouts, using their ERP vendor SOA technology offers a compelling set of advantages.

Business diversity favors neutral SOA vendors: Not everyone is looking to increase reliance on their ERP vendors. Using SOA technology from an independent vendor has compelling advantages as well, especially for companies that encourage independence among business units.

All companies can benefit from having some number of common processes and a minimum of different software vendors. Even decentralized companies can benefit from standardizing on a single SOA vendor and its technology. But decentralized companies tend to have more unique businesses, processes, and applications than those pursuing a One Company strategy. For these companies, their integration and composite application needs tend to be highest within, rather than between, business units, each with its unique environment of installed software. The best SOA technology for these companies works well with all the company's applications, regardless of vendor. The more business unit independence a company maintains, the higher the value of SOA vendor neutrality.

Furthermore, the best SOA technology guarantees a degree of future application selection independence. Where business unit autonomy is considered a strength, the company will be better served by allowing the widest option of applications for future needs. The best SOA technology will support these application choices without prejudice. It will not bias future application decisions in favor of existing vendors, letting each decision be made solely on the business value an application can bring to the business unit involved instead.

For companies like Cox Communications (which uses Software AG's webMethods suite for SOA), the flexibility of working with a neutral platform vendor outweighs the negatives of adding it to the company's list of key vendors. IBM, Progress, TIBCO, and other vendors also offer neutral options, with no application agenda to advance, only a focus on making heterogeneous applications work well together.

Enterprise architecture is the bigger issue: The SOA vendor your company chooses is a big issue for your vendor. Winning the SOA technology selection processes will help it sell future applications, services, and infrastructure. While you should be mindful of this, it's not the most important issue you'll face.

While the choice of SOA technology for a project is important, it's less important than many people suspect because standards make it possible for SOA technologies to interoperate and SOA technologists to migrate between vendor technologies. The decision for one vendor's SOA technology doesn't prevent using applications from a competing vendor's enterprise applications or even, in many cases, a competing vendor's SOA technology. Many companies already use SOA technologies from multiple vendors, rather than forcing standardization. Industry standards enable interoperability between infrastructure and applications, making retraining and cross-training technology staff manageable.

The bigger issue is the architecture adopted. The value of your SOA will ultimately be in your architecture--how useful the services are to the current and future needs of your business, and how quickly you can adapt to changing business requirements--rather than the tools used to build that architecture. One experienced company warned us that businesses should expect to fail twice before they get their architectures right. While switching SOA technology providers has proven to be a minor issue for most, rebuilding the architecture and the applications that depend on it is a major undertaking.

The best way to start getting benefits from a service-oriented architecture is to start working with it. Learn what it can do for your company in small projects, and scale when you have confidence in your skills, tools, and architecture. The selection of your initial SOA vendor is neither crucial to your initial success nor irreversible, but there is no substitute for a good architecture for long-term success.

The best first step is getting first-hand SOA experience with the technology that best suits your business strategy. Those pursuing a One Company strategy should use their ERP vendor SOA offerings, starting with projects in and around the ERP core. Companies that value business and application independence over integration should look to the independent platform vendors for their SOA infrastructures. The best second step is taking the energy you saved by not fighting over your SOA vendor choice and devoting it to constructing your architecture to serve your current and future business needs.
AMR Research

There is no "right" service-oriented architecture (SOA) technology for every company. Some will be served best by their ERP vendors and others by independent vendors. The answer is in your company's business strategy, rather than the functionality of today's products.
When customers began investing in technology to build out their service-oriented architectures, application vendors were not players in the market. Companies had to buy SOA technology from independent infrastructure vendors like Cape Clear, BEA, IBM, IONA, Progress Software, TIBCO, and webMethods. But since those days, the SOA landscape has changed dramatically. Oracle, SAP, and Microsoft are now counted as among the worlds top SOA vendors. Other ERP vendors like Epicor, Infor, Lawson, and Workday have built or partnered to offer their own SOA products as well.

So, which direction should companies take today? Should they continue to invest in their current SOA technology, or move to what's offered by their primary ERP providers?

Before anything is decided, companies should look less at the technical merits of today's products and more at their business strategies when choosing their SOA technology partners:

1. Companies pursuing a One Company business strategy will see the most benefit in consolidating their SOA investments with their ERP vendors.
2. Diversified companies will find independent SOA vendors a better fit.
3. Companies with more SOA experience validate that the services architecture you create is more important than the technology used to create it.

Companies pursing a One Company vision are some of the heaviest investors in ERP software and are best served by SOA technology from ERP vendors. For these companies, ERP is the software foundation on which common data, processes, and metrics are built, enabling them to standardize and unify core operations. Service-oriented architecture plays a supporting role by linking independent applications to the ERP core and exposing reusable software services to extend ERP applications to support custom processes.

An ERP suite can replace hundreds of independent applications when fully implemented, but most companies still need hundreds of additional applications in order to function optimally. Furthermore, most companies are far from fully implemented--even those with plans to consolidate on a single, global ERP platform. Service-oriented architecture helps companies move to common processes, despite the patchwork of applications in place, by integrating applications together and to the ERP core. New composite applications can also be layered across the patchwork to support new processes unique to the business.

Common processes can also be exposed as reusable software services to ensure they are used throughout the organization. As common processes (sourcing, for example) are standardized and supported in the ERP system, they can be used by all parts of the organization by exposing the edges of the sourcing process as SOA services.

ERP vendor products offer major opportunity. SOA technology from any vendor can be used to enable these benefits, but the SOA products of ERP vendors have some significant advantages.

The Trojan horse: The first advantage is that customers already have, or will soon have, their ERP vendor's SOA technology running in their data centers. Vendors are building SOA technology into the newer versions of their applications so that when customers upgrade, their SOA technology gets around the normal infrastructure selection process and becomes a part of the standard infrastructure--a bit like the Greek warriors in the Trojan Horse.

ERP customers have no choice. Once they upgrade to a current version, they have to learn to support and use their ERP vendor's SOA technology. Over time, all Infor, Microsoft, Oracle, SAP, and Workday application customers will become their SOA customers as well. This makes the ERP vendor an incumbent vendor--one with good connections to the ERP system.

Having the SOA software installed and the skills in house, ERP customers ask, "Why not make my ERP SOA technology my standard SOA technology?" Companies like Arrow Electronics and Schneider Logistics did just that and now use SOA technology from Oracle as their standard SOA infrastructure. Many SAP and Microsoft customers have also already come to the same conclusion. As more customers upgrade, more will ask the same question.

Guaranteed compatibility: The second advantage ERP vendors have is they can deliver application services, technology frameworks, and other SOA content that are guaranteed to be compatible with their ERP suites. Future releases of ERP and SOA software can be unified to ensure compatibility and simplify upgrades. A unified management tool can be offered to simplify administration and operations. The burden of maintaining integrations falls, at least partly, on the ERP vendor, which helps reduce customer cost, time, and risk. Other vendors cannot provide such guarantees.

While this compatibility is more a future than a current feature of ERP vendor service-oriented architectures, it's a compelling vision for ERP customers. It's "one throat to choke," extended as far as it can go.

For Pfizer, Oracle's Application Integration Architecture (AIA) provides a standards-based way to integrate Oracle and non-Oracle applications to the ERP core. The SAP Enterprise Service Repository's tight integration with NetWeaver offers much of the same benefit to its customers. For companies looking for SOA to assist their One Company strategies by extending the reach of their ERP rollouts, using their ERP vendor SOA technology offers a compelling set of advantages.

Business diversity favors neutral SOA vendors: Not everyone is looking to increase reliance on their ERP vendors. Using SOA technology from an independent vendor has compelling advantages as well, especially for companies that encourage independence among business units.

All companies can benefit from having some number of common processes and a minimum of different software vendors. Even decentralized companies can benefit from standardizing on a single SOA vendor and its technology. But decentralized companies tend to have more unique businesses, processes, and applications than those pursuing a One Company strategy. For these companies, their integration and composite application needs tend to be highest within, rather than between, business units, each with its unique environment of installed software. The best SOA technology for these companies works well with all the company's applications, regardless of vendor. The more business unit independence a company maintains, the higher the value of SOA vendor neutrality.

Furthermore, the best SOA technology guarantees a degree of future application selection independence. Where business unit autonomy is considered a strength, the company will be better served by allowing the widest option of applications for future needs. The best SOA technology will support these application choices without prejudice. It will not bias future application decisions in favor of existing vendors, letting each decision be made solely on the business value an application can bring to the business unit involved instead.

For companies like Cox Communications (which uses Software AG's webMethods suite for SOA), the flexibility of working with a neutral platform vendor outweighs the negatives of adding it to the company's list of key vendors. IBM, Progress, TIBCO, and other vendors also offer neutral options, with no application agenda to advance, only a focus on making heterogeneous applications work well together.

Enterprise architecture is the bigger issue: The SOA vendor your company chooses is a big issue for your vendor. Winning the SOA technology selection processes will help it sell future applications, services, and infrastructure. While you should be mindful of this, it's not the most important issue you'll face.

While the choice of SOA technology for a project is important, it's less important than many people suspect because standards make it possible for SOA technologies to interoperate and SOA technologists to migrate between vendor technologies. The decision for one vendor's SOA technology doesn't prevent using applications from a competing vendor's enterprise applications or even, in many cases, a competing vendor's SOA technology. Many companies already use SOA technologies from multiple vendors, rather than forcing standardization. Industry standards enable interoperability between infrastructure and applications, making retraining and cross-training technology staff manageable.

The bigger issue is the architecture adopted. The value of your SOA will ultimately be in your architecture--how useful the services are to the current and future needs of your business, and how quickly you can adapt to changing business requirements--rather than the tools used to build that architecture. One experienced company warned us that businesses should expect to fail twice before they get their architectures right. While switching SOA technology providers has proven to be a minor issue for most, rebuilding the architecture and the applications that depend on it is a major undertaking.

The best way to start getting benefits from a service-oriented architecture is to start working with it. Learn what it can do for your company in small projects, and scale when you have confidence in your skills, tools, and architecture. The selection of your initial SOA vendor is neither crucial to your initial success nor irreversible, but there is no substitute for a good architecture for long-term success.

The best first step is getting first-hand SOA experience with the technology that best suits your business strategy. Those pursuing a One Company strategy should use their ERP vendor SOA offerings, starting with projects in and around the ERP core. Companies that value business and application independence over integration should look to the independent platform vendors for their SOA infrastructures. The best second step is taking the energy you saved by not fighting over your SOA vendor choice and devoting it to constructing your architecture to serve your current and future business needs.
AMR Research