Wayne Kernochan, senior analyst for Illuminata, is a long-established expert and thought leader in development solutions and information management. He has closely followed the System i segment, and contributes regularly to articles in the System i press. Throughout his twenty-five year career as an engineer, analyst, and author, Wayne has focused on software development, databases, Enterprise Information Integration (EII), infrastructure software/middleware, and mainframe-class deployments. He has been a strong advocate of holistic information management, agile programming, composite applications for linking business processes, and the strategic use of EII. At Illuminata, Wayne supports the company's Application Strategies practice. iLink Digest recently talked to Wayne about Web integration on System i. iLink Digest recently talked to Wayne about Web integration on System i.
iLink Digest: Many people have noted that the System i community has been slow to Web face their applications and even slower to achieve full Web integration. Is that your experience?
Wayne Kernochan: I've seen some indications that the situation may look far worse than it really is. But it is true that there's a lot more work to be done and that the System i community has not fully accepted the tools it has been given to accomplish Web integration.
iLD: What is it about these tools that the market didn't accept? Is it simply a matter of RPG and Java being too complex?
WK: Java is not the best tool for putting a Web interface inside a major RPG application. If it's simply a matter of slapping a Web browser in front of an RPG app, Java can be pretty complex for a task that is really pretty straightforward. But the real problems with acceptance have been culture shock and the fact that there has been no real immediate demand perceived by senior management for applying these Web-facing tools to System i apps, even though they might present an opportunity.
iLD: Given the fact that these System i applications tend to be central to the heart of the business, why wasn't there a stronger perceived need?
WK: Until recently, System i users were not getting the message from the overall business in which they are embedded that they really needed a strong interface. Coordinating System i apps with the applications from the rest of the organization and from customers and suppliers via the Web was not high enough on the company's priority list. Other folks were off doing development on the core competitive advantage stuff, and the main objective for the System i folks was just to keep those business applications running. They weren't necessarily looking to extend those applications to a broad class of new users. But that is changing.
iLD: What is happening now that's changing that?
WK: The whole SOA [service oriented architecture] initiative that IT organizations are experiencing is a key component of many companies’ strategies over the next few years. What seems to be happening is that many organizations are now looking at what will give them the most value add with the least risk when they implement SOA—and that means “Web-servicizing” key applications like the System i ones.
iLD: How will SOA impact the development effort?
WK: It turns out that SOA does not make building applications any easier. In fact, if anything, it makes it harder. But what SOA does do is to leverage the value of existing applications like System i applications. When you bring that application under SOA, the first thing you do is to "web-servicize" the existing application, meaning that you carefully define the interfaces by which other applications call them, according to a de-facto Web-services standard. If people want to get the biggest bang for the buck with SOA, they will often look to web-servicize existing System i applications, and all of a sudden, that has put the System i applications much higher on the priority list.
iLD: And that is where the competitive advantage will come from?
WK: Yes, but the meaning of competitive advantage has changed a bit. Competitive advantage now comes from doing your business processes more effectively, not just having better products—and SOA helps you do that. Pre-SOA, a System i application was not necessarily a customer-facing application or a competitive-advantage application; it just “keeps the business running.” With SOA, the System i applications almost inevitably have an impact on doing your business better—for example, by creating a composite application that combines the key business processes that System i apps represent, more effectively. That, in turn, typically means not only putting a Web browser in front of the System i application but also creating a specific application programming interface in front of the application that allows you to treat it as a Web service. That's a significant programming task, and one that the organization really wants.
iLD: Will the System i community begin to move forward with SOA and Web interfaces?
WK: In the long run, it's inevitable. But the speed with which they will accomplish it really depends on the tools given to them. They should not get hung up on the language. RPG is nice not just because everybody's used to it, but because it's more efficient for the typical System i application. But we're talking about a task—providing a browser interface and Web service code—that RPG won’t do and that if you were doing pure Java you would have to laboriously hand code. A tool like Magic’s—a visual programming environment— takes care of that for you. The key is not the language, but the fact that the tool is a higher-level abstraction, much as RPG “abstracts” via a decision tree. It's abstract compared to your normal, low-level programming language. So, what we're really talking about when we say “you could use Magic on top of Java” is substituting one abstraction for another. At the abstract level, i5/OS doesn't care.
iLD: You predict, then, that we will see true integration of System i applications with the rest of the enterprise?
WK: Yes. In the end, users will web-servicize the RPG applications and those systems will be able to talk outside and System i and even outside the organization. They have to. If you're an ISV and you don't, you're in danger from newer, Web-based solutions. If you're in IT in an end user shop, you can't ignore a corporate imperative. Things will start flowing outside you and eventually you have no more turf left. In the short term, you can put a gun to the head of the corporation and say, "I'm your expert; you have to keep me." But eventually, more and more people will stop using you. It's death by a gradual crumbling away of your usage.
iLD: Will people now start looking at development platforms instead of development tools?
WK: Yes. This started taking place about five years ago. The name of the game is no longer writing code in a specific language. The question now is whether or not you have components—preferably high-level business components—that will make that job of writing the code that much easier. In many cases, instead of writing the code yourself, you just invoke the components. A lot of those components have to do with allowing the application to run no matter where. That is often where WebSphere comes in. WebSphere not only provides a way of interconnecting applications across the platforms, it's also providing a set of programming tools so that if I write on top of WebSphere, my application will run anywhere.
iLD: This approach, then, will benefit the organization in terms of agility and cost?
WK: In the TCO/ROI [total cost of ownership/return on investment] studies I've been performing, I've seen an interesting connection between the value add of the development platform and the value add of the deployment platform—if it’s a more rapid development platform during the development phase and therefore gets you earlier to market to gain more ROI, it also is typically a more robust platform during the deployment phase and gives you lower TCO. So a platform that gives your organization more agility to rapidly react to new needs via new apps is usually one that leads to lower-cost applications. Note that this is a platform story—not just a development tools story. Providing a Rapid Development Tool is one thing. Providing a Rapid Development Tool on a really robust platform is another. People want to do better in both development and deployment now because they understand that the two are related. The System i can play a big role in achieving these benefits.