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
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
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.
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;
![]() 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
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
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. |