<<SOA and the invisible side-effects of refactoring In last week's post, Is your SOAP turning to SOUP?, I described some of the problems in store for SOA adopters. In particular, I asked how your organization is dealing with service change, and how it is measuring the ROI into specific services.
Surely, you may ask, these issues are old hat? We've been dealing with such questions forever. The point I am trying to make is that the ballgame is changing. Once upon a time, IT departments met the needs of the business by building custom applications and/or implementing packages. Periodically, they had to justify enhancements/upgrades to these applications/packages. And every now and then, they would decide whether or not the service provided by such software was still delivering value to the business, or whether it should be abandoned/replaced. SOA makes this process much harder. Once your monolithic software applications have vanished beneath a service layer, you can no longer conduct such analyses on each application in isolation. Rather, you have to look at a much bigger picture - one in which the inter-relationship between software components and business usage is vastly more complex. And even this is not the whole problem. There are yet deeper issues, related not simply to justifying software changes but also to implementing them. Sometimes there are dangers that are obvious neither to developers nor to the business. Let's take an example. Bear with me, since detail is necessary to illustrate a typical problem. Suppose you work for a financial services company, and your leasing application has a useful piece of code for calculating credit risk. The calculation is long and involved - best of breed, the result of years of refinement. Further, it makes use of an expensive third party subscription service for which you pay a flat annual fee (as many checks as you like during each year). Your developers observe that this code could and should be made available as a service for use by other applications, not only in the interest of maximizing benefit and cost-effectiveness but also to make such calculations consistent across the organization. So the module is refactored to expose the credit risk calculation as an independent function, and this function is then exposed as a service. After checking that in each case that the calculation is appropriate for various other applications, they are each refactored to call this service, and their own credit risk calculations scrapped. So far, all well and good. However, no-one has noticed that an interesting aspect of the leasing application's credit risk calculation. It was only ever applied at a certain stage of the leasing process. In a previous stage, the customer's address, bank account and other confirmatory details had been checked against their company name - in other words, they were who they said they were. So this check was never required as part of the credit risk calculation, and now it is not part of the service. Of course, all other applications also make such checks. However, one application in particular - for debt consolidation - did not make the check itself. It did not need to, since it implemented credit risk analysis via a call to ancient mainframe code. This mainframe code was well-written for the time - so carefully written, in fact, that before carrying out any calculations at all it would do various checks, including of company details against their address, bank account, and so on. At the time of creating the debt consolidation application, it was well-known that the mainframe application did such checks. This is why they were not included in the debt consolidation application. However, there is no longer anyone around that remembers this. In fact, the only description of these generic checks is buried deep in the original program documentation for the mainframe application as a whole - no-one saw a need to repeat the description of the checks in the documentation of each individual module. At the time of its own creation, the mainframe application was monolithic, after all. So the documentation for the credit check module of the mainframe application only mentions the credit risk calculation itself. The result of all this is that the new credit risk service appears to be a perfectly valid replacement for the legacy mainframe code. Further, the debt consolidation application was actually the last remaining user of the legacy mainframe application, so the legacy application is discontinued on switching to use of the new internal credit risk service. No-one has noticed that in the process, a baby has been thrown out with the bathwater. Credit risk calculations in the debt consolidation application are now being made on companies that may not be who they say they are. Anyone could use a company name that belongs to someone else to borrow money. This may never happen. But if it does, no-one will even notice. Until, that is, debt consolidation customers start to vanish without trace, taking your organization's money along with them. TAKE AWAY I have often seen exactly this kind of thing happen as a result of refactoring. In the simplest case, an extracted method may fail unpredictably on re-use due to lack of a null check enclosing its logic, since in the original code from which it was taken the null check was performed outside the lines selected for extraction. However, until recently the side-effects of poorly implemented refactoring have generally been limited to within a single application. Hence, such side-effects are often discovered in pre-release testing, and even if disaster hits post-release, it can be contained. However, with SOA, refactoring is no longer of components. Refactoring is now of services. Unintentional side-effects may have long-term, organization-wide consequences. It has become much harder to discover problems such as the above - and once they are discovered, it is much harder to put things to rights. So what is the solution? In fact, the clue to it is contained in the scenario description above. In future postings to this blog, I will show how to use the principles and patterns of Human Interaction Management to deal better with the extension of refactoring to an enterprise scope, along with the more general issues of impact analysis and the assessment of ROI in an SOA environment. PS On Friday I am talking at Javapolis, and will be at the conference from Tuesday evening onwards - if any readers of this blog also happen to be attending, and would like a chat, do come and find me.>> You can read Keith's blog at: http://www.ebizq.net/blogs/it_directions/archives/2006/12/soa_and_the_inv_1.php Gervas
