Even though some enterprise workloads are shifting to the mainframe, the continued proliferation of Unix/Linux/Windows scale-out servers shows that the mainframe has moved far from the dominant position it held in the 1970s, when the default location of an app was on a System/3x0 machine in the data center. As long as overall enterprise workloads stay split between mainframe and Unix/Linux/Windows or shift away from the mainframe altogether, the mainframe's future is in question.
A new enterprise architecture concept
I believe that the long-term mainframe solution to this FUD (fear, uncertainty, and doubt) is a new enterprise-architecture concept that is an elaboration of the old idea of a "hub." The old idea of a hub was a separate set of systems specializing in a particular function. The new idea of a hub is a full distributed enterprise architecture in which one system, system type, or platform is "first among equals" for a specific
To put it another way, a new-type hub's core is the site of key "metadata" or governance for a particular business/IT function or the enterprise architecture as a whole. One example is a data-hub architecture that has multiple database instances operating on platforms ranging from mainframes to laptops, all interoperating as if they are equals. Still, the data dictionary that defines the location of data items -- and links between them -- would reside on the core hub machine. Therefore, for optimal performance and simplicity, as many database instances as possible are placed on the same core machine or platform.
The advantages of a hub-type architecture are abstruse, but very real. For example, suppose an enterprise took a service-oriented architecture (SOA) or cloud and converted it to a new-type hub architecture. In the new architecture, as before, new apps can be flexibly placed anywhere and moved relatively easily from platform to platform as the enterprise's needs change. But compared to the vanilla cloud, a hub architecture centered around a high-quality platform like the mainframe adds most of that platform's advantages in robustness, security, and scalability.
Additionally, having key metadata in one place simplifies people's lives. The programmer is confident that the hub architecture will increase the scalability, robustness, and security of the app he/she is developing, and also knows where to store the app's metadata. The administrator knows that key data, usually about the apps he/she is monitoring, is always available and where it's located. The CIO or CTO has a new tool with which to decrease enterprise-architecture costs and/or improve its capacity, by flowing workloads to the "specialty" core hub platform.
Mainframe at the center
The mainframe is, and should remain, the prime candidate for the core platform in such a hub architecture -- the "hub of the hub," as it were. The mainframe's continuing excellence in scalability, robustness, and security, plus its new strengths from virtualization in cost-effectiveness and energy savings, make it a natural core where users apply the hub concept to existing enterprise architectures of a certain size (e.g., 20 apps or more). IBM has suggested six areas where users can employ the mainframe as a hub core right now:
- Business process integration (BPI)
- Storage management
- Workload/capacity management
- Data serving
- Business resilience
Until recently the mainframe lacked many of the key features required of a hub core platform. This includes the ability to provide an integrated systems management, identity management, information integration, or failover solution spanning not only mainframes and the data center but also distributed Unix, Linux, or even Windows machines. How close is the z10 to being able to do these things? Again, let's look at data serving as an example.
Since the 1960s, the mainframe has been the logical repository for mission- and business-critical structured data in file, record, or database formats. The mainframe as a data-serving hub would go well beyond this; it would be the central repository for metadata allowing information integration and coordination of information on demand across different data stores on different platforms, and might add rich-media (Web audio, video, graphics) data management to its responsibilities. The mainframe already handles the most mission-critical data, so it's the best place to put a repository that will first and foremost support mission-critical-data access and database coordination.
In particular, there are a couple of possible tasks for the mainframe right now as a data-serving hub: 1) as an "offload" from other systems in the enterprise architecture for high-performance/high-storage-capacity transactional apps; or 2) as a content management (CM) hub. In the first case, IBM is clearly already providing mainframe-hub services in the real world -- Second Life now apparently handles certain types of data/transaction on an IBM mainframe integrated with IBM's Cell Broadband Engine. As for the second case, it appears likely that IBM CM and FileNet workloads will be coming to the mainframe now that it can handle XML and binary large objects (BLOBs) better. Content Manager is being ported to the z10, although an upcoming Integrated Information Server product on the mainframe is "not ready for prime time."
Change your hub architecture incrementally
Overall, then, the idea of the mainframe as the core platform of a new-type hub architecture is highly attractive. The hub mainframe promises lower costs, more green-computing energy savings, greater robustness, better security, higher scalability, and increased architectural flexibility not just in the data center but also across the distributed enterprise. These improvements should be achievable without major changes to an enterprise's existing architecture, in much the same way that consolidating Unix workloads on partitions on the z10 is proving straightforward to implement. On the other hand, in many of the areas cited by IBM as places to implement a mainframe-centric hub architecture, the features needed for full z10 hub support are a year or two away, so a real-world implementation may require extensive advice and customization by IBM services.
I therefore recommend the following IT action items right now: choose what types of hub are appropriate for you; do a preliminary architectural design with full understanding of the app/database migration that will be involved when the architecture is implemented; implement the foundational components or specialty hubs that are already available -- and enjoy the incremental benefits while waiting for the full solution.
ABOUT THE AUTHOR: Wayne Kernochan is president of Infostructure Associates, an affiliate of Valley View Ventures