SOA must be underpinned by better management

Most people know SOA is widely over-hyped (mainly by vendors seeking a new label to sell last years goods under, and ICT people who see a new set of technologies they can focus on rather than engage with the business). How on earth can we move to a more sophisticated, atomic, externalised, real-time view of services (lets forget about technologies and standards for now) - when the current management of services - which are simple, large-scale, mainly internally controlled, and seldom adjusted in real-time - is just typically pitiful (from requirements, through design, to implementation, operations and measurement).

In a CIO presentation on SOA in early 2005. I discussed the business drivers and technology enablers for SOA, the design challenges (perennial and new). It was drowned out the superficial presentations focused on irrelevant discussions around a plethora of technologies and standards.

I identified some things that make it hard e.g.

• absence of a well articulated technology vision
• tightly coupled, poorly bounded, systems producing fragility and insecurity
• technical fiddling with OTS components so that systems overall are expensive to maintain
• poorly managed outsourcing [i.e. the management of services]
• orienting technology architectures around systems/vendors/products/technologies rather than around the business and standards
• descriptions of the business that were incomplete, incoherent, inconsistent, inexplicit.

I suggested that the challenges are largely the same as they have been – but failure may become harder to hide (i.e. perceptions of the quality of businesses may be based on how well their systems perform).

That SOAs don’t present many overly difficult problems to well architected and managed enterprises, but that SOAs may be less forgiving to doing things in ways that have worked in the past (though they are not best practice).

To support my call for more professional and better management of complexity - I quoted British computer society "A striking proportion of project difficulties stem from people in both customer and supplier organisations failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry... Whilst the most pressing problems relate to the people and processes involved in complex IT projects, further developments in methods and tools to support the design and delivery of such projects could also help to raise success rates. In particular, basic research into complexity is required to facilitate more effective management of the increasingly complex IT projects being undertaken..."

To point out how little has changed I referenced what was said on architecture in a IBM systems journal from 1999:

• “Today, the most common model for solution development is based on an approach that we call ‘heroic’ ”.
  
• Goals: contain costs and risks, providing timely, adaptable, and customizable solutions.
• Challenges: complexity: driven by new technologies/standards; legacies; many applications/services; unique customization; external relationships (i.e. business network) change: a high rate of both business and technological change.
• Suggestions regarding the solution: patterns: a standard framework to support creation, reuse, and maintenance of design assets; discipline applied: to allow practitioners to base their development on patterns; reuse: of proven building blocks, applied systematically to enable asset-based solutions optimized to business goals. focus on: component topologies/interactions & management of: security, systems, performance; combine: HW, SW, products, assets, and services; establish: business reference models, default infrastructural templates/frameworks, contextual map for cataloging assets and knowledge, clear methods for making decisions
  

To indicate my dispair I quoted Hegel "what experience and history teach is this - that [we] have never learned anything from history, or acted upon any lessons they might have drawn from it". Though I would rather believe William Blake "Truth can never be told so as to be understood, and not believed"