Db2 for z/OS and its ecosystem

This is the fourth in a four-part series of articles addressing Db2 for z/OS and modern development utilizing an Agile methodology and DevOps processes. To read the first three articles please follow these links:

https://community.ibm.com/community/user/hybriddatamanagement/blogs/daniel-luksetich/2021/06/21/traditional-db2-development-vs-modern-development

https://community.ibm.com/community/user/hybriddatamanagement/blogs/daniel-luksetich/2021/08/09/devops-and-modern-it-defined

https://community.ibm.com/community/user/hybriddatamanagement/blogs/daniel-luksetich/2021/09/14/the-ibm-unified-management-server-and-db2-for-zos

In this article we address the critical needs of the Db2 for z/OS professional and the way these needs are met with the IBM Db2 DevOps Experience for z/OS. In addition, it will look at the needs of the modern Application Developer and the enterprise advantage to keeping your systems of engagement and innovation close to your system of record.

Systems of Record versus Systems of Engagement/Innovation

• Systems of Record

This is the authoritative system for a given element or piece of information, often the primary database supporting transaction processing. This basically represents the primary data store for an enterprise and the heart of their IT operations and is typically centralized. For z/OS systems this typically means a database in Db2 for z/OS, IMS, or perhaps even VSAM.

• Systems of Engagement

These are typically people-focused applications that enable customers, partners, and employees to interact with the business. These applications can be decentralized and typically evolve quickly to meet the changing technology, representing ways in which enterprises can interact with their customers.

• Systems of Insight/Innovation

These are applications that use leading edge technology that aims to improve the customer experience through information discovery, driving new ways of doing business. These applications are also typically decentralized and can be deployed across multiple technologies.

Db2 for z/OS continues to hold its place as the premier data store for your system of record. Db2 12 for z/OS offers astounding stability, availability, and performance for all your high-volume mission-critical applications. Your systems of engagement and insight/innovation, however, are often being built upon database technologies other than Db2 for z/OS. This is under the pretense that innovation happens at a greater pace with these new technologies than the enterprise z/OS system, and Db2 for z/OS cannot adapt to this pace. The result is a collection of cloud-based applications and data built around the z/OS system, sometimes involving replication of data from Db2 for z/OS to these applications and databases that are often cloud-based. While cloud computing can offer fast deployment and provisioning, costs can quickly spiral out of control for these systems. The cost of the replication of data from Db2 for z/OS to these remote systems can increase dramatically as the data quickly grows

The Evolution of Db2 for z/OS and Database Administration

In the first article of this series we discuss the evolution of Db2 for z/OS and the evolution of Database Administration on the z/OS platform. With an aging workforce and continued attrition, the Db2 for z/OS DBA is faced with a plethora of development databases to manage, as well as the needs of the production environment in a 24X7 world. While there has been a reduction in Db2 for z/OS database administration staff, there has been no lack of new Db2 for z/OS features, as well as an overall improvement to the database engine, during this same period.

Adapting to Change

Competition is fierce and the enterprises that can adapt and innovate the fastest are winning. You cannot think that your enterprise is immune from competition. Delaying, or avoiding, innovations in favor of traditional application development methodologies does not help. At this point in time, information technology is part of what drives your enterprise and the product it delivers to your customers, regardless of industry. Thus, innovation is the key to success, and we need to start adapting how we manage Db2 for z/OS to keep pace with this level of innovation.

The most successful companies recognize information technology is a core competency of the business. The advent of cloud has lowered the barriers to delivering world class technology to start     ups and smaller companies. Your competition might be coming out of left field, looking more like an information technology company than your competition has in the past. Many of these startups have shown the ability to challenge mainstay corporations. Just look at startups like Uber and Lyft, and what they did to traditional taxi service, or perhaps Airbnb and its impact on the hotel industry. A large enterprise needs to approach IT with the same zest as the smaller ones to maintain a competitive advantage. Agile development and DevOps processes are focused on the rapid delivery of innovative business system features which delight your customers. Can you outpace the innovations of a focused, driven start     up that is determined to disrupt your industry? Decades old lean manufacturing techniques have shown to apply to information technology feature development and deployment. To outpace the competition, you must be more efficient at delivering what your customers need. Instead of constantly pushing on the accelerator, try taking your foot off the brake.

Traditionally, there have been designated and rigid roles involving the management of Db2 for z/OS in an enterprise environment. The Systems Administrator role typically involved the installation and maintenance of Db2 for z/OS. The Database Administrator role typically involved managing the definition of database objects, the management and availability of the data stored in those objects, and perhaps also included physical data modeling. The Data Administrator role involved entity and attribute definitions, enterprise standards, as well as process modeling and data modeling. The Business Analyst role involved defining interfaces, business rules, and dealing with customer requirements. The Application Developer role served to deliver the application logic that connected the defined processes with the Db2 database. In larger enterprises these roles could be further subdivided and in smaller enterprises one individual could fulfill several roles. This conglomeration served the waterfall methodology of application development very well, and provided strict rules, documentation, and control over all aspects of application development. However, while all these roles still exist, the support model must change in an era of DevOps processes and Agile development methodologies. The enterprise must adapt to the fast-paced world of modern application development, which includes continuous delivery and continuous integration. This does not mean job elimination by any means, but it does mean a redistribution of responsibilities, hopefully aided by some automation. Of course, there are many ways to handle the redistribution of these responsibilities, and there is no “one size fits all” approach.

The goal is to have your systems of engagement/innovation use the same Db2 for z/OS as your systems of record, thereby reducing costs associated with data replication as well as cloud costs associated with provisioning a data stack, utilizing a data store other than Db2 for z/OS for your Application Developers.

Changing the Support Model for Data Administrators

To enable DevOps processes, including continuous delivery and continuous integration, the individual Application Developer is going to need a little more control over the development process. This includes the ability to provision and modify database resources. This, by no means, is a wild-west approach to development as there can still be a system of appropriate checks and balances. It does mean, however, that certain functions within the enterprise will have to evolve. While major application design efforts may still be managed by Data Administrators and Business Analysts, individual sprints involving relatively minor changes requiring immediate (two-three weeks) coding, testing, and integration could be performed by Application Developers with minor oversight. Regarding enhancements to existing applications, the most common database change is the addition of a column to a table. Such a change could be entirely handled by the Application Developer.

While major database designs should remain in the hands of Data Administrators and Business Analysts, modifications like column additions to tables in response to application changes could be handled by individual Application Developers. These types of changes, traditionally speaking, are submitted to Data Administrators to review for compliance with data type, naming standards, and data modeling. In an Agile world the change being incorporated and coded grinds to a halt when such a request is made, and with such short      durations (sprints) for testing and delivery any delay involving a request being accepted, assigned, analyzed, and approved would be unacceptable. Giving developers’ individual control over such changes means a new set of rules would need to be developed and applied to development procedures. These rules could be documented and distributed to the Application Developers but enforcing them presents another challenge. Applying DevOps processes within Db2 for z/OS database management can assist with rule enforcement. If Data Administrators can develop, store, and enforce the rules as metadata in Db2 this daunting task becomes very manageable.

The DevOps Research and Assessment LLC (DORA) talks about database changes as a major source of risk and delay when performing deployments. The key to mitigating these risks is to establish good communication and comprehensive change management practices. Integrating database work into the software delivery process helps contribute to continuous delivery. Keeping all database changes in version control associated with the corresponding application changes will go a long way to improving the DevOps process. Utilizing a tool, such as the IBM Db2 DevOps Experience for z/OS will help to integrate those application and database changes.

There are no right and wrong choices, but there are trade-offs and consequences in business decisions that are made. Development, like electricity and water will eventually end up taking a path of least resistance. Data friction in DevOps is a primary driver that sends developers to other platforms. This may seem innocent enough. Given enough time and enough data feeds, Db2 may lose its reign as the system of record. Db2 for z/OS has been, and still is, the system of record for many enterprises, but is the business innovating around Db2 for z/OS? Responsible leadership demands a good hard look at modernization and the cost that comes with it. Especially, if the data in Db2 for z/OS ends up being replicated from the system of record to the system of engagement or innovation. Many times, these costs are divided up or hidden under “maintenance” that mask the true costs of distributing this data. It may be appropriate to balance this against the cost of investing in a DevOps solution for your Db2 for z/OS data store as an alternative. There could be a significant advantage to this approach!

Changing the Support Model for Database Administrators

In support of DevOps utilizing Db2 for z/OS as a data server, development and testing environments will need to be established, or allocated, and managed. This would include targeting appropriate LPARs or Sysplex, and Db2 subsystems, and designating their use, whether it be pure development, integration, or testing. This level of designation can assist Database Administrators and Application Developers to contain the proliferation of database schemas.

Database privileges are an obvious critical concern and giving Application Developers the authority to create and change database objects, even in a development or test environment, can lead to chaos. This would be an extremely difficult thing to do without some sort of software tool to manage this access. Otherwise, the Database Administrator is making the changes and that work could become a bottleneck. The IBM Db2 DevOps Experience for z/OS solves these issues.

Database schema management is an extremely important subset of the Database Administrator’s responsibilities and the focus of the DevOps activities for the DBA. Developers and their development teams will need to be identified and a process created that can assign databases, or subsets of databases, to these teams. Unique schema names for individual instances of a given set of database objects will need to be determined. These instances could then be used to create DDL and the appropriate logic to populate data in the appropriate environment (i.e., provision a development or test database) assigned to a team or individual Application Developer). As part of the application development activity, the Application Developer could then modify a database object in their assigned isolated instance, subject to the rules developed by the Database Administrators and/or Data Administrators. After Database Administration approval, any changes would be applied to a master copy of the DDL for that database, and promoted through integrated landscapes, eventually deploying into production. While it is a part of DevOps that a database can be provisioned for development and testing, the code (DDL) must be maintained, changes tracked, merged, and kept consistent. This is another potentially daunting task for a Database Administrator, and one in which a software tool can be of definite benefit. Once application development has completed for a particular instance that instance can be dropped (i.e., deprovisioned) or maintained for future sprints. Once again, the IBM Db2 DevOps Experience for z/OS can manage all of this!

What is the IBM Db2 DevOps Experience for z/OS?

In the third article of the series we introduce the reader to Zowe and the IBM Unified Management Server. In short, this software provides a browser-based interface to z/OS resources, which includes the IBM Db2 DevOps Experience for z/OS. There is no need to train Application Developers or newer Database Administrators in the task of navigating TSO/ISPF since most of what they need on a day-to-day basis is integrated into an intuitive web interface.

You can get all sorts of information about the IBM Db2 DevOps Experience for z/OS here, but in short here is what it has to offer:

• Intuitive web-browser interface
• Ability to configure and enforce
  • Environments
  • Teams
  • Security (governance)
  • Design rules
  • Standards
  • Storage reporting and limits
• Control DDL as code, including versioning
• Provisioning and De-provisioning of database schemas
• Unites application version control with DDL

The IBM Db2 DevOps Experience for z/OS is built upon REST services which can be invoked from a variety of software tools and platforms, enabling a DevOps Engineer to customize the CI/CD pipeline by incorporating Database as a Service (DBaaS) into the pipeline. All the IBM Db2 DevOps Experience for z/OS REST services are fully documented via Swagger.

Final Word

The IBM Db2 DevOps Experience for z/OS is designed to complement all roles and implement the efficient processes to support the fast release cycle. This keeps Db2, and the Z platform relevant, and allows Db2 to be a first-class citizen in the innovation delivery of your enterprise.
#Db2 for z/OS