If you run legacy systems and you’d like to service-enable them, how do you know which processes to work on?
NetManage Inc is a 15-year-old company that is originally known for the Rumba AS/400 screen scraper, and more recently, a family of OnWeb products that repurpose this older technology for web services enablement. It’s now taking a similar approach by introducing a new planning tool to help you figure out what screen flows should get converted.
The tool, SOA Planner, sits on a network switch and sniffs packets. In essence, it looks at how users are interacting with the back end system. By sitting on a switch rather than on the client machine, users won’t notice that their actions are being monitored. And by sitting on network node rather than back end server, you don’t impact the host machine or tie up data center staff.
The result is that sessions are pieced together, and through various aggregation and analysis tools, common patterns of interaction can be identified.
Although it uses similar parsing techniques as OnWeb, which identifies, not only the screen UI elements, but correlates them with back end transactions, SOA Planner is used differently. For instance, OnWeb is used when you have an idea of which screen flows to service enable. By contrast, SOA Planner is intended for when you’re either not sure or don’t yet have a clue.
(There’s another difference: OnWeb sits on the appserver, while SOA Planner lies off on the network.)
As the company unveiled a tool, it has tried pitching this as part of a larger 4-step process governing the web service enabling of legacy transactions. It starts with, naturally, Plan, for which this new product is directed. Once you’ve identified the transactions to bundle into a service, you then build, using the existing OnWeb tools. SOA Planner includes a feature that allows you to choose the bundle of transactions and send instructions off to OnWeb which builds the service.
The back end of the life cycle includes an evolve step, where the service is modified during the life cycle, and scale, where you could redeploy the service form an appserver or middle tier piece onto the legacy box, which of course has the power.
While the outline of a lifecycle is admirable, it’s currently half-baked. The company offers tools for plan and build, but as yet has no answers for the critical change management piece, which becomes critical once you start building services in volume. To avoid reinventing the wheel, it would probably make sense to expand its existing IBM partnership to encompass some of the Rational and Tivoli offerings that could help it flesh out a more complete legacy service life cycle product.