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
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 Salesforce.com 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
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.