It’s my experience that all delivered projects and operational processes are governed by the project management “golden triangle.”
This is a triangle where each point is a different option for the outcome: fast, good and cheap (see Figure 1). You can only manage two, as it’s not possible to achieve all three at once.
Figure 1: Golden Triangle
As a programmer analyst early in my career I was exposed to the project management processes and learned about the golden triangle. I didn’t appreciate this fully until my first technology migration later as a lead architect. We successfully delivered the project, but a month later we experienced an outage due to a design flaw. The outage lasted 12 hours. The technical debt we created in the project caused the “bad day.”
Development encountered a design problem that delayed getting the system to Quality Assurance. The validation testing was successful and a decision was made to go to production.
Architects sometimes miss opportunity's to establish value in an organization strategically during project development. As leaders architects are responsible for protecting production for future projects and provide technology roadmaps as a future guide. Sometimes, our enthusiasm to help the business deliver time to market blinds us to what might happen in a bad day.
Project managers are measured when a project’s delivered on time and on budget, which begs the question how does “good” get handled? The design, architecture and process of a given project address the “good” attribute. This is where an architect, the system historian, can have a huge impact on the success of a project.
Plan for Technical Debt
Each completed project creates technical debt. If you’re trying to get an idea to market in a hurry, you probably doubled that debt. Unfortunately, once the project is up and running the cleanup is abandoned for resources to be applied on the next project. It’s important to build into any project process the ability to productionize or reduce technical debt to continue the evolution of a given application or service. All technical debt must be paid. One of the challenges for an architect is to plan that payment when it’s not a surprise.
The z System platform has done an amazing job at helping system and application architects deal with technical debt. I expect that most who have been involved in the platform know those capabilities of IBM z but don’t actually discuss these and other attributes with their distributed teams. Sometimes it’s just a language barrier that needs to be addressed. What follows is information about some of those attributes.
A major tenet of the mainframe architecture is to separate the life cycle of the hardware with the life cycle of the software. I’ve been involved many times when a company brings in a new generation of mainframe hardware within days or a week. They successfully brought the system into production with only verification checks. The frameworks and application software rarely need regression testing because of a hardware upgrade.
This leaves the frameworks and the application teams to take their time for migrating to the next version or update the application to take advantage of new functions.
This is especially true with the LinuxONE offering. If you have applications that run Linux on z Systems you’re covered with the same capability. Application development teams aren’t forced into a software tech refresh each time the z System server’s upgraded.
The technical debt can be created when a system shop wants to keep things as they are and just upgrade the machine without keeping up with the framework or z/OS releases. This platform allows these types of decisions to a certain point. Unfortunately the rules of the golden triangle are that this debt will be paid with inflated future dollars.
The IBM z platform has processor resiliency built into the hardware and microcode. When a CPU fails, the system will switch on the next instruction cycle a spare CPU maintaining application state and processing capacity. Repairs can be delayed to the next maintenance window.
This is a critical capability for applications operating at high system utilization to maintain capability through a CPU fault.
The technical debt is addressed by not having the application program or frameworks write system level code for local processor resiliency in the z System platform.
A huge capability of the z System platform is its ability to share everything in the Computer Electronic Complex. There aren’t systems restrictions to moving a process to another core, memory or I/O channel seamlessly. All such restrictions have to be configured into the system. This reduces resources needed to drive a multi-application environment.
An applications programmer or system administrator isn’t required to statically map a CPU’s I/O paths or memory allocations to an application or service. The time to market and the quality of the delivered application or service is improved. The application development teams can focus more time on testing reducing technical debt.
This item is the most misunderstood attribute of the z System platform. Simply there are two major measurable categories of expenses:
- Develop and maintaining application code and frameworks
- Ongoing running and licensing in support of the application
The misunderstanding comes from unmeasured expense driver called non-functional requirements.
The first application on any platform has to pay for the following non-functional requirements:
- System backup and restore
- Data backup and restore
- Application recovery
- Disaster recovery
Each subsequent application that’s added to the platform doesn’t have to invest in these capabilities other than implementing the business requirements to participate in the existing processes.
Consolidating on a system that has the ability to enable processors upon demand solves the time to market problem without development resources. Licenses don’t have an impact to your run rate until you actually use the software and derive business value.
This is a huge save and contributes to reducing future technical debt. Because non-functional expense is not reported as a single line item, the consolidation value of the platform isn’t fully realized.
Architect Is Critical
The role of the architect in the golden triangle is critical to the success of any project.
Essentially you have to cover what the project managers and developers don’t want to address, like protect production and manage future roadmaps. Every project investment needs to include thinking ahead to the next set of projects at least to make sure you and your team aren’t creating technical debt. It’s made easier when you can react to market conditions on the IBM z platform.
Understanding the expenses of non-functional requirements and finding ways to cost effectively reduce technical debt are the real benefits of the z System platform.
My first bad day under my watch was due the business modifying a new table with a GUI. There were 10 fields in a condition that wasn’t tested. The system crashed three days later.
Donald Gerace z Systems client architect at IBM.