Understanding OIS - Standard InterOperations

The organisation that tools and curates Operational Integration Standards (OIS)

Standard InterOperations (SIO) provides the methodology, language and tooling to precisely model activities within and between organisations and allow them to be refined, converged and crowd sourced into best practice

These are documented in OIS Contracts

OIS Principle

each OIS Contract represents a distinct activity with operational value, performed by a supplier, with sufficient control from the client, but leaving the supplier free to optimise its performance and add maximum value

What OIS Does

OIS models operational activities precisely and without ambiguity, so they may be refined, communicated, compared, converged, crowd sourced into best practice and, most importantly reused. The models of activity are at their most valuable shared across the whole sector, to develop into sector-wide standards. Such standards create transferable skills within operational disciplines. They become equivalent to technical and engineering skills. They encourage solution vendors to produce products that are usable directly off-the-shelf.

OIS works by drawing on the experience of key Subject Matter Experts, modelling their know-how and turning it into a shared asset that is no longer hidden in the minds of individuals, to be lost when they move on. OIS can be used to model anything from laboratory experiments and medical procedures, to on-boarding new customers and setting up and monitoring networked devices

Introduction to Operational Integration Standards (OIS)

OIS & Subject Matter Experts

OIS empowers key subject matter experts in any organisation to compose a library of best practice within that sector

OIS Contracts capture the experience of these highly skilled specialists...forever

Technical Specifications

OIS combines a Domain Specific Language (DSL) with a methodology to apply the language

Solutions and Business Process designers can generate designs by sequencing OIS Contracts. These define supply chains, both internally and between organisations.

System functions and features are fully defined by OIS Contracts.

OIS finally unites the operations, business processes and systems by using a common language for Operations

More Ops Than DevOps

DevOps has emerged this millennium in recognition of the the divide between software development and the operational community it supports. It's aim is to make Development more effective in supporting Operations and this intention cannot be faulted. However, DevOps comes from the Development community and so is fundamentally about software development

The correct result of combining Development and Operations should be Operations

It is not that Development should be subsumed into Operations, but that it should largely disappear

IT, of course continues and grows massively as the primary enabler of operations
Development should be restricted to only those features that are unique to the organisation- features that give competitive advantage and must be kept in house as a trade secrets

Today, DevOps feels more like Development imposing on Operations. It is a hangover from the days when software was restricted to database transactions and Operations had to align to fit in order to benefit. With its many methodologies and evangelists, Development can all too easily dominate over Operations, who have little or nothing by way of shared methodology. And yet, software should no more prevail over Operations than, for example, Human Resources (HR). Both are enabling facilities, not a sector in themselves. Operations has a tendency to be subsumed by the enabling services in an organisation, whether it be headcount reduction implemented through HR, or process automation implemented through Development. Both are necessary; one supporting systems, the other supporting people and both have their methodologies and professional discipline, but it is Operations that delivers revenue.

Operations suffers because the experience and expertise of operations are home-grown and kept isolated . They have not been turned into disciplines, with methodologies and made professional. There are no bodies of knowledge, or a means to acknowledge excellence.

Until now. OIS changes this. It brings professionalism and authority to Operations by creating an independent body of knowledge to reference correct practice. OIS stops Operations being subsumed

OIS - the Journey to Industrialise Enterprise Software

The journey is a human and organisational effort to converge operational activities, be they technical, or people-based, and remove unnecessary variation. This is carried out using an ever growing library of OIS Contracts that stabilise more operations in more sectors and highlights similarities between sectors

OIS methodology connects individual skill areas into a model of the entire solution

Componentisation

Experts build up a model of the system components in their environment as they document their expertise. They establish distinct roles and boundaries for the components they are involved with, as part of authoring OIS Contracts

Those components become standard building blocks, when they represent a converged view, specified in collaboration with other experts in the field, from consumer organisations, vendors and integrators

More of the sector is componentised as OIS Contracts are authored in adjoining operational areas.

Business priorities determine which operational areas are modelled using OIS and in what order

Everything is made from building blocks

and most things are made from standard building blocks; skyscrapers, computers, our bodies - anything engineered.

We know what an engine block is and a gear box and a clutch assembly. We know what they do and what they are used for in a vehicle. No one ever says "Its just metal, we can make it do whatever we want", because they are established components in an engineering discipline.

The first step in the industrialisation of enterprise software are components, with clear roles and clear values. But the situation today shows us that even with long established components such as CRM, Order Management, Payroll, ERP and Billing, by themselves, components are no where near enough on their own

Component Inter Operation

OIS Contracts specify how system components inter-operate. This is not just a matter of 'Services Offered', but also about 'Services Required' and by whom. This ensures that the components really can plug together

System inter-working becomes standard when peer groups of experts collaborate to specify OIS Contracts for the whole sector

Software vendors are able to offer products that are compliant with commodity specifications

A detailed model of the solution emerges as more OIS Contracts are specified, so increasing the coverage over the operations performed in a market sector

Designers combine OIS Contracts to;

specify systems
assemble solutions
assemble macro business processes

In fact solutions and macro processes become exactly the same. Finally Operations and IT are unified

You only really know what a component is, by the way it inter works with others.

A component that advertises what it must connect to and what activities takes place over that integration is a building block. The component is designed to work as part of a bigger machine. The engine delivers certain features to the clutch assembly, which in turn delivers specified features to the gear box and so on

Value Differentiation

Standardisation does not mean all operations are conducted in the same way in all organisations

Proprietary features can be added to the commodity OIS specification in a number off ways

What is more, experts specify what and with what performance a component operates,

but not How the component works internally. Distinguishing between the two is another challenge for the Subject Matter Experts

The internal workings of each system may be as rich, as costly and as performant as the market will bear

Vendors are motivated to differentiate their offerings on price, features and performance, or any other factor

Much more innovation is possible with standards. Every computer; server, desktop, laptop, tablet, or mobile uses standard physical components with standard inter working. Software standards for smartphone allow app stores to exist. Anyone argue these areas are not innovative?

Well defined components that inter work in standard ways creates a global market for component products. It motivates suppliers to take the commodity features and add their own innovative value.

In due course, innovative features will be commoditised - folded back into the standards,

so that newer innovations can be built using them

Plug-and-Work Solutions

OIS generates machine readable code to enable automated assembly. It will enable systems to plug-and-work for commodity features, leaving integration effort for new, innovative features in the integration. Software systems will need to be enhanced to read these specifications, but that is not additional work. It simply replaces otherwise custom interface specifications

The journey of componentisation, component integration and productisation must be taken first, to create the building blocks