Service Oriented Architecture: The 'Pewter Bullet' That Creates New Value from Legacy Software

Editor's note: What are the best practices in moving data to the clouds? Learn more here!

I've been writing software for a long time.

When I was 14, I taught an HP programmable calculator to tell time by flashing hours, minutes and seconds repeatedly. It used a loop of null operations to take up the time between each second. Slight changes in room temperature would cause it to speed up or slow down the rate at which it performed these loops, ultimately making it a poor timepiece.

But I was hooked -- I have loved programming since those days. That was almost three decades ago and since then, I've been writing some kind of software almost every day or managing those who do. For the last decade, I've been running a company that creates and sells software.

In all that time, there has been a recurring theme in our industry that keeps raising its head over and over again: reusing already battle-tested software is preferable to writing new software. How can we do a better job of reusing legacy software?

Reusability -- The Holy Grail

That same wonderful HP company that got me started on this path (and is now one of my customers) put out a great book in 1992 with the obtuse title, "Practical Software Metrics for Project Management and Process Improvement." I know it sounds like a snoozer, but it's not. Although this book is more than 18 years old, it could have been written this year, because the concepts are still relevant. Among the research are these two nuggets of wisdom:

1.Projects created primarily from reused software experience only about 1/3 the defect density of those that are new.

2.Projects created primarily from reused software take about 1/4 the time and resources of those that are new.

There are many other nuggets. It's a great book.

Enter Service-Oriented Architecture (SOA) -- the next wave of reusability.

Whenever "the next big thing" is announced, CIOs are understandably skeptical. At a recent IBM SOA conference that I attended in Dallas, one CIO of a Fortune 500 firm said to me, "Is there really a standard here or is this like the OSF where all the Unix vendors bickered endlessly, producing little agreement while Microsoft chortled in the background? SAP says they have thousands of companies participating, IBM says they have 300 ISVs and thousands of 'assets' -- are they counting the same things? Are they in agreement over definitions? I don't think so."

Another queried, "Why isn't this just another layer on top of all the other layers that won't be the magic bullet either and, in the end, will also require endless maintenance?"

These are good questions. While agreement between vendors is often imperfect, Microsoft's .NET, IBM's Websphere and SAP's NetWeaver programs all agree on SOAP, XML and WSDL, and these web services technologies do enable the kind of architectures that SOA is creating.

IBM in particular is making serious headway. They have a blizzard of products to enable SOA and have bought a number of companies to add to the capabilities, like Manoj Saxena's company, Webify. Saxena -- now vice president of SOA middleware at IBM -- admits that SOA is not a silver bullet. "It's more like a pewter bullet," he says. "But it's aimed at alleviating the IT hairball we've built up over the last four or five decades in IT shops."

That phrase "IT hairball" is so wonderfully accurate and descriptive. The SOA idea is simple: componentize pieces of your legacy applications and provide a WSDL layer on top of them. You will then be able to use tools like IBM's Portlet Factory and Dashboard Framework to drag and drop services into new dashboards to create new applications.

You can pull client lists, project lists, project costs and employee data from SOA-enabled applications like Journyx Timesheet and plug them together with data from Oracle or SAP or to create new views of data and new applications based on these standardized services. Sounds easy, right?

The benefit of doing this is that you can innovate not just your products and services but even your business models. You can create new ways of selling that the IT hairball would have previously made impossible. Without destroying the value that exists in your legacy applications, you can, in fact, unleash it -- thereby getting your IT shop to be as agile as a Silicon Valley startup.

What's the Catch?

Ah yes, the catch. The myriad of applications that you're plugging together in this way may have disparate security semantics and different performance capabilities, and, of course, testing all this is a whole new ball of yarn. After all, you will have fragmented your application logic to an extreme degree with SOA. It could very easily result in finger pointing. SOA allows more direct communication to potentially vulnerable code residing on the back end. It creates a level of connectivity that was never designed for by the makers of the legacy applications it often exposes.

Perhaps your legacy application is not accustomed to the new load. From IBM or SAP's perspective, this is an opportunity to sell more hardware, more software, and many more services to get it all rolled out. SOA blurs the lines between infrastructure, applications and business processes. This could lead to an overall decrease in application manageability. IBM's answer to this will be, "buy Tivoli." See how this works? But at least they have an answer.

I frequently give speeches to IT audiences around the country and one of the questions I ask people is, "Are you looking into rolling out SOA technologies in the next 12 months?" The number of hands going up on that one has increased substantially over the last quarter or so. Gartner states that "Service-oriented architecture (SOA) will be used in part in more than 50% of new, mission-critical applications and business processes designed in 2007 and in more than 80% by 2010.
There's no doubt about it, SOA is coming soon to a theater near you.

Challenges for Project Managers

From a project management perspective, SOA presents additional risks to project success. Legacy applications mean legacy application owners and an increase in political risk. How are you going to get all these departments to work together effectively? IBM predicts that the services related to SOA over the coming years will dwarf the software and hardware purchases. So start with a very small project and demonstrate success before you implement the big-bang theory. Technical and engineering risks will be high if your organization hasn't done this before. The testing and verification portion of the project gets more difficult, as does the communications management. Certified project managers become more necessary in an SOA environment.

Any powerful new concept entails risks. The Internet poses risks of fraud, such as Google's nemesis -- pay per click fraud -- that no one could have conceived of before. SOA is powerful, and it will have some flame outs too. Proceed cautiously, but proceed. You'll get the reusability benefits for which we've all been searching.