The Real Niel: SOA has promise

With mass customization, we hold an inventory of a small number of standard, nearly finished products that we assemble as close to the customer as possible and as late as possible. From this inventory of standard parts, we can build a nearly infinite combination of products to meet changing customer demands. As an analogy, think of how a small set of Lego blocks can be used to create an amazing variety of "products." Imagine what we smart IT types can do with a well-designed, well-thought-out set of services that we assemble as needed, when needed.

Niel Nickolaisen

If SOA is our version of mass customization, it makes sense that we learn the lessons that manufacturers have learned when implementing mass customization. Good manufacturers learned that they needed to revise their practices before they could exploit mass customization. For us to take advantage of SOA's technical promise, I expect we will also need to clean up our methods. Fortunately, we can go to school on what manufacturers have already learned. I have found that by borrowing the 5S system from lean manufacturing principles I can improve IT performance. The five S's are:

• Sort
• Set in order
• Shine
• Standardize
• Sustain

Of these five, Sort seems to be the most important. To properly sort, we define criteria and then use the criteria in everything we do. Applied to IT and SOA, rather than transitioning our entire code base to a service, we should first define meaningful criteria and then sort our code according to the criteria. For example, we might sort based on usage or architectural standards or some combination.

More SOA resources for CIOs SOA: A Midsized Manufacturer's Framework for Growth SOA adoption check list

If we have not used some portion of our code base for several months, it might not be worth our time to SOA-ize it. Or we might think twice before we invest in wrapping our COBOL code elements as a service.

With the criteria in place, we do an initial sort to clean up what we have in inventory. I usually sort into three "piles": Things I know I need. Things I know I don't need. (I put these in a passive management category or possibly discard pile.) And things I am not sure about.

For the things I am not sure about, I put them in a holding tank. If, after a few weeks or months, something is still in the holding tank, I move it to the passive management/discard pile and get on with my life. Thus, I clean up my inventory and only invest in SOA-izing the things that deserve the effort. In addition, 5S provides collateral simplification benefits. How many of my precious IT resources are supporting systems that don't deserve a high level of attention?

Imagine what we smart IT types can do with a well-designed, well-thought-out set of services that we assemble as needed, when needed.

We cannot define the sort criteria by ourselves. We need to work closely with the business and teach it the what and why of our sort. The first time I tried to use 5S for IT, I made the mistake of sorting without first collaboratively defining the criteria. When I asked which of our current systems were essential, the answer was, "Everything." I then retraced my steps and we decided that something was "less than essential" if it had not been used in at least 18 months. As it turned out, almost 20% of those initially essential systems fell into the new category.

When we make our SOA plans, we can optimize our work if we focus our attention on the pieces of our code base that will benefit from the investment.