Enterprise Executive 2017: Issue 2 : Page 44
Figure 1: How to Open Access to Your Mainframe Databases In many industries, such as financial services and healthcare, more than 80 percent of the structured data still resides on a mainframe. While this design worked well 20 or more years ago when the architecture was first put in place, times have changed significantly—and the shift to the digital economy is massively changing the workload topology again. When the architecture was first established the read/write ratios were in the 4:1 range; today, in the digital world where individuals can check their accounts multiple times per day, the read/write ratios have exploded to more than 1000:1. This transactional overload has created mainframe application bottlenecks and impaired an organization’s ability to create end-user apps that are responsive to users without overhauling or jerry-rigging the underlying data center infrastructure. The Traditional Band-Aid To satisfy the business needs IT architects have traditionally created a number of caches or cloned copies of the mainframe 44 | E nt e rp r i s e E xe c u t i ve | 2017: Issue 2 databases that can be used for each of the distributed applications involved. Since the mainframe is the only server with a shared-everything database architecture, this means that there is a requirement to make unique in-memory caches or cloned databases for each application and server (logical or physical) that needs access to the data. Moreover, these new databases are not read-only. Thus, at the end of the day—or at some points during the day— synchronization tasks must be executed to get all the databases in sync and reconcile all the differences. This is not much of a problem where the number of transactions are small. But when there are hundreds or thousands of applications and databases and the number of transactions during the day becomes quite large, it can create a large corporate risk exposure. Moreover, there may not be time enough during the batch window to reconcile all the differences and get all the databases back in sync before the process begins all over again—raising the risk level even more.