What experience does OpenLegacy have in modernizing and integrating legacy applications?

The OpenLegacy team has decades of experience in legacy modernization and integration. Throughout our careers we have been involved in both software development of legacy modernization software as well as helping enterprises implement these solutions. We have lived the pains of developing and deploying solutions that are proprietary and/or solve only some of the legacy modernization challenges. These experiences inspired the creation of OpenLegacy. Our mission is simple, to be THE de facto standard for legacy modernization and integration that is quick, easy, and has no barriers to use the software. 

What is the easiest way for me to update or expose my legacy application to the new “on demand” world?

Many legacy modernization solutions, while appealing in theory, take too long to implement. Others are so invasive to the application that they require a huge set of stakeholders and approvals to move forward.

We recommend finding a solution that minimizes the impact to existing systems and lessens the expertise required to expose those critical backend processes.

The ideal solution combines a non-invasive standard with a full development environment with drag-and-drop tools, so that you get rapid to market results.

The “on demand” world is not going away, and is constantly changing, so the ability to deliver quickly, adapt, and stay current with technology trends is paramount for long-term success.

What are my options for modernizing my legacy systems?

There are five primary options for modernizing your legacy systems:

  1. Application Rewrite/Reengineer
  2. Application Re-Host
  3. Application Migration/Conversion
  4. Application Replacement
  5. Application Re-facing

Application Rewrite: “Fraught with peril.” This option takes the most time and usually costs the most money. Because of the duration of these projects, which begins with analysis and design, followed by the incorporation of new market demands and the need to put other initiatives on hold, these projects often get cancelled mid-way through the originally planned timeline.

Application Re-Hosting: This is a sound strategy if the only objective in your legacy modernization plan is to reduce costs (e.g. get off the mainframe). The end result of this type of project is that you spend time and money to save some money, but your end users see no difference. There is no improvement to user efficiency, business processes, addressing new markets, etc.

Application Migration/Conversion: This approach grew up through the Y2K analysis and parsing tool solutions. It is an effective approach if your primary purpose is to retain your original programming investment. This approach analyzes the code base and database structures, then, through an iterative approach, generates new code in the target language (COBOL, C#, Java, etc.). Some of the downsides to this approach are the re-training and hiring of new skills, testing requirements, and the reality that at the end of the project, the flow and efficiency of your new target application has not changed.

Application Replacement: This approach involves the trials and tribulations of purchasing a vendor “solution” and then customizing the package’s capabilities to fit your unique business requirements. At the same time, you must try to incorporate decades of past information stored in legacy application into the new package.

Application Re-facing: If your user community complains about navigating multiple menus and screens to perform a business task, or they are required to repeatedly sign on to different applications to enter or retrieve related information, re-facing your legacy systems with a new user interface may produce some significant benefits.

If it’s done right, you could end up with cheerful, efficient users that can access the same information in the same applications as today with a completely revamped interface. But make sure you keep track of changes to the legacy environment, because this text-based screen scraping will produce incorrect results if everything is not exactly where or how it should be.

What is the difference between SOA and API?

Conceptually, SOA (service oriented architecture) and API (application programming interface) based IT infrastructures accomplish similar end-goals: creating an IT architecture that abstracts consumers of services from the applications and technology that deliver the service. In either case, IT’s focus subtly shifts from delivering technology and letting the business figure out how to use it (SOA), to working with the business to deliver a series of services that are then combined to accomplish an objective (API).

SOA presumes that an IT department carefully manages and curates access to the services it delivers, striving to deliver limited and carefully controlled services. SOA mirrors integration efforts of years past, where access was created on an as-needed basis, and generally only between trusted and well-known partners.

This contrasts with APIs, which offer more of an “if you build it, they will come” philosophy of creating relatively open services, and allowing users and others within IT to figure out how to derive value from them. APIs mirror the development that occurs on the public internet, where everyone from payment processors to the postal service provides open APIs, and allows developers to access and use them.

Is a detailed legacy application assessment process needed before engaging in an OpenLegacy project?

The non-intrusive or non-invasive solution approach of OpenLegacy does not need a comprehensive assessment and documentation of the legacy application that needs to be exposed to the “on demand” world. A complete application assessment process can be long and the need to complete one is a big hindrance in achieving desired time to market objectives.

Who are your “go to” integrators to implement these solutions?

We have a growing list of partners who are experts in legacy modernization. As a part of our partner program we provide initial and ongoing training. In addition our partners are an active in the OpenLegacy community and participate in contributions to the software platform. Visit our partner webpage for more information about our partners.

How do you interact with Microsoft or IBM in building new applications?

We are active members in both the IBM Accelerator Program and the Microsoft Platform Alliance. We hold regular briefing sessions with them and when needed, utilize their respective facilities to test our solution enhancements.

Why are companies looking to modernize their applications?

Based on our experience the reasons companies modernize their applications are:

  • To satisfy the “on demand” needs of today’s consumers,
  • To expand to new and emerging markets,
  • And to be competitive against new enterprises that do not have a legacy footprint.
What will be the impact of OpenLegacy on my end users, productivity, efficiency, relearning, etc.?

With OpenLegacy, you will be able to provide your end-users with an improved experience by providing access to systems through web or mobile devices within weeks. From an internal perspective, the time and resources needed to develop and deploy the solution are much less than other solutions. For your end users, they will have an improved experience in addition to information and new services they did not have available previously. Examples of what you can expect can be found in our case studies.

What strategy should I use to modernize my legacy system?

While the execution of a modernization strategy will be different for every enterprise, we recommend you include the following into your strategy:

Leave the backend system alone. Your legacy systems are highly reliable and contain your critical business processes that have been refined over the years.

Focus on meeting the needs of mobile, web, and cloud access.   For most, the reason to modernize is to support the demands of your customers for web, mobile and cloud access to your legacy systems.

Shift to a more lightweight, open standards programming language that leverages APIs to communicate directly with legacy systems

Not only is this strategy faster and less expensive it will also be more successful. The areas of risk are minimized, and you can be up and running in a very short period of time, without committing to anything.

Why not leave my backend systems as-is and do nothing?

There is a high cost to the “Do Nothing” strategy.

Deciding not to modernize is a strategic corporate decision that will cause organizations to become unresponsive to customer needs. Ultimately, this will make it difficult to compete in the marketplace.

The problem will only get worse as the technology gap between where you are and where you need to be gets wider. This can cause a painful, expensive, and uncertain future.

Maintaining your current legacy systems can divert up to 80% of your IT budget and staff resources—an expense that grows incrementally each year.

Modernizing applications delivers greater performance with lower cost and risk, which positions your organization for innovation and growth.

What benefits are there to using OpenLegacy instead of other traditional legacy modernization approaches?

An application is broken into the following integrated parts:

  • Screen Logic Processing: What is the end user doing, how are they doing it, and how do we help them make sure they do it correctly?
  • Application Business Logic: Are the business rules embedded within the program logic? How do we add a customer, does that customer have credit with us, where do we ship items, where do we invoice, and how do we make sure that the data we have is synchronized with our other systems?
  • Data: How do we get to the data, what are the rules about adding and deleting the data, and who is allowed to look at the data?

Legacy systems are the definition of a closed universe. They are extremely effective at what they do, they ensure business rule integrity, and they maintain data and access security. But it takes a lot of time and money if you want to have them talk to another system, expose parts of the system to a smartphone or tablet, or allow some cloud access.

OpenLegacy allows to you to leverage your investment in your legacy application. We don’t mandate that you change, rewrite your system, or buy something new. Our solution listens and learns from your application environment from the screens, programs, and database.

You can use our automated API generation tool to extend your application. It is a standards-based, open source solution meant to improve your business footprint, your market accessibility, and end-user efficiency. It is absolutely non-intrusive to your critical back-end applications environment.

What does a typical OpenLegacy project look like?

A typical OpenLegacy modernization project follows these 5 simple steps:

  1.  Identify a legacy process & target: This may include a mobile device, 3rd party application (such as CRM, ERP, MRP, vendor/supplier access, etc.)
  2.  Automatically capture, parse & analyze: OpenLegacy’s workbench auto-generates a powerful API from your legacy business process
  3.  Enhance API and app: Enhance the API and customize the resulting rich application with maps, graphics, and new functionality
  4.  Verify & test: Speed your time to market with OpenLegacy’s built-in verification and testing tools
  5.  Deploy application: Access from mobile devices, cloud applications, ESB/Orchestration, and in-house applications. The sky is the limit!
How long does a typical OpenLegacy project take?

You can bring new life to your AS/400 and mainframe applications by extending them to the web, mobile and cloud in a matter of days. The majority of our customers are able to deploy solutions within a very short period of time. Due to or our non-invasive approach, automated generation of APIs and apps, and built in testing and verification, valuable development time is greatly reduced. Every project depends on your specific environment and needs. See our case studies for examples of what you can expect.

What is the impact of an OpenLegacy project to my systems of record?

The Openlegacy microservices-based API Integration platform is built on the principle of being absolutely non-invasive to the backend Legacy application. We do not believe replacing, rewriting, re-engineering, or re-hosting a proven and secure back end environment defines legacy modernization. The solution has proven itself to seamlessly analyze all three basic layers of your legacy applications (Screen Interaction, Programs and Data), to generate API’s that that can then be deployed and used for web, mobile, and cloud applications.

What is iPaaS?

iPaaS (integration Platform as a Service) is a development platform for building integration applications. It provides a set of services and capabilities for integrating applications in the cloud and within the enterprise. The core tenants of iPaaS are the same as PaaS, except the services on the platform are geared towards integration.

In addition to some base expectations, such as multi-tenancy, elasticity, and reliability, there is a list of core capabilities that you can expect from iPaaS:

  •  Intermediation: integrate application and services.
  • Orchestration: service composition, connectivity and ability to map data between services.
  • Service Container: ability to publish services using REST, SOAP or SOA technologies.
  • Security: authentication and authorization of access.
  • Enterprise Data Gateway: secure channels to access on premise back end system through a gateway.
  • Developer Tooling: ability to develop and enhance the services without impacting the enterprise’s development processes.
  • Runtime Monitoring: tracking response times, user limits, traffic boundaries and throughput through high watermarks alerts.
Will the Open Legacy tool cater to older versions of RPG using PLIST as entry parameters?

OpenLegacy works with many type of meta-data including PLIST for RPG.

If there are multi-country sites, will we need to replicate an API for every country?

We have done such a use case for a tier-1 bank. Only the interface SDK needs to be generated (automatically) for the different countries, the API logic implementation can be the same one for all SDKs.

One to one mapping of COBOL programs to POJOs is clear. What about inter program interaction between MF programs? How do those get handled?

We do not intervene in the program-to-program communication of COBOL, it runs as is. If multiple COBOL programs need to be orchestrated from the outside, it is done using their respective SDKs.

What is your view on legacy modernization and co-existence?

OpenLegacy is not a modernization tool but we support modernization efforts in two ways:

  •  By allowing continuous service and the ability to provide valuable new functionality through the migration project
  •  By decoupling the architecture into microservices with legacy access as their data-store which later can be replaced to any other data-store or core system in a gradual manner. This is called phased migration.
How to take it forward when the database is migrated? Can we connect with migrated java code?

OpenLegacy creates standard Java projects with a firm separation of concerns, changing the back-end once it has been replaced is as easy as changing a dependency library SDK.

What about other items like batch jobs, schedulers, business rules and other entities that need to be moved outside?

These need to be assessed on a case by case, OpenLegacy will not migrate any of these but might leverage and deliver APIs for them in relevant cases.

How does the Open Legacy platform manage a fail-over in the back-end system?

Fail-overs are managed by standard microservices mechanisms such as circuit-breakers, specific handling can be added to templates.

Does the OpenLegacy support customization/integration with any of the open source frameworks?

OpenLegacy is based on open standards and supports many open-source frameworks. Additional ones can easily be introduced as normal Java dependencies.

Does the OpenLegacy have a in-built mechanism for data validations?

OpenLegacy provides support for many types of data validations using the graphical editor, including spring expressions. More complex validation can be added as code - in the API or as a template for many APIs.

Does OpenLegacy auto generate any automated test cases to test the migrated services?

Yes, OpenLegacy automatically generates test modules for every API generated.

Is OpenLegacy built with any frameworks/patterns?

OpenLegacy is built with the SpringBoot framework and uses Maven.

Does OpenLegacy provide any in-built security mechanism for data during transformations?

OpenLegacy provides built-in authentication and access-control based on Spring Security.

How is the security managed since it’s a middleware product? Any standard followed?

Security is based on the Spring Security standard and is managed through the management console.

Is there any impact to back component change assuming I/O parameters are not changed in linkage section?

Backend programs need to be callable with parameters to be used by OpenLegacy, whether it is in the linkage section or a different method of invoking (IMS messages etc.). There is a separation between parameters parsing, done in design time and program invocation, done in run-time.

Is OpenLegacy compatible with databases outside of the mainframe?

OpenLegacy supports and JDBC compliant database, including stored procedures.

Do you offer support for PL/I, Natural/Adabas, and Assembler routines in an IBM Mainframe?

All can be supported.

During implementation, do we need any support from our data migration team?

OpenLegacy accesses data and programs on the legacy side, so usually no data migration is needed.

Is there any impact to DB2 or IMS or COBOL version changes to this interface?  Any such incidents in the past?

Access to DB2 and IMS/DB is done via JDBC drivers, IMS/DC via IMS connect, as long as these are supported versions don't have an impact.

Are OpenLegacy services extendable via message brokers like MQ?

Yes, OpenLegacy can support MQ both as a backend and as a consumer and can be implemented as a component in an MQ based SOA architecture if needed.