5 things SOA vendors are missing, and 5 things customers need

(prompted by 5 things SOA Vendors are missing)

This item is refreshing direct and points out that SOA is an architecture (a complex distributed architecture, leveraging many of the traditional EA concepts) and or a meta an architectural pattern. What is needed are products that are elements in an SOA, not products that in and of themselves aim "to be" the SOA. It says to Vendors:
1. Make sure your product works.
2. Make sure you know what SOA is - most who sell SOA technology don't understand the first thing about SOA and typically play "buzzword bingo" reciting terms e.g. agility, reuse
3. Get wise about the approach to SOA - how should each customer approach SOA.
4. Don't sell yourself as "one stop SOA shopping." - in reality, nobody is a one-stop SOA shop.
5. Consider the future - Architectures are journeys, not projects. You need to think long term when you work with a customer and a customer's architecture inserting yourself at key points in the process

What Customer need is people who:
1. Know how to make the product works. Or at least can confirm they don't work, or they are not working as they are meant to. This usually comes from someone who has worked with a number of products of each class.
2. Know what SOA is - often these will be people whose goal is not to sell a particular technology and rather focus on what the business aims to achieve.
3. Are wise about the approach to SOA - and know how to engage with customers at many different stages (before they need a product set, when they do need and are selecting a product set, when they have a product set).
4. Know "one stop SOA shopping." - doesn't make sense, and at it worst ends up in the customer being captured by the vendor (which is most vendors' goal)
5. Can consider the future - will be around for the journey, and are able to think long term when looking at a customer's and a customer's architecture.

It is staggering to think that Customer's would look to the major product vendors and outsourcers for independent advice in this area.

Linking SW Architectures with Enterprise Architectures

(prompted by an interface between Lattix and Troux)

In an Enterprise Architecture (e.g. Troux) an organisation would record its applications (hundreds to thousands). The level of detail they would record about applications would vary. Often not much detail is available (i.e. to hand) regarding the internal aspects of the applications (i.e. its internal modules/components and how these inter-relate).

Application portfolio optimisation work is typically focus on rationalising the set of applications at a macro level (e.g. often duplication of function arises as a result of mergers).

A next level of analysis would involve looking at the modules (or components that application is constructed from). This may present opportunities for more atomic refactoring of the application portfolio and will insights into candidates for service representation.

When an application is analysed using Lattix (SW architecture analysis) - we can use the information provided by Lattix (based on an examination of the actual code) to augment the information in the Enterprise Architecture (i.e. add the modules).

See also Enhancing EA

Thinking SOA (are the issues really that new?)

(prompted by thinking SOA)

I agree with the conclusions i.e.

- SOA is a core aspect of EA (and EAs that get this will get SOA more quickly)
- SOA does have new some challenges especially around lifecycles, service quality management and inter-party agreements - but think that in but in many cases the challenges have always been there - now it is just harder to bury your mistakes.

I disagree with some of the things implied i.e.
- Good EA has always been about interoperability (driven by business goals such as agility) - and never about layers of technology. So this is not something new with SOA.
- "Traditional enterprise architecture" is Technology Architecture (NOT EA). Many of frameworks, methods and tools - have been manifestly unsuited to real EA for a decade (hence the how few really success EA projects there are). So this is not something new with SOA either

See also: EA/SOA a shareholders issue?

EA and SOA shareholder issues?

(prompted by: Could Lack of SOA Drive Shareholder Lawsuits)

[WIP]
I can't really bring myself to agree with the conclusions in this item - that the absence of good EA's could drive lawsuits.

Key assertions from this:
1. Shareholders are looking at enterprise architecture efficiencies
2. Many major public companies don't have efficient enterprise architectures
3. Stockholers assume that IT/Architects, are doing their best to make the architecture optimal for the business. However, in many cases, that is not true.
4. Years of neglect, lack of talent and understanding, etc. have created dysfunctional EAs.
5. Bad EAs hindering corporations ability to make money and return value to shareholders
6. This could drive lawsuits where bad EAs may need to explained in depositions (during law suits).
7. SOA are not a fix for bad EAs - they will just make bad ones worse.
8. What is needed is a long term cogent SOA strategy and this is complex and hard, but worth it if you do it correctly.
9. Shareholders may ask for complete audit be done on the methods and practices in building an effective EA

Comments re the points above:
2, 3, 4, 5, 7, 8 - I think are fairly well known i.e. - Most major enterprise don't have efficient EAs and years of neglect, lack of talent/understanding are a cause. Few IT orgs are doing their best to fix this. Bad EAs do hinder ability to return value to shareholders and SOAs will make bad EAs worse (adding complexity) and what is needed is a long term cogent strategy. These strategies and architectures are complex and hard to do.

I think 1/6 - are unlikely. That shareholders will look at architectures and focus law suits on the deficiencies seems improbable to me for many reasons.

The last point 9 - may well make sense. They may ask for audits to be done on the methods and practices in building an effective EA But the challenge will be finding auditors with the knowledge and experience to do the auditing who are actually impartial e.g. most of the organisations that are recognised as leadings in EA seem to have unignorable conflicts of interest i.e. they are primarily vendors of systems or software; they generate huge incomes from the implementation ERP systems (often following services associated with "impartial" evaluation of ERP solutions); they don't really understand some of the issues associated with EA.

See also SOA's must be underpinned by better management

SOA and EA - IBM's lessons (my summary)

(provoked by: IBM's item on EA and SOA)

My summary of the lessons
1. SOA addresses only a subset of EA domains (i.e. services) and can leverage other EA domains (e.g. information architecture, system management, operational architectures, rules/decisions architectures, function/process architectures, control architectures etc.).
2. SOA governance should leverage EA governance. The service model(s) should be developed and maintained by the SOA experts just as other aspects of an EA should be developed and maintained by their experts e.g. data/information, architecture, rules/decisionms, process arch, systems etc. The Services model(s) should be referenced from the EA and architecture review boards should consider services governance.
3. Ideally the funding models for services (and common infrastructures, and functions) should be based on an enterprise level not a project level.
4. SOA infrastructure is an enterprise asset (just like any other infrastructures e.g. information/data, rules/decisions etc.) and should be managed as part of the enterprise system management and comply with enterprise policies e.g. security.

(see also: SOA's need to be underpinned by better management)

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"