I have seen IT-proclaimed silver bullets come and go, and so am skeptical about claims of newfound breakthroughs. But service-oriented architecture (SOA) seems to be something that can deliver on its promise. I have hopes for SOA because it just might deliver to IT what mass customization has delivered to manufacturing.
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.
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.
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.
 |
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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?
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.
Niel Nickolaisen is CIO and vice president of strategic planning at Headwaters Inc. in South Jordan, Utah. Write to him at nnick@headwaters.com or editor@searchcio-midmarket.com.
