Information Technology (IT) is rather young in human history. If you compare this sector with industry, IT is just at the beginning of its development. To illustrate this infancy, let’s consider the evolution of IT jobs. With the multiplication of tasks and jobs left to IT, teams grew in number but also in complexity. New fields of expertise emerged to cover these growing needs. Nowadays, a Fortune 500 company has hundreds of software products running on its infrastructure. More and more data are collected, processed, stored, combined, analyzed, distributed… The amount has grown by a factor of 10 in only 6 years.
For decades, companies’ infrastructures grew with the urgency of fulfilling business needs, but due to the infancy of IT, some organizational rules remained absent. The consequences are variable:
- Duplication of software covering the same needs
- Loss of knowledge on software dependencies
- Software that is no longer used but still maintained within the infrastructure
- Software with overdue/expired contracts remains installed
- Risks for future evolutions are hard to estimate which increases the probability of project failures
This situation is easily understandable:
- First, a system programmer does not have the time nor the responsibility to follow the lifecycle and the contracts of the software in use.
- Second, for a small organization, the lack of visibility on infrastructure has a smaller impact on the business. As the organization continues to grow and the amount of software increases, technological dependencies arise as contracts with ISVs are cancelled or changed. The problem only becomes relevant over time as the organization grows larger, as employees with infrastructure knowledge and skills retire or leave the company.
- Third, IT was originally considered as a support department, but that changed. When computers arrived, no one questioned their usefulness and significant computing investments were made. The benefits in terms of competitiveness and productivity, especially for administrative tasks, were obvious. But as time passed, IT became an opportunity to create value and, as a result, investments had to be justified and profitability became a new priority.
To control costs and evolution of information systems, companies adopted a strategic “software urbanism”. Its purpose is to build an organized structure for information systems that will lead to higher performance, flexibility and profitability. This approach consists of creating an inventory of current solutions and analyzing how they are addressing specific business needs, their connections with external software, and their potential. With this information, rationalization becomes possible and IT resources are enhanced.
Let’s now consider software urbanism as it is applied to mainframe management. As reducing IT costs is still a major priority for many IT departments, the mainframe is often put under the spotlight as it represents 30 percent of the software costs of a company. Viewed as an easy way to quickly reduce IT costs, the mainframe still remains critical for a business. In this situation, software urbanism is a great way to optimize costs without threatening the platform as it is simply a tool to improve how you organize allocation of computing workloads and localization of software. Actually, most ISVs are charging their solution on the amount of MSU used on the logical partition (LPAR) on which it is installed. So, having no urbanism strategy can lead to:
- Higher MLC costs
- Software invoiced twice or more for the same service
- Waste of resources
- Unused software increases LPAR consumption and therefore the costs of other software
Here is a simplified but real example from an airline company:
This architecture was a result of past company activity, as well as acquisitions and mergers. They simply merged infrastructures to ensure that they fulfilled all business needs.
The related costs are:
|Software||Costs (LPAR 1 + 2 + 3…)|
By completing a software urbanism project, the airline company noticed that they didn’t need this kind of architecture. They were able to optimize their infrastructure to reflect their current (actual) needs. Here is the result:
|Software||Costs (LPAR 1 + 2 + 3…)||Savings|
|IMS||400 MSU||400 MSU|
|CICS||400 MSU||400 MSU|
With just a logical organization on where to install the products, they saved 400 MSU for CICS and 400 for IMS!
Software urbanism has a significant and direct impact on reducing IT costs and, as such, provides other advantages:
- A clear overview on the enterprise architecture helps to manage the infrastructure on a daily scale
- It also helps to build an accurate capacity planning
- Further evolution will be easier to implement
An interesting question about software urbanism is: Why underuse it if it has such a power to rationalize software costs?
- A software urbanism project implies a long process—don’t expect to complete it in less than 6 months.
- You need to have the support of everyone involved in mainframe activities.
- Software urbanism requires dedicated resources: it’s a complex task that you can’t manage as a side task
- Infrastructure inventory has to be as exhaustive as possible, but it can be hard to track diverted software. Only users that are using software for something else than its main purpose, detain the information you need.
- All information gathered around business needs requires verification and cross-check to ensure the success of the project.
Software urbanism is a challenging project but, at the end, it is a highly rewarding one.