Zero Outage Layered Model
Since the Zero Outage Industry Standard strives to achieve “Zero Business Outages” it must be applicable in a variety of IT environments. In today’s world where business value is created by integrating various services and systems, often across company boundaries, it is crucial to look at Services of Services and Systems of Systems. Complex combinations of on premise data centre solutions, can work hand in hand with cloud solutions and even further with non-data centre IT like Internet of Things devices.
Defining the Layered Model
In the interest of architectural clarity, the Zero Outage Industry Standard follows a layered model. This model takes into account the way IT is deployed in terms of shared versus dedicated, and traditional versus cloud implementations.
As depicted in Graphic 12 there are three horizontal layers:
- The foundation is called “Basic IT Infrastructure”, containing data centre facilities, cabling, network, storage and compute capacity.
- On top of this basic layer sits the “IT Systems and (shared) Services” layer, which provides both, the platform for application to build its consumable business value upon, and the control system for the underlying IT infrastructure. Therefore, IT Systems include Operating Systems and infrastructure controllers (e.g. virtualization) as well as shared IT services such as data persistency, API management and orchestration (e.g. process, container).
- Finally the “Business Application” layer exposing the functionality in support of one or more business processes, which includes user experience, application logic, data management and integration building blocks. Building applications on top of IT systems and services as an abstraction layer makes both, the applications and infrastructure easier and better to manage in the Zero Outage sense.
When talking about a Zero Outage Service as a solution provided by IT (along with its internal and external suppliers) and consumed by business users (internally or externally), the following applies.
- The business user does NOT experience any service outage or degradation.
- The Zero Outage service may be comprised of other services.
- Its implementation may cover all layers and deployment options.
Remark: In future publications the Zero Outage Industry Standard may also include IT equipment that resides outside of data centre environments. Examples might comprise departmental IT equipment, mobile devices or Internet of Things devices.
Implementing the Layered Model
Depending on the actual implementation, each layer can be used by one dedicated client, by a small number of clients that share the resources of that layer or by many clients. Dedicated is the most common model in the traditional enterprise data centre environment, but many IT Service Providers offer dedicated environments in an outsourcing type of service as well. Shared environments span a wide range of implementations from company internal solutions to cloud services. Public is generally offered as cloud services to provide the scale needed to support a massive number of users.
All layers themselves are complex structures that are comprised of building blocks, such as servers, storage and network in the basic infrastructure. The building blocks can be further de-composed into components, such as switches and routers in network, for which vendors offer specific products.
From a business perspective every solution that realises a Zero Outage service can be created from a combination of building blocks or components from all layers and across the various deployment models. It is rare today for a solution to have a direct relationship of the desired business outcome to an individual IT system that uses a single stack of IT infrastructure. The norm is rather to have a number of building blocks and components on different layers that have to work together to provide value to the business. Graphic 13 shows a conceptual picture of a business solution that leverages a number of building blocks dispersed across layers and deployment models.
To make sure that the goal of Zero Business Outages is achieved, every building block must provide the appropriate level of resilience, depending on the capabilities of its components and the capabilities of other building blocks. It might be possible to raise the capabilities of one building block and therefore to lower them on another one or the other way around.
One example could be to use multiple components with almost no built-in resilience but leverage resilience capabilities on a higher level to achieve the desired quality. Following that principle of delegating functionality (in terms of resilience) to higher levels would offer some freedom in the way a solution is implemented and more effectively facilitates finding the optimal balance between resilience requirements and affordability per component.
To enable the principle mentioned above, it is necessary for each component or building block to offer the following:
- It must not contain nor be a single point of failure itself.
- It either has to fulfil the Zero Outage Industry Standard criteria for that kind of component or, if it does not fulfil the defined criteria, it has to define what it requires from a higher layer.
Graphic 14 depicts an example.
At the centre of the above picture is the component of a building block. On the left is an example of the list of Zero Outage requirements (coming from the Zero Outage Platform Design Principles [future release] in that case) and on the right it would provide a definition of requirements to other components within the same or in higher layers.
The “Layered Model” provides an overview which allows individuals or companies interested in the Zero Outage Industry Standard to easily understand some basic concepts and ideas. Together with the Zero Outage Map it offers overarching design principles, which are further detailed in the documentation of the workstreams covering people, processes, platform and security.
Linking the Layered Model to the Service Model
As described in the Zero Outage Map, the service model is the centre of the value chain. Its specification evolves along the lifecycle of a service along the value chain, from a conceptual model in Plan, to a logical model in Build, to a desired model in Deliver and an actual model in Run.
Each phase and the corresponding model require specifications across the levels of the Layered Model. For simplicity the table combines the lower two layers into one, the systems & infrastructure layer.
When looking into the details, the table expands into the following service model details across the layers, which is work in progress, requiring further review and detailing as a next step:
This will provide further guidance to the workstreams developing and structuring design guidelines and best practices along the architecture framework.