Oh No! We need another Practice Framework?
A few years ago I commented [in Beware the New Silos, ref 1 below] that in a complicated world we cope by specialization – and across the industry in general and in individual enterprises specifically we have created silos of our primary disciplines. The widely used frameworks and methods illustrate that common practice of discipline centricity. We don’t have to look too far for examples such as Enterprise Architecture (TOGAF), Governance (Cobit), SOA (separately by OASIS, OMG, Open Group), Agile methods (many and various), Business Process Management (BPM) and IT Service Management (ITIL). All of these disciplines, whether de jure or de facto standards, are all very narrowly focused with minimal treatment of how the disciplines might work together.
A good example is how Agile methods are tightly focused on application development and architecture is assumed to be an integral part of the Agile delivery project. Yet the reality in all enterprises is that significant aspects of architecture must be consistent at the domain or enterprise level. Another good example is how the three standards bodies OASIS, OMG and the Open Group were so divergent in their treatment of SOA, they commissioned a report [ref 2 below] to explain how these inherently duplicating standards and specifications relate to each other.
The level of adoption by enterprises or service providers of all these and similar practice frameworks and standards is of course highly variable. However it must be said that the very existence of the discipline based materials will frequently have some considerable influence on how enterprises organize themselves.
The thinking IT or business professional might also like to question just how up to date these frameworks are, and how they support today’s business goals, which for most of us have changed dramatically over the past few years. We might also speculate whether the education and certification ecosystems that feed off some discipline based frameworks may discourage rapid evolution. A good example is how TOGAF maintains the core architecture style as application centric and treats SOA as a style extension. This is really quite extraordinary because by now everyone knows and many accept the digital business is going to be inherently service oriented. In practice of course the TOGAF specifications are so extensive that making fundamental changes may be very difficult, but it demonstrates neatly how legacy capabilities become “part of the furniture”, not just in frameworks but also in delivered systems and services.
In effect what we did was to establish a service and solution delivery value chain that commences with the raw customer demand and finishes with the delivery and integration of some useful business capability, but crucially with a much improved balance between immediate solution needs and longer term strategic goals. And it’s this balance that many enterprises find extremely difficult to achieve.
The core problem is that disciplines are vertically integrated; set up to optimize the discipline at varying levels of abstraction. In contrast the value chain approach optimizes across disciplines in pursuit of overall value chain outcomes. And this is only achieved by value chain activities that encourage effective collaborations between multiple capabilities and disciplines.
In the beginning we (Everware-CBDI) had a framework – Service Architecture & Engineering (SAE). The name makes it clear this is a forward engineering approach, and whilst it was very strongly business driven, it would be fair to say that the business modeling components were less well worked than the architecture, design and delivery. And as described we have very naturally, as part of the process of supporting large enterprise initiatives, expanded the framework capabilities and embraced an inherently Agile approach.
The principles underlying the framework now include:
– business capability based modularity
– pervasive service architecture
– continuous modernization
– service evolution not (one time) delivery
– model driven architecture and development
– everything is inherently agile – iterative, evolving, and narrowly focused on specific business capability delivery.
So to answer my own question, we clearly need a new framework. But it’s a very different practice framework to the ones that we are are accustomed to.
In our natural evolutionary process we recognized that the original (SAE) framework was merely one component of a much broader body of knowledge and practices. The new framework is goal driven, not discipline driven and incorporates the entire value chain of capabilities. But the capabilities are not standalone, they are effectively services that are executed in a way that supports the overall business goals of the enterprise, domain or program. We refer to this as Service Oriented Application Modernization (SOAM).
Interestingly this is not a monolithic framework. It’s vital to treat the framework as a set of capabilities with defined services and dependencies. Some might say, “eating our own dog food”. In this way we don’t make the same mistake as legacy frameworks such as TOGAF, that are very difficult to keep current.
Finally what happens to the existing discipline based frameworks and standards? Of course they can be used in conjunction with the SOAM framework. But we do need to be careful not to just inherit monolithic capabilities. Increasingly we find it necessary to do this very selectively in order to use capabilities that fit and support the value chain. Perhaps in time the various disciplines will recognize the monolithic nature of their practices, and decompose and modernize into more goal oriented components. Meanwhile, in SOAM we have demonstrated that it is possible to reinvent the wheel.
Some SOAM Components:
Agile Service Factory
Conceptual (Agile) Business Modeling
SOA Reference Framework
Ref 1: Beware the New Silos