A Case Study on the Origin of the IT4IT™ Standard

On the Origin of the IT4IT™ Standard

Boundaryless Information Flow™ achieved through global interoperability in a secure, reliable, and timely manner

Executive Summary

Like many of technology’s better creations, the IT4IT™ Reference Architecture standard was born out of necessity.

The IT landscape is continually shaped by innovation. Despite that being a cause for celebration for consumers and end-users, the introduction of these new technologies – such as the mainframe, the PC, client servers, the Internet, cloud computing, IoT, etc. – meant that the IT function had, effectively, lost track of what it needed to manage and control.

An open standard architecture-based approach to managing the business of IT was needed. This would have to be a holistic, end-to-end, service-based description of everything the IT function needs, and to be a good steward of all the IT components, solutions, and services within its remit. It was this issue that set in motion the train of events that brought us to where we are today. But there are no grounds for complacency. The work continues.

Even today the complexity and pervasiveness of, and the dependency on, IT systems continues to grow. In many cases, in many organizations today, the management solution is a loose collection of siloed processes. We are still not paying enough attention on how to remain in control. That is why the IT4IT standard is such an important instrument to manage IT, and why we have chosen to document how it came to be.

Why is the IT4IT Standard Needed?

The IT4IT Reference Architecture provides a structure to manage the business of IT and focus on end-to-end tracking of what happens so that organizations can connect the WHY with the WHAT and the HOW of their product and service delivery. Before, everything focused on managing the WHAT, be it process, technology, end-point, or whatever. Also, other frameworks, such as the ITIL® framework, did not really manage digital services as something that required product management and consistent evaluation against business terms. Instead, it focused on defining the people and processes needed to manage services, at least in our opinion.

Most IT organizations were (are) fragmented, non-collaborative, and generally immature compared to more traditional business areas like manufacturing and finance. Providing a structure that injects a business orientation around WHY IT exists is the basis for turning the situation around. Due to the unsatisfactory starting point, this is a huge, complex transformational undertaking that most companies shy away from. However, now the IT4IT standard provides a structure that allows IT organizations to resolve smaller problems that are easier to tackle, yet still address these in the important context of the larger end-to-end flows.

In short, in terms of structure, IT was a confusing, fractured world of technology organizations working independently of each other with little thought for cross-referencing. IT professionals and vendors did little in the way of collaboration.

Instead, they were creating and selling products and processes and associating them to disparate, largely siloed IT standards and frameworks, and these standards were predominantly process or technology-focused, with no agreed benchmark.

As the universe of business continued to rapidly expand, its growth driven by innovation and disruptive technologies, it became clear the industry needed a recognizable anchor point. That stability would be an agreed, vendor-neutral reference architecture for managing the business of IT. Those last four words are significant. Because the febrile world of business IT innovation lacked a real-world, holistic reference point, it would be a major improvement to develop a relatable framework that unified stakeholders and industries plus have the flexibility to accommodate changes in technology, process, methodology, or business models. This was the need that the original IT4IT Consortium set out to meet.

It is difficult to appreciate the need for the creation of this standard without fully appreciating the inefficiencies that preceded the inception of the IT4IT standard.

Typically, the development of an IT management solution for a reasonably-sized enterprise was done in silos, with no overarching plan. Consequently, it would evolve into a myriad of hundreds of individual, non- integrated systems with no unifying management function.

The realization that this was impeding the ability to deliver quality IT services to their lines of business would trigger major enterprises to do the architecture work to capture the current state and design a fit-for- purpose future iteration.

Companies would use consultancy resources and tooling vendors for that work and to understand how to manage IT going forward. This would generate case-specific, incompatible solutions, and blueprints using proprietary vernacular. The only common denominator would be the presence of the vendor’s tools at the pivot point.