Standardise interfaces, not technology


Infrastructure diversity is one important component of many IT infrastructures’ complexity. Even at a time when organisations are standardising on x86 hardware, they often maintain separate support groups by types of operating systems.

In the meantime, we see even more technology diversity developing in a relentless pursuit of performance, and ironically, simplification. This begs a simple question: Should we, for the sake of operational efficiency, standardise at the lowest possible level, e.g., the computing platform, or at a much higher level, e.g., the user interface?

In the past months, I think a clear answer was provided by the mainframe world. One key element that actually limits mainframe expansion in some data centers is the perception from higher levels of management that the mainframe is a complex-to-operate and obsolete platform, too radically different from the Linux and Windows operating systems.

This comes from the fact that most mainframe management solutions use an explicit interface for configuration and deployment that requires a detailed knowledge of the mainframe specificity. Mastering it requires skills and experience that unfortunately do not seem to be taught in most computer science classes.

Because mainframe education is lacking, the issue seems to be more acute than in other IT segments. This eventually would condemn the mainframe when all the baby boomers decide that they would rather golf in Florida.

 This whole perception was shattered to pieces by two major announcements. The most recent one is the new IBM zEnterprise platform, which regroups a mix of hardware and software platforms under a single administration interface.

In doing this, IBM provides a solution that actually abstracts the platforms’ diversity and removes the need for different administrators versed in the vagaries of the different operating systems.

The other one, which has been an ongoing strategy for quite some time, is CA Technologies’ “Mainframe 2.0.” Mainframe management solutions are often adopted as purely reactive and tactical measures. Each solution has its own interfaces and operability characteristics, which complexity derives from the platform and from the specific implementation of the management software.

The CA solution eliminates diversity through a unified, intuitive, and modern graphical user interface (GUI) for configuration and operation, and embedded best practices reduce the dependence on skills and experience. CA Technologies has run a number of spectacular benchmarks where non-mainframe specialists actually implement solutions faster with the new interface than specialists using the old one.

Ideally, if this was extended to cover all management solutions, regardless of the destination platform, we would have removed a serious operational hurdle and actually abstracted a lot of the complexity off system administration and management.

As stated in my recent paper “The Writing On IT’s Complexity Wall,” diversity comes from the fact that IT projects related to architectures or applications and business services are discrete events. They are based on the technology available at the time and conclude with that same technology.

As IT technology progress is a quasi continuum, projects are actually technologically obsolete by the time they enter production. Then the next-generation projects will use the next available technology, which leaves IT organisation with many different platforms, each with its specific management constraints and each requiring specific skills.

The obvious conclusion is that in order to remove the operational consequences of diversity we must either freeze innovation and progress or find a way to abstract the resulting complexity. I vote for the latter.