Enterprise Software - All Change
The organisation for Operational Integration Standards (OIS)

Enterprise Software

Punctuated Equilibrium comes from evolutionary biology. Change comes after a long period where everything stays much the same, but when it comes it is radical and dramatic. The same notion works for organisational change

Organisational Change

(1) a large majority of organizational transformations were accomplished via rapid and discontinuous change.., 
(2) small changes in strategies, structures, and power distributions did not accumulate to produce fundamental transformations

It is easy to assume that things will carry on the way they have always been
That assumption is never correct

Good news does not help you improve...Bad news does

Keep Calm
Enterprise software has been bedding into its current model for 25 years or more, but, as they say, past performance is no indicator ...

If the failure rate in major IT projects are taken as  'business as usual', or flatly denied, then uniquely valuable insights are lost and lessons are not learned

Contrast this with the way the Aviation Industry deals with failure. Each incident is closely examined, lessons learned and action taken to minimise the risk of repeating the failure

Most of the enterprise software studies place poor requirements capture ator near the top of the reasons for failure. It is the weak spot at the start of any big project. Requirements are captured in isolation, specific to each new IT project and they set the course of  the project towards either success, or failure

We take a step further back to the totality of the enterprise project process. Enterprise software is constructed by hand, as a craft, producing unique solutions that cannot be reused elsewhere

This can  be seen clearly in the cost of the software products in enterprise solutions, which are a tiny proportion of the total cost of the end result. The rest is hand crafted code from system integrators
Undoubtedly this is the right way to produce art, but is this the way to engineer an organisation? Every component hand-crafted and unique? A complexly interlocking jigsaw puzzle?

The reason why transformation projects in large organisation are at such high risk
is each one is built from scratch, with negligible operational reuse
and unable to converge on authoritative source for operational best practice

A change is gonna come.......Sam Cooke, 1964, an anthem for the Civil Rights Movement

Transformation in Enterprise Software

Evidence of Change
  •  Gartner, “By 2016, 30 percent of global organizations will establish a clear role distinction between foundational and vanguard enterprise architects
    • Foundational - legacy
    • Vanguard - high value business transformation
  • Enterprise software is moving away from a support role, to being front-line
    • Defense is now dealing with intelligence and cyber threats
    • Health and Social Care convergence is based on information integration 
    • Business Analytics and Big Data are showing immense value, particularly in the new, Internet businesses
  •  moving into  the spotlight....and into the firing range
  • Enterprise SaaS, Cloud-based services are on the march 
    • Most top 10 enterprise software vendors have SaaS offerings
    • Centrally managed, always up-to-date, usage-based pricing
    • No need for local management
  • SDN & NFV will replace the machine room with commodity appliances, moving features into centrally managed software
    • No need for local management
    • Operational specialisms captured in the software
    • This applies to the Communications Service Providers and  Network Vendors as well, so...
  • Specialist telecommunications devices (and their technicians) are already being replaced by basic data boxes, which have standard computing interfaces
    • The high cost and time-to-market of specialist network devices, with their custom interfaces is increasingly hard to justify
    • Less need for local management
Cross Hairs

If these trends are ignored, IT departments and machine rooms will become as rare as typing pools

OIS - Not Just a Methodology for Enterprise Architecture

There are very many initiatives, methodologies and architectural tools available today. There are even standards bodies for some enterprise software
Existing methodologies and tools deal with the software medium, not the business activity

Existing Methodologies, Tools and Standards

There are any number of tools for Enterprise Architects

TOGAF is a framework for Enterprise Architecture. It specifies a process to build architectures in its Architecture Development Method (ADM). The resulting architectures themselves are specific to each organisation that uses the methodology

The Open Group also has Enterprise Management Standards. These are pure IT standards

The Telemanagement Forum (TM Forum) deals directly with management systems in telecoms (see Telecoms Cases Study)
TM Forum has produced a set of framework standards for telecoms management software. These are not prescriptive, in the way that telecoms hardware devices have prescriptive standards, from organisations such as the ITU. Instead TMForum have framework standards that provide comprehensive coverage of Communications Service Provider operations, including Product, Customer, Service and Network

ITIL is a widely accepted process for managing the quality of software. It is a process description, like Project Management. It documents the steps required to maintain software quality and like Project Management, it is used independently for  each project, producing no enduring output itself for each project, but improving the quality of resulting software services

But even the software focus takes only the first step. These are frameworks, processes and methodologies. 
  • Standard frameworks leave individual organisations to customise their own version of the standard. A step in the right direction, but such standards do not enable actual interoperability
  • Processes & methodologies are applied to a project and then they are discarded. There is no enduring output other than the project itself
In the conclusion to the Microsoft Developer Network (MSDN) article, the author states 'enterprise architecture is a path, not a destination'

Pure Process Methodologies
Software standards & methods are best practice for the journey 
By contrast OIS is the common destination on which architectures converge

Gartner has a visionary view of Enterprise Architecture. It starts with 'a discipline for proactively and holistically leading enterprise responses to disruptive forces'. If this were realised, it would make Enterprise Architects a prime consumer of OIS

Change is coming....from Enterprise Software

Informed opinion agree that there is a necessary role for IT in the enterprise, but that is in delivering innovative and differentiating value (e.g.NETWORKWORLD: The future of IT jobs? Not all bad news, Carr says)

Software has come a long way in 25 years and the old limitations of data base systems have gone. Operational activities can now be built directly into software, when they are specified in a concise and unambiguous way

The core discipline for architecture and standardisation is no longer software systems, but the real-world operations of organisations

And here is the challenge

To have a future, IT departments, CIOs and system owners must shift their skills to supplying genuinely differentiating value, above and beyond commodity software. Today, enterprise IT is not about differential value, it is about maintaining and recreating software systems to support the same commodity operations that have been around for 25 years; CRM, ERP, Payroll,..

The myth must be challenged: that every organisation needs its own custom systems, 
no matter how ordinary, 
how universal are the operations that they support

The cost of this customisation is just too high and the risk it adds to a project are totally unjustifiable, but...

solutions for commodity operations must be off-the-shelf, without risk and at commodity cost

For this to happen, private strategy, localised to one organisation, or even one part of one organisation, will not do
  • It is too dependent on individual strategists, consultants and executives to endure
  • It does not draw on enough breadth of expertise to be authoritative
Private, local experts must be pulled together 
across the sector, across territories and
from service providers, vendor, supplier and integrator communities
The experts work together to create truly authoritative best practice

Enduring Authority

Standard InterOperations provides the methodology, language and tooling to create enduring discipline and authority from operational activities