Cutting Through the Hype: Where Web Services and SOA Are Really Working
By Louis Columbus
Summary
The move by database developers to include object-oriented programming languages has changed the scope of application development and is acting as a catalyst for Web Services development. Being able to define stored-procedures in object-oriented languages is leading to an entirely new approach to creating workflows and supporting transactions in manufacturing and services industries. Despite the availability of object-oriented programming languages however, many systems still rely on file server architecture, two-tier, or n-tier architectures. Web Services, many internally developed, show what object-oriented programming tools can deliver.
For many manufacturers this starts with tying together supply chains with more than the equivalent of hand-built adapters that cannot scale across all the transactions a manufacturer needs them to. Many manufacturers are holding onto their hand-built adapter strategies to integration, just as Web Services are starting to prove themselves. The bottom line however is the Web Services work for integration today – yet are still unproven for completely replacing ERP systems that include complex distributed order management, supply chain synchronization and customer fulfillment.
What’s Really Happening In Web Services Today
Forget about the commercials and hype showing Web Services as an all-knowing and all-seeing platform that can tell any salesperson at any time, from anywhere the status of orders in a remote location of Europe for example – just the infrastructure investment to support this level of responsiveness would dwarf the entire IT budgets of many Fortune 1,000 companies.
The reality is that there is much more crawl-walk-run and testing going on than global best practices at mobilizing a single system of record for example. In the research completed for this article and in the multiple manufacturers spoken with, there’s more of a focus on test-driving Web Services today than en masse development.
Several companies spoken with are concerned more with security than time and cost efficiency savings; the fact that according to AMR Research there is less than $100,000 spent on pilot projects underscores the fact that Web Services gets used more for integrating databases together and less for transactions outside an enterprise. Despite the hype surrounding Web Services as the Next Big Thing, it’s clear from watching the adoption of companies using this approach to managing database integration that it takes on average 2 years to make Web Services fully operational, specifically including five Web Services or more.
Additional insights into the true adoption of Web Services are provided here:
- 75% of all Web Services projects are purpose-built for database and data warehouse integration projects.
- 65% are developed to support integration to legacy or mainframe applications.
- 60% are developed for internal portal integration efforts with legacy and typically three or less databases internal to the company.
- One manufacturer of complex pumps and valves focused on headcount reductions equally $500K the first year only to find that the two engineers that were going to be let go were actually needed for integration work for the Web Service aimed at streamlining complex order capture. The net result: the Web Service worked and another Application Server engineer needed to be added to the product.
- One manufacturer of computer equipment uses Web Services to integrate their order capture and pricing systems that are part of their SAP ERP instance – and the result is the ability to publish out price updates to worldwide channels within 48 hours. The Web Service will also add Oracle pricing integration – yet that will be over a year away and require months of internal development.
ROI for Web Services Is Still Elusive
Of the manufacturers who are using Web Services, ROI is proving elusive to quantify much less track over time. Because of the majority of companies developing Web Services do not do ROI analysis before starting development they often have high expectations that are often not met.
Because of the majority of Web Services adopters not defining ROI targets, the majority rely on headcount reductions for show ROI. This is clearly a cop-out because cost reductions and greater efficiencies taken together should deliver gains in revenue either directly as the result of serving customers more responsively or streamlining workflows.
Second to headcount reductions, companies are looking at reduction of the costs of integration, data entry, and reduction of Value-Added Network costs as the approaches to show positive ROI for internal Web Services developments.
Service-Oriented Architectures By Any Other Name
According to the vendor community today, their collective vision says that a grouping of Web Services actually creates a Services Oriented Architecture (SOA). Despite the fact that the concept of an SOA is met more with criticism and doubt than Web Services, it’s becoming clear that Web Services as a database integration platform are starting to pay off. That sets the stage of an SOA platform for the early adopters. The disparity however between the best practices and clarity of the EAI vendors including BEA, Siebel and platform vendors including SAP NetWeaver are portraying and the actual results of companies adopting SOA strategies is narrowing.
Especially in services industries there is a strong focus on creating five or more Web Services to streamline integration points in financial reporting and human resources applications. The fact is many IT organizations have an SOA and do not really know it. Abandoning the concept of using hand-built connectors and adapters for more scalable platform has delivered SOA years ahead of the hype.
Databases that have programming extensions for HTML, HTTP and XML extensions have been added to these company’s platforms and today they are serving as the foundation of an SOA. Put aside the hype of SOA and start looking at your existing databases to bring in programming extensions and access points for web-based development languages. Manufacturers who have relied on ODBC either as a transport mechanism or for the basis of their adapter development, it’s critical to remember that the convergence of object oriented programming languages to include C# and J2EE is making the storing of objects – not just data – the heart of what it takes to move into Web Services that matter.
Where SOA Is Working
Just forget about the hype of SOA and see it as a platform for ensuring integration with the many systems that are toggled together with hand-build adapters and connectors that don’t scale. The IT organizations getting the best results today are doing the following:
1. Take order management trouble spots and apply integration to streamline these workflows. Web Services show the highest ROI when applied to transaction workflows – and thanks to the development of more object oriented programming tools – databases can handle this.
2. Look at how to use Web Services to create an order state engine. Being able to track an orders’ state at any point in time makes more sense as a Web Service, especially if an organization relies extensively on precise delivery dates or high levels of customization in product designs.
3. Web Services starts with time savings not headcount reductions. The fact that so many early developers on Web Services are relying on headcount reductions to provide a positive ROI is a misnomer; better to trim time from any order management process over simply automating an internal function. Making order management and transactions the center of Web Services development shows ROI.
4. Security concerns addressed. The ACID-compliance test of any Web Service is the managing of a stream of transactions. It’s not enough anymore to simply tie together content and present it in a portal; that is Web Services 101. The true test of Web Services is in automating order management and transactions.
Summary
To a large extent database architectures are additive. Don’t however let the hype surrounding Web Services or even Service-Oriented Architectures (SOA) make the concept of fixing order management for example turn into an internal project – as many projects originally defined as Web Services turn out. Use the problem areas of order management as the basis for testing Web Services development in your own organization.
Posted by LOUISCOLUMBUS on August 2, 2005 at 11:30 AM in Business Infrastructure | Permalink
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/t/trackback/407529/2933965
Listed below are links to weblogs that reference Cutting Through the Hype: Where Web Services and SOA Are Really Working:
