The Standard

Next Steps

The current content serves the objective of providing a common structure to align the work of the individual workstreams towards a consistent picture. Hence, we will drive the adoption of the Zero Outage map and the respective alignment in the next release.

As defined in the architectural framework the next logical step is the introduction and development of the reference architecture, including two essential architectural models: the functional model and the information model. Again, we do not need to start from scratch but can leverage the IT4ITTM standard, which specifies an IT reference architecture at its heart.

Graphic 19: IT4IT™ Version 2.1 reference architecture level 1

That is a great basis targeted at the modern IT enabling digital transformation, however, not (yet) driven by Zero Outage use cases.

Therefore, we need to thoroughly articulate such use cases and scenarios, and determine, whether and how IT4IT caters to these and where not. For these specifics we then need to articulate the rational and the consequences, which might be expanding the functional and information model, adding required detail specifications to it, or even change it. Certainly, we will undertake this work in close cooperation with the relevant teams at the Open Group. As a result, this will actually strengthen both standards initiatives as well as the market adoption.

Graphic 20: Draft thoughts to expand the RUN RA

Even though this is very early thought leadership and by no means a best practice yet, let‘s look at a potential expansion of IT4IT, simply to get the principle approach across.

We articulated the capability „Preventive Health Management“ earlier, stating that in order to drive Zero Outage, we need to innovate the approach of anticipating issues, specifically using big data analytics.

This certainly disrupts the traditional approach of monitoring, event and incident management. That linear approach of looking at the known infrastructure and data sources, and acting after the fact does not cater well to the Zero Outage goals. On the other hand in reality there will always be a mixture of traditional and Zero Outage use cases. Hence, it does not make sense to throw away the „Run“ reference architecture and redo, but to sensibly build additional functions, data objects and relationships around. This won‘t be the final answer, but the thought was to add unstructured data, integrate with structured data, do behavioural data analysis on top to pinpoint preventive consequences. Again, this is just a draft example work in progress to describe the approach, which we will apply to all Zero Outage critical capabilities across the value chain.

Looking further to the future, we also need to evolve the definition and articulation of the Zero Outage Map towards an operating model, expanding on related roles and responsibilities, metrics and KPIs.

The Zero Outage Map provides a solid basis as a capability model intrinsic to the plan, build, deliver, run phases, along with the supporting capabilities, most notably risk management and governance, but it still requires refinement of the fifth retire phase.

The layered model is conceptually a good start, but practically needs to be tested against the complex realities of sourcing trends and IoT, in cooperation with the platform workstream. Also, the application layer needs focus and the right level of detail in order to serve as architectural guidance.