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.
Which brings me right back to the question – do we really need another practice framework?
For several years now I and my colleagues have been evolving and implementing a different transformation approach. Initially we focused on SOA. And as many will know, we were fundamentalists in this area and we published detailed and open meta models for the service architecture and delivery life cycle based on “everything is a Service”. This approach has been very successful, particularly when the service architecture conforms with a strong layered reference architecture and rigorous componentization of services and business capabilities. But because we always knew that there was no such thing as a green field, we worked to harvest knowledge from existing systems. And over time we made a virtue of this, focusing on continuous modernization as a matter of principle. More recently we have further evolved the approach to embrace Agile and MDD, establishing an agile service factory and generating code from rigorously defined service specifications.
But we found many of our customers struggled to implement a strategic SOA because business change was implemented project by project. And sure enough, project specific services and SOA have become ubiquitous; you might say almost a contradiction in terms. To counter this we advise that the demand management process should be complemented with demand shaping that decomposes the customer solution based demand to discover requirements for services and other sharable components and then re-aggregates the raw component demand into related projects that coordinate the delivery of business solutions and strategic services.
But even though this approach works well at a project and technical level, we frequently encounter difficulty in persuading business stakeholders to balance short term advantage with more strategic goals. And we recognize this is because business stakeholders habitually make investment decisions on flawed criteria, because the ROI model only looks at the solution in isolation, rather than looking at the strategic opportunities to implement better architecture, address portfolio rationalization and reduce technical debt. This prompted us to find ways of working more effectively with business stakeholders. To encourage them to understand and indeed influence the conceptual business model and to understand a richer underlying business model that reflects a more comprehensive cost benefit model. And this helps to bring LoB managers into the conversation on demand shaping – balancing immediate solution requirements with longer term goals.
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.
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