News Stay informed about the latest enterprise technology news and product updates.

When is SOA the right road to application modernization?

To apply SOA to app modernization, you must distinguish between service orientation and service-oriented architecture, and determine if legacy code is well written enough to benefit from modernization.

Application modernization, interoperability and integration are key drivers behind many service-oriented architecture initiatives. Add in reduced total cost of ownership for all of the above. While an SOA may not be right for every organization, it can be the foundation for achieving business agility by enabling business process management and dynamic business processes.

Experts emphasize that organizations embarking on this route must distinguish between service orientation and service-oriented architecture, determine if legacy code is well written enough to benefit from modernization, and have a plan.

"Folks modernize for a number reasons; modernization is the superset," said Phil Murphy, principal analyst at Forrester Research, in Cambridge, Mass. "Sometimes small things are wrong with the application so they don't look at SOA at all.

"When these things don't talk together, or it's a monolithic application that's a beast to do anything with, then SOA presents an opportunity to break things down into smaller chunks of reusable functionality, and then rewrite," he continued.

In a SOA surveyed conducted in April by, the TechTarget Application Development Group and Forrester Research, respondents cited improved data integration as the top benefit they hoped to achieve from SOA adoption, followed by enabling legacy application integration, improving flexibility of application development, integrating disparate, departmental applications, and reducing costs.

For smaller organizations, a move to an SOA may not be necessary, according to Jason Armstrong, practice manager for strategic solutions at Pittsburgh-based Summa, and IT consulting and custom development firm. "But for most companies, if they have more than two or three systems to integrate, SOA makes a lot of sense. SOA is the stepping-stone, the foundation to bigger things.

"When you look to BPM or dynamic business processes or events, if you don't have an SOA foundation you can still do those projects," Armstrong continued, "but you're not as efficient or effective, or there's a chance you won't be successful. Especially for dynamic business processes, the idea is you can rearrange how systems are integrated through BPM on the fly. Without services you can't do that easily."

However, SOA is not always going to solve a modernization or integration problem, contends Leigh McMullen, vice president, solutions and delivery, Sogeti, a global IT consulting company headquartered in Dayton, Ohio. "If your application is well structured, it may be well suited to SOA," he said. "If it's a piece of junk, SOA has no prayer of helping."

The approach to modernization really depends on what's wrong with the application, according to Forrester's Murphy. "I see a lot of folks come loaded for bear, wanting to replace the application, when what in particular is wrong is that the UI is ugly. In a well- structured application it's perfectly acceptable to expose those pieces of work as services, and so you have a presentation layer interface. But you don't want to do that in an application that's poorly structured because it will be mess."

No service orientation without SOA

The fact is, the notion of service orientation is widespread in IT today, McMullen said, but that is distinct from the architecture itself. "Even back in the Cobol days there was some measure of service-oriented programming," he said.

What many don't realize, Forrester's Murphy said, is that back in the CICS days "folks wrote code that's not completely foreign to SOA concepts. We wrote an order-entry screen that added a customer, or we wrote a screen to check a customer's credit. In many respects, if the green screen apps were well written, they were not foreign to SOA guidelines."

Today, McMullen said, most shops are using some service-oriented programming coupled with Web services and SOAP or REST. However, he said, "I would submit every company is doing some service orientation, but most are doing it absent an architecture."

While McMullen said an SOA would benefit most organizations, "doing service orientation absent an architecture is a bad idea. While loosely coupling your applications using an ESB or something of that ilk is a great idea, ESBs can become convenient places to co-locate spaghetti code, without the right discipline."

Also, he said, from an IT management perspective, without an architecture and good governance in place, "you could wake up in 5 years without knowing where you're spending your money." Today, he said, CIOs can easily tell you the top applications they spend money on. "To disintegrate all those applications without a plan and a good SOA perspective, you won't be able to say where you're spending money. If you spend $5 million on a platform it's easy to analyze. If you spend $5 million, $10,000 at a time, maintaining a wild wild west environment of proliferated services without a plan, you're just spending a ton of money."

Some Cobol code is irreplaceable

In terms of modernizing mainframe applications via an SOA, Summa's Armstrong said the decision "comes down to how much I invested in the system, and how well written and easy it is to integrate. In a project I worked on a few years ago, the restraint was we couldn't change anything deployed on the mainframe, but we had to add new functionality. We used legacy enablement products to expose the mainframe in a service-oriented manner. With that, they were able to do more than before, but still reuse the investment in the mainframe system. Other customers want a wholesale migration off the mainframe. We're seeing a lot more Linux these days; often Redhat Enterprise Linux running on a Java stack."

Sogeti has done a lot work with banks and insurance companies, McMullen said, adding that "banks were the first to do a true SOA. There are a lot of [mainframe] banking systems wired together with MOM [message oriented middleware]; they've got pretty good abstraction and message brokers between programs. There's a lot of inspiration to be drawn from the discipline behind these large banking systems wired together with MOM. They're very compartmentalized, and the way they've grown and been managed is really where we need to be going."

There is still a lot of good Cobol code out there that is irreplaceable, McMullen said. "Going through modernization, the trick there is what can we bolt on and expose core services as services, not ripping out the gut of the mainframe."

Nothing common about common application integration

To begin a modernization and/or integration effort, "the most common thing is, there's no such thing as common," Armstrong said. "One of more common ways we see is an evolution of an existing system We rarely see rip and replace. A lot of times the organization is extending the life/investment in legacy or older technology, so it becomes a phased migration."

Summa is an IBM business partner, so often they will bring in WebSphere application server and process server, Armstrong said. "We're finding that coupling a business rules management system like ILOG is a very good value proposition for customers. One thing we see with BRMS [business rules management systems] on the horizon is that with ILOG you can have business users and analysts authoring and maintaining rules, so you can shift the cost from developers to subject matter experts. This is more efficient too, because subject matter experts know their business, rather than explaining that to the developers." For legacy enablement, Armstrong said he tends to use IBM's WebSphere Host Access Transformation Services (HATS). "You can integrate at the screen level with the system, but you can expose it from the middle tiers as a Web service."

For the move toward an SOA, McMullen recommends an architecture roadmap and a plan. "Following that, start with good service orientation, which may sound like conflicting rationale, but unless you've got a business-critical reason for doing it, typically going on a big-bang approach to SOA is a bad idea. Managing an SOA takes different techniques than monolithic platform-based architecture, and the budgeting techniques have to be different too."

From there, McMullen advises starting with small projects, "and stay simple in the way you implement the architecture and do design. Don't go full-out to service orchestration and BPM like your hair's on fire. You've got to get good at the governance and management of this environment. If you start with an overall high-level vision, and implement it in a simplistic way, you'll minimize the impact of the mistakes you almost certainly will make."

In terms of products, McMullen suggests a standards-based approach to remain somewhat platform independent, which he said also dovetails with simplicity. "If you pick an open source ESB that's not full featured, that doesn't bundle in all the whiz-bang features, it will force you to be simple in the way you use it. Go with an open source portal like JBoss vs. an Oracle or WebSphere. By forcing yourself to be more standards compliant, you can lower your investment in SOA infrastructure, with the unintended benefit of forcing yourself to not code to a specific high-end platform, which forces you to be more standards based and disciplined."

But Forrester's Murphy said to remember that SOA is not the be-all, end-all to modernization or integration/interoperability challenges. "We've got a bad habit in this industry of saying, 'This the answer; what's the question?' Certainly SOA suffered that fate, as does every new thing we introduce. It's a tool in an arsenal; we forget they're just tools. They're good in the hands of good process and design, but they can make a mess just as easily as a masterpiece."

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.