When is the best time to turn off legacy systems once their functions are captured in the SOA middleware layer? The sooner the better, says the chief architect at BT, the UK-based telecom mega-giant.
A new report from InformationWeek's Charles Babcock notes that BT is shutting down hundreds of applications or systems each year as it moves more deeply into SOA.
The article quotes George Glass, chief architect at BT, who argues that SOA payback won't be seen until these older systems are put out to pasture. "To get cost savings, mining Web services from old applications only pays off if IT follows through and shuts down the legacy applications," the article notes. InformationWeek also ran a survey that reveals that "adding complexity and failing to get cost savings could result from companies adding new Web services without ridding themselves of old applications. Thirty-six percent of respondents didn't replace older technology with SOA."
For BT's part, it has so far shut down 205 legacy systems the first year of its SOA implementation, 710 its second year, and 260 in the first quarter of its third year.
BT's SOA focus has been on extending functionality formerly locked away in its internal systems out to business partners. Those included services such as billing or customer address checking, that could be used for BT's retail customers or for a new third-party broadband provider piggybacking on BT's network. Glass says BT "was able to identify 160 core capabilities that BT provides, each with five to 15 operations." As a result, BT has been able to cut time to market with a new service from 270 days to 90 days, says Glass.
This is a shining example of SOA going straight to the bottom line. Most SOA implementations have been able to demonstrate internal productivity savings, but BT is demonstrating that such a flexible architecture is enabling it to quickly go in new directions with its 400 business partners.
Reducing the Shut Down Risks
I believe the author of this blog entry left something ambiguous. “Mining web services” and “shutting down” appear to contradict each other, as the result of mining is something of value (a web service), which one would certainly like to keep. I suppose the author meant to imply that the user interface or the client facing part of the application could be shut down, while the pure service part is kept in place.
Given this understanding, I believe that the riskiest aspect of shutting down the application is the potential loss of some existing functionality that is still needed by the business. As an example, imagine that all screen interfaces were replaced by web services. In such a case, is it possible that the application still receives some feed from an outside source? Even for the case of the user interface, how are we sure that all data elements and user actions are being replaced and nothing is lost? Furthermore, what about the application boundaries – could it be that we shut down something that does not properly belong to this application, or is shared with another application?
The way to reduce the risk is to perform a careful and exhaustive analysis that would reveal (1) the application boundaries and (2) all application interfaces. Both these could be handled more or less automatically by a modern legacy analysis tool.
The application boundaries may be discovered by a so-called transitive closure: starting with some recognized software artifacts which clearly belong to the application (such as screens or tables), then finding all related objects (used or using the artifacts), then continuing this process until no more artifacts are found. The interfaces may be discovered by looking for all input or output operations, such as “receive or send data to a screen,” and “read, write, update, delete” against a persistent data storage.
A careful analysis can thus insure that no application input or output is left behind as the user interface is replaced by web services. Once the risk is eliminated, applications may be “shut down” at a higher pace.