Integrating System i or mainframe systems with the rest of the IT infrastructure has always been a big task. Companies have invested huge amounts of time and resources in maintaining legacy applications over years and even decades. However, IT has been constantly challenged to get real-time information to business users in the form of reports or Web browser interfaces. Legacy applications play a big role, and new demands arise as business imperatives change. But the term "legacy" itself has a negative connotation. With the demands to adopt newer Web-based technologies, organizations have been debating over whether or not to "rip and replace" legacy applications in order to modernize the IT infrastructure.
First of all, our legacy applications will be part of our SOA solution, since they are not going away any time soon. These mission-critical applications are the backbone of the business. So when it comes to modernizing IT and adhering to SOA, rip and replace is not the right answer.
I consulted with a company that scrapped the System i application with a vision of replacing it with a faster, more robust, more manageable new technology. We never even got a chance to find out whether the new system performed better, cost less in the long run, or proved to be more manageable. The implementation failed, and the director in charge was fired. The company went back to its so-called "old" workhorse, the System i, after losing time to market the product and scratching their heads wondering what had gone wrong.
Rip and replace projects are costly and prone to failure. However, legacy applications do have some limitations. They are often disconnected from the enterprise, and they house silos of data that are difficult to integrate with other silos. Keeping them always involves tradeoffs.
Leverage Existing Assets
For years, IT has debated what the best modernization path is because such a project has a big impact on the entire infrastructure. The impact involves not only applications, but also business processes, staff, and intellectual property. IT developers have been building and refining applications for years. They are intimately familiar with the business process the system supports. The business users are also well aware of these applications. They know why the applications work the way they do.
To modernize IT systems in a way that evolves rather than revolts, consider the less costly and less risky "retain and extend" approach. By retaining and extending the capability and productivity of our legacy applications, we capitalize on longstanding strengths: reliability, security, and performance. "Retain and extend" is the commitment to not only maintain the past and present, but also propel us into the future.
However, we must never forget that legacy applications are often written in monolithic fashion, and some have been around for decades. Can these applications be exposed easily using Web services with a little point-and-click tooling? Or will the applications require significant reengineering before they can truly take part in the dynamic, federated, on-demand future of SOA? The answer to both may be "yes."
The monolithic nature of older legacy applications was in part due to the design philosophy (e.g., user interface), the business logic, and the data access logic—all of which are contained in or built into the same program. This makes it virtually impossible to reuse portions of these applications or to integrate them into other applications. In some instances, companies included several different interfaces (Web, Java, green-screen), different data sources and data access layers, business logic contained in different modules and integrated process flow. Applications are even more monolithic when they are contained within organizational silos. Interaction with other silos has to happen via messaging layer or file-transfer mechanisms.
The initial approach would be to map out where one system begins and another ends. You need to make the boundaries between silos manageable. You must identify where obscurity happens and then develop elemental services to form the new basis of composite applications. You need to make these services available to existing legacy applications, allowing slow transition of reusable components. At the same time, you revisit your monolithic approach of coding and progressively move toward more loosely coupled, reusable components that can be easily aggregated and integrated to deliver new services. Some basic elemental services remain distinct, and these services will form the basis of the new "composite" application.
The next approach is to create these services as Web services. Programs (or service programs/procedures) written in ILE RPG reside in the System i for example, and a Java wrapper (i.e., SOA adapter) is created to invoke the RPG program. The resulting service is created as a WSDL. You should leverage the appropriate host integration tool (IBM WebSphere, BEA WebLogic, or Microsoft .NET) so you can quickly abstract what was once a monolithic, terminal-based application into a set of services. The result is enhanced customer satisfaction, reduced cost with better internal efficiencies, and a rapid development platform in place for ongoing projects.
Decoupling Legacy Applications
Developing reusable components is good, but these components become limited when tightly bound into an application.
Partitioning applications improves code reuse, simplifies maintenance, and makes it easier to mix and match technologies. This allows you to leverage developer resources more effectively because developers can work on different parts of a large project. Developing flexible application architecture is the goal, but leveraging the architecture to provide new user interfaces is an important secondary goal.
To accomplish this, you must decouple business logic from user interfaces within the current application, making it possible to modify user interfaces without affecting business logic and vice versa. Lay the groundwork so that you can later rebuild the user interface (e.g., JSP now, JavaServer Faces technology later). By decoupling the user interface, you can also accommodate a variety of user interfaces (e.g., BlackBerry and PDA to full browser).
The Model-View-Controller (MVC) framework is becoming widely embraced for System i SOA architecture. MVC separates the application into three functional parts: the model (or business) function, the view (or user interface), and the controller that handles the communication between the model and view.
As you review your existing legacy application, it is important to keep the MVC approach in mind. It's tempting to couple the controller and model together too tightly. For example, consider a healthcare application to do claims adjudication. To maintain the separation between the controller and the model, you could have the controller launch a comprehensive "claims validation" in the model, rather than invoke the "get claims information" function directly. The claims validation model handles the task of getting the claims information as well as verifying all the header and detail information for the claim.
Because MVC uncouples the view from the controller and model, you can theoretically create the view using any technology you choose. This stage can gradually center on a browser-based view written in JSP, for example. JavaBeans can be embedded in the JSP. By using servlets and JavaBeans, you can easily assign a code component to a single task, which simplifies maintenance and creates opportunity for code reuse. You can easily support different user interfaces for the same application. For example, a claims application may support a JSP interface for internal claims adjusters, a portlet interface for external providers, and a batch interface that accepts XML claims transactions using MQ.
You may need to invest in training to support that effort because, for many System i developers, writing GUI components is a new skill. For example, for MVC applications to succeed, a developer with Web design and JSP (or ASP) skills will create the view; a developer with RPG skills may write the model, and a developer with Java (or.NET) skills will write the controller and deploy the application.
SOA: No Longer "Same Old Approach"
The IT legacy approach has been following a path to achieve short-term goals. This only perpetuates the long-term issue of having to decouple more legacy applications. To champion your legacy assets, you must vastly improve them by utilizing SOA methodology and tools:
- Extract business rules from existing source code or new applications.
- Architect applications with a goal of developing the implementation into building blocks from reusable components.
- Manage internally reusable components for later use within System i applications.
- Manage enterprise-reusable components into a collection of SOA-based services.
The impact on the legacy approach can be greatly reduced and your applications modernized by understanding and exercising the SOA methodology now.
Alex Nubla works as the Enterprise Architect for Health Net. He used to write technical articles for Powerbuilder magazine, Midrange Computing magazine, and iSeries News magazine (even way back in News 3/x days). Alex lives in Southern California now, after relocating from Charlotte, North Carolina, where he worked for Bank of America as the V.P. in charge of technical support for System i.
Alex hasn't written articles for the past nine years because of the high demand on his consulting work. However, he has written numerous utilities and always makes them available for free in the System i community.
Alex has always been a great supporter of the System i. He has butted heads with other industry folks who refer to the System i as old technology. He says, "I don't want to be portrayed as an old bigot who loves System i, but the truth is System i is here to stay. And please, don't call it a legacy system."
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online