An airline wants to cooperate with a credit card company's rewards program, enabling credit card rewards points to be transferred to the airline's frequent flier program. That program is managed by a mainframe‐based application.
A manufacturing firm wants to outsource their customer relationship management (CRM) software to a software‐as‐a‐service (SaaS) provider but needs to provide real‐time data from their mainframe‐based inventory and product control systems.
A retailer wants to implement a new distribution center product‐shipment system but needs to interface that system to their mainframe‐based inventory control application.
It's happening more and more: Companies in a variety of industries want to do more with their business. They don't want their mainframe system to hold them back, but they're not interested in replacing the mainframe, which in most cases does a great job of doing what it was designed to do. They just want to use that data in more places, giving themselves more business agility. In more and more of these cases, they want that mainframe data to be used in "the cloud."
It's easy to think of "the cloud" as just another overused IT marketing term. We're bombarded with cloud‐based promises almost every day. The fact, however, is that the cloud is real. Every day, thousands of companies process transactions in cloud‐based services. More and more companies are outsourcing selected applications and functionality to the cloud—CRM, business intelligence, email, collaboration, and more. The cloud is giving businesses new options and opportunities to reduce costs, reduce business distractions, and increase their flexibility and agility.
The cloud and its supporting technologies offer an unprecedented level of integration between business partners. Information can be more easily exchanged, validated, and stored. Companies no longer need to rely on slow, manual, batch data transfers conducted via physical media or scheduled FTP transfers. Instead, companies can interact in real‐time, exchanging exactly the data they want in a fast, secure fashion. An airline can show you how many frequent flier miles are available to be transferred from your credit card's rewards account, and an online dinner‐reservations service can check on the availability of a table at that hot new restaurant in town.
Cloud technologies have enabled a whole new breed of outsourced service, whether you call it SaaS or some other term. With real‐time data exchange, these services are more than just a service that you pay for and consume; they can become an integral part of your infrastructure by accessing key data from your in‐house systems—blurring the line between "cloud" and "data center" and providing the right set of services, at the right time, to your business. A cloud‐based business intelligence (BI) platform can access sales data from your internal systems, helping you to answer business questions and make smarter decisions going forward.
Cloud technologies can even make it easier to share data between your internal systems by relying on well‐understood, industry‐standard protocols for communications and data exchange. Your order‐tracking system can send shipping information to a shipmentprocessing system as well as to a credit card merchant system, speeding up and automating order processing and fulfillment. You gain greater abilities to use off‐the‐shelf systems and components as part of an integrated system—without having to custom‐integrate them.
The big problem arises when your legacy data—the data living on your mainframe— becomes involved. Mainframes have typically been big, monolithic, all‐inclusive environments. They don't always work and play well with other systems, and when they do integrate, they like to do so on their own terms. Most mainframe applications were designed well before the advent of the Internet, let alone the concepts that make up the modern cloud. Those legacy applications can hold you back.
The ultimate problem is that, given a desire to integrate that mainframe‐based data with other systems, you're left with few choices, and they all seem like bad ones. Mainframe applications aren't generally designed to expose application programming interfaces (APIs) so that other applications can interact with their data. Mainframe apps don't typically provide direct database access, either. Instead, they're based on ages‐old, manual entry screens, typically conducted through terminal emulation software or other user interface layers.
Sure, you could change all that, but reprogramming a mainframe application is a big move. It's risky because you're tampering with an application that forms a core part of your business. It's time‐consuming because most companies typically maintain a long backlog of application changes they'd like to make—and because working slowly and carefully is the only way to help reduce the risk of messing with such a mission‐critical piece of the business.
In other words, connecting your legacy data with other applications is risky, difficult, and time‐consuming. Many companies prefer to simply not do it, meaning they have to content themselves with leaving their data locked up inside those mainframe applications. They have to be happy leaving their data hostage. The good news is that it doesn't have to be that way.
In the next article in this series, we'll examine some of the traditional approaches to making that connection—and look at some of the downsides of those approaches. In the final article in this series, we'll see what new techniques and technologies exist to help make that connection with less risk, less time, and less complexity. However, to make sure those new techniques and technologies can meet real‐world business needs, we need to spell out some of the reasons businesses want to free their mainframe‐based data and bring it to the cloud.
One major reason companies want to unlock their legacy data is to enable integration with cloud‐based applications. As already mentioned, companies are increasingly turning to cloud‐based applications for select functionality. Although it's unreasonable to expect most companies to outsource all of their software, companies are finding value in outsourcing complex, difficult‐to‐maintain, hard‐to‐deploy applications that threaten to be a business distraction otherwise. Big enterprise‐class applications are a prime target: CRM, enterprise resource planning (ERP), BI, email and collaboration software, and so on.
These applications, however, don't exist in a vacuum. In order to provide the best functionality and the most value, these cloud applications need to access certain kinds of data, usually maintained in applications that are more core to the business' operation, which businesses quite reasonably want to keep in their own data centers. That might be a BI system that needs to access product and sales data, or it might be a CRM system that needs to access customer order information. The real trick to moving to these cloud‐based applications is in doing so while still giving them the tight integration with in‐house data that you'd get if implementing those applications in your own data center.
In companies that rely primarily on PC‐based computing, this integration often comes in the form of direct access to databases and applications. Newer applications are often written with data‐sharing APIs, and they run on standardized, easily‐accessible databases such as Microsoft SQL Server, Oracle, and the like. Those are all easily‐accessible using onsite agents and other techniques. However, if your data is locked up inside a mainframe application, getting at it can be much more difficult.
Companies are increasingly looking to exchange data with each other about their mutual customers—and not just for cross‐marketing purposes, as has often been the case in the past. Instead, companies are offering real integration of their services and partnerships, presenting customers with a more seamless experience. Online financial management systems pull bank account transactions in real‐time. Customer loyalty programs exchange points between customers. Customer appointments and reservations can be made through popular partner Web sites. These and other scenarios are becoming more and more common.
One approach to creating this kind of connectivity has been to implement custom systems. For example, one popular restaurant reservations Web site requires that restaurants use the site's own on‐premises dining room management software, enabling the site to remotely access table availability and create reservations. That's suitable for some circumstances, but companies are increasingly interested in creating that kind of integration with their own systems rather than adopting new systems. Such is especially the case with companies that have put one or more mainframe applications at the core of their business.
Yet mainframe applications are, as has been outlined, difficult to integrate with. How can a remote business partner's systems insert data into your mainframe application when the only way to enter that information is through a terminal emulator and manual entry? How can you ensure that the incoming data is valid, and that it won't bypass the business controls and validation built‐in to your mainframe application? That's a key challenge in enabling this kind of integration, and something we'll consider carefully in the forthcoming articles in this series.
Another kind of integration that companies are wanting more and more is to simply integrate their own internal systems more closely. As companies acquire new, nonmainframe applications and systems, they want those systems to be able to access the core data contained in the mainframe applications that run the business. That kind of integration typically involves a per‐project modification of the mainframe application— something that, as has been stated, can be expensive, time‐consuming, risky, and complex.
What's really needed is a way to expose mainframe data in a single, consistent fashion. Ideally, that method will include standards‐based communications so that a broader range of communications and data transfer is automatically available.
The idea, in fact, is to make your mainframe the back‐end for your own private "cloud." You'll provide specific interfaces that enable access to your legacy data by external systems—whether those systems are in‐house, owned by a cloud computing provider, or owned by a business partner. That's what we'll explore in the next two articles.