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.
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