change

The organisation for Operational Integration Standards (OIS)

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

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 at, or 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 reuseand 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

Existing Methodologies, Tools and Standards

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 Telemanagement Forum (TM Forum) deals directly with management systems in telecoms (see Telecoms Cases Study)TM Forum has produced a set of framework standardsfor 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 haveframework 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'

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 makeEnterprise Architects a prime consumer of OIS

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