This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Service-Oriented Architecture, Part ll: Leveraging The Legacy
Expensive, dysfunctional integration stymies efforts to gain full value from generations of investment in application systems. By supporting end-to-end business processes, a service-oriented architecture (SOA) promises to bridge foreign software lands.
Expensive and dysfunctional integration stymies businesses that want to gain full value from generations of investment in application systems. By supporting a vision of end-to-end business processes, service-oriented architecture promises to be the blueprint for bridging foreign software lands. The second part of our series offers a practical exploration.
Service-oriented architecture (SOA) facilitates the creation of end-to-end business processes using loosely coupled software parts and standards, enabling businesses to profit from their investment in a generation of IT systems, application logic, and user interfaces. In Part I of this article, I focused on integration, one of the five key SOA components. I now turn to two more: synthesized computing and abstract service taxonomy. To get a handle on how vendors are implementing SOA principles, I will examine key aspects of Tibco's and SAP's product architectures.
With the rise of XML, stringing applications together is not only possible, it's expected. Standard, XML-centric middleware offers a common way to describe data and protocols at an application level unencumbered by lower-level details. Applications can no longer be islands where mere portions of business processes are automated; rather, enterprise and collaborative business applications must comprise a collection of services that function in tandem to automate whole business processes. The SOA benefits here are threefold: standardized connectivity, the ability to build greater connectivity into applications, and a new architecture that lets application vendors reorient their packages around connectivity to improve participation in end-to-end business processes.
A typical business process spans multiple enterprise (ERP, CRM, and legacy), productivity (Microsoft Excel and Word), and collaborative (e-mail, portal, phone, and fax) systems. Almost all business processes require all three types of systems. Orders that go on a "credit hold" commonly require email messages and phone calls between sales, accounting, and customer service to determine whether to extend credit. Finance fills in spreadsheets to tally and characterize orders it's overriding. Credit-hold calculations require data and processes across ERP and CRM systems. The fact that Customer 10 cannot order a specific product is just as relevant in Excel as it is in SAP R/3.
It may be hard to conceptualize the true value of combining disconnected, "siloed" subprocesses — both automated and manual — into end-to-end business processes. After all, in many cases the result doesn't automate anything; the XML-based foundation simply provides coordination for end-to-end processes and accessible repositories. Think, however, of an order-entry system: The fact that orders, customers, and inventory are tracked by the system obviates many manual activities, even if the orders themselves must still be entered manually. Similar efficiencies are possible for most business processes when you tie together a range of manually performed tasks, including inserting reminders in calendars, completing forms, making phone calls, sending faxes, creating manual logs, and sending out (countless) emails, that someone must perform to fulfill a complete business process.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.