Java Reference
In-Depth Information
▪ N = Number of times each user was projected to perform that use case in the next five
years.
That gave something like the following equation: R = (T * .6) * W * N * U.
Everything gets rather more slippery in an SOA environment. Let's examine why now.
ROI in SOA
While SOA as a concept has been around for a number of years, it remains relatively new
as a widespread practice. Determining a long-term ROI therefore has little precedent. But re-
membering what the goals of SOA are in the first place can help you establish some clear
guidelines for ROI.
Primary business drivers for SOA are agility and flexibility. But these concepts are too general
to be monetized and must be unpacked in operational terms. Because the advantages inherent
in the idea of software reuse are well understood through their roots in traditional software
projects and components, reuse makes a good starting point.
There are different kinds of reuse that SOA affords, however. In “application modernization,”
SOA architects and developers find meaningful ways to service-enable legacy code. There are
millions upon millions of lines of COBOL code in operation in the business world. These ap-
plications may be viewed as dinosaurs, and developers and business users alike might love
to replace them with slick new applications. But these legacy applications are frequently the
foundation of the enterprise, and represent decades of stability, testing, and proven ability in
the field. Rather than ripping and replacing, SOA seeks to leverage these significant invest-
ments by wrapping them with modern web services that can increase the agility and respons-
iveness of the enterprise. At the same time, there is a diminishing return on any system as it
becomes more costly to contrive ways to manipulate and adapt these older applications nat-
ively into use within a modern application. SOA recognizes the benefit of tried-and-true ap-
plications in the enterprise, and attempts to walk this line by extending established value once
compositions enter the picture. Which is where the next aspect of reuse enters the picture:
after a service catalog is established.
Reusing existing services from a variety of clients through orchestrations and automated busi-
ness processes makes a compelling cost benefit. Once your enterprise is service-enabled, the
ability to quickly deploy new products on new platforms that build on the existing infrastruc-
ture can be quite valuable. The “network effect” (wherein the value grows exponentially as
the number of nodes on the network increases) really blossoms at this point.
But it also seems clear that SOA as an integrative technology is going to be more expensive
up front. Developers need education, the organization needs infrastructure to support it, and
it can take some time to get used to and really learn to leverage the depth and breadth of the
