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


Meaning of 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

OIS Contract

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)The Value of OISHow OIS WorksRole of SIOEnterprise Software in TransitionBack to Home Page


OIS & Subject Matter Experts

OIS empowers key subject matter experts in any organisation to compose a library of best practice within that sector
OIS Summary
 
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
Technical Specification

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


Introduction to Operational Integration Standards (OIS) The Value of OISHow OIS WorksRole of SIOEnterprise Software in TransitionBack to Home Page


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
Operations DevOps

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

Introduction to Operational Integration Standards (OIS)The Value of OISHow OIS WorksRole of SIOEnterprise Software in TransitionBack to Home Page


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
Integration

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

Branded Software Products

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.