SOA: A Life-Line for the iSeries?

by Mary Lou Roberts

Unfortunately, there are not a lot of new OS/400 application development efforts underway, either among OS/400 shops or third party software developers. Efforts to get iSeries shops to "modernize" their applications have generally been translated as "move to WebSphere and Java," and only recently has IBM acknowledged that OS/400 shops have not been stampeding to follow that directive. As a result, the iSeries Development Roadmap has recently opened up to include lots of tools and, as importantly, supporting the idea that a good many iSeries users (read RPG die-hards) intend to stay lean and mean with their existing applications that work just fine, thank you very much.

However, business needs are driving companies to "webify" their applications--and increasingly that means more than just putting pretty front ends on the core legacy systems. It means forging true integration with other applications, both internal to and external to the company. If you want to be a player in the supply chain, you're going to have to get on the team. And that means integration.

That's where service-oriented architecture (SOA) comes in. Much has been written about SOA, a self-described "architecture" that might more accurately be called a methodology. It is, in short, the definition of reusable components (known as "services"), each of which contains application logic to perform a specific business function: "insert purchase order" or "validate credit rating," for example. Such services may access different systems/databases on different platforms transparently.

A recent white paper issued by Butler Group, an IT research and advisory organization, states: "What this means from a business perspective is that each application needs to be understood from the point of view of what services it provides to the organization. Applications then need to be 'deconstructed' into their component services--each of which performs a specific business function."

The word "deconstruct" sends shivers up and down the spine of many an English major who has struggled with Derrida's enigmatic philosophy. (After several decades and a master's degree, I still don't get it.) According to the Merriam Webster dictionary, deconstruction is "a method of literary criticism that assumes language refers only to itself rather than to an extratextual reality, that asserts multiple conflicting interpretations of a text, and that bases such interpretations on the philosophical, political, or social implications of the use of language in the text rather than on the author's intention." Huh?

Rather than deconstructing our applications from the bottom up, as Butler suggests, SOA really demands that we construct the business processes we want to apply to service the needs of the business from the top-down and then reconstruct the applications not by rewriting all of our code, but by integrating these processes into a framework that encompasses our existing applications. This integration is done regardless of location or platform.

That's the goal of SOA, and the touted benefits are numerous: greater flexibility and agility in responding to changing business needs; decreased implementation costs through reusability; reduced complexity of development; increased leverage of IT assets; platform independence; reduction in complexity; and more.

Sounds good, right? But what's the relevance for iSeries shops? For one thing, fewer and fewer of them are truly "islands" any more. They exist side by side with other platforms in enterprises (albeit they are often host to the legacy business applications--those boring but critical systems that do the heavy lifting of the core business). And, as Eduardo Ross, vice president of research and development for ASNA, notes, "The theoretical island doesn't exist any more. Even if a company only has an iSeries, it still isn't really an 'island' any more. The moment you connect that iSeries to the Web, you are no longer an island. You need to connect to personal computers, other systems, and other business partners somehow. The time when the AS/400 was truly isolated, back in the early 1990s, is long gone."

Jake Frievald, director of marketing for iWay (a subsidiary of Information Builders, bolsters this argument: "There's not a lot of new development on the iSeries. But a lot of companies that have an iSeries have to fit within a larger environment. If you like your iSeries, the key issue is not about new development. It's about extracting value from what you have. Working toward SOA is a good way to do that."

In fact, the philosophy behind SOA isn't really new. Ross points out, "On the iSeries, SOA has been a good practice since the days of the System/38, where you would pass parameters to another system through a call."

What is new, however, is the emphasis on Web services--often the driver to implement SOA in today's more complex world. In fact, some people equate SOA with web services and use the two terms almost interchangeably.

Paul Koenig, marketing and development consultant for Versata, acknowledges that there is a lot of confusion between SOA and web services. But, he asserts, "It's not correct to use these interchangeably. Web services is a special case of SOA, with standard protocols."

Frievald agrees: "SOA and Web services are absolutely not interchangeable. The minute you equate the two you are in trouble. You can create nasty spaghetti-based integration without Web services, and you can create a SOA without Web services. SOA is an architecture to create functionality and make it available across applications. First, you have to carve out services into a composite application. Second, you have to expose it to Web services."

By defining these business processes and services, "composite applications" can be built, delivering new application functionality based on existing applications, says David Holmes, executive vice president of marketing for Jacada. "This creates a new view for the user through a new user interface with an application that typically touches more than one system. If you've done the job properly," he says, "You haven't really created another application--you've added another layer of logic."

Ian Goldsmith, vice president of product marketing for SOA Software, (who, by the way, does use the terms SOA and web services interchangeably), describes the trend in yet another way: "Instead of looking at just putting a front-end on their applications for humans to browse, companies are now building SOAs so that other systems can browse them."

The path to SOA can be fraught with pitfalls--the largest one of which is the definition of the business services themselves.

"The biggest issue is that the services that people want to expose tend to be way too low-level-just a recasting of something in the application," says Koenig. "What you really want to get to is business function--that is, 'query a customer'--not database function--that is, search by name or search by address. 'Add a customer' is a business service. With that, you can tie together the applications that allow you to make that happen. Tell me what you need done; don't tell me how to do it."

Frievald expands on that idea: "You don't want to think about 'insert purchase order into my JDE application' or 'insert purchase order into my Siebel application.' You want to think about 'insert purchase order' without affecting the back-end applications. Expose the lowest level transactions and then put them into a single business process at the highest possible level."

Who best to do this definition? Ross says that many companies have created a new title for this job: architect. "But it's usually the programmer who is really defining at a higher level," says Ross. "Once the interface design is done, some people in iSeries shops are often challenged to implement it because most of them are RPG programmers, and that's not the language of Web services."

iSeries shops may have an advantage here since in the typical shop many of the IT folks are also highly knowledgeable in business process--more so than in larger, more "advanced" environments. On the other hand, they should caution against being locked into a particular way to thinking because of their long-term association with a specific way of doing things. Further, Ross points out that the typical iSeries development environment doesn't natively support the generation or consumption of Web services when they have to communicate with other systems.

Fortunately for many iSeries shops, there are many tools now available to automate the move to SOA and Web services--and more and more are being announced as time goes by. Holmes cautions, "Composite applications will typically be built with Java or .NET. I don't recommend doing it yourself if you have only RPG skills in-house. But you can contract it out. Jacada, for example, can come in and build the composite application, and maintenance of it is not that significant."

As might be expected, iSeries shops, while interested in the potential of SOA, are not all rushing to feed from the trough. Ross reports that some of ASNA's iSeries customers are feeling the fire to communicate with other companies using Web services rather than paper and telephone calls. On the other hand, "Other iSeries shops are struggling just to get beyond the green screen. They still don't have the power to connect with others."

Holmes reports, "Philosophically, iSeries shops do want to get there. But the world is now all about Java and .NET development, even though RPG is still the best business development language. Small iSeries shops have a hard time accepting this--especially those that are package-dependent."

But the vendors all report signs of iSeries community movement in the SOA direction. Goldsmith notes, "iSeries shops tend to be less leading-edge than other organizations, but they are starting to move. There are advantages to being a technology laggard. Organizations that have not yet webified their applications by building pretty front-ends for humans are realizing that that's not the way to go. Now they can skip that step and go straight to the second stage: building SOAs so that other systems can view them. SOA is the technology that's going to keep them employed and keep the iSeries as a player in the enterprise."

There may be a bit of hyperbole in the assertion that SOA will be the savior of the iSeries, but these vendors are banking a lot on the belief that SOA is not just today's new buzz word, but rather an architecture/methodology that will gain increasing acceptance. "Don't believe the hype yet, and don't confuse SOA with Web services," Frievald cautions. "But do take what you have and make it reusable so that people can leverage and get value from it."

Holmes sums up the iSeries perspective: "iSeries shops have awesome business functionality and the most stable platform on the planet. They need to find a way to leverage this with composite applications."

Mary Lou Roberts, a 35-year veteran of the information systems industry, is a new contributor to IT Jungle. In addition to her work as a reporter in the iSeries space, she has spent her career as a marketing and communications professional working exclusively with information technology publications and companies. She can be reached at WriterNewf@aol.com.