Saturday, March 1, 2008

SOA VDS – AmberPoint Example

ZapThink's analyst David Linthicum wrote a zapflash titled: Avoid Vendor Driven Architecture (VDA).In this Zapflash David Linthicum describes two prevailing SOA implementation patterns: buying SOA products from existing vendors and letting these vendors to design and define the solution.

According to his analysis the outcome of such approach will be a failed SOA implementation because SOA is Architecture and not Technology, so the expectation of out of the box magic technology solution to improper architecture is both unrealistic and misleading.

As an experienced consultant I would add to this that whatever the technology or architecture is vendors are biased towards their own solutions and vendors employees rewards are dependent upon sales.
This post is not about VDA but about VDS or Vendor Driven Surveys. Same as Architectures build by vendors are suspect to bias towards their solutions; results of Surveys executed by vendors probably will be biased towards their solutions.

AmberPoint is a leading SOA Management and Governance products vendor. The company has impressive line of products and partnerships (e.g. Microsoft, BEA, Software AG) for competing with companies like IBM, HP and CA.
On January 2008 the company published a survey titled "State of SOA Adoption Survey".The survey results show more mature and successful SOA adoption than other surveys. Unsurprisingly, the survey results show that AmberPoint's customers SOA initiatives are more successful: approximately 41.3% of AmberPoint's customers reported that their SOA initiatives met all their goals in comparison to 28% of non-customers.

A Skeptic general results analysis
Let us try to interpret survey results in non VDS attitude.

Issue 1: The stage of SOA adoptionResults:
Internal multiple Department – 22%
External – 11%
Internal Single department – 9%
In Development – 22%
Experimental – 36%
My interpretation: SOA is implemented by only a third of the survey participants (Internal multiple Department and External). The others are in early stages of implementation. Notice that 100% of the survey participants declared a SOA initiative in any stage. This could be a vendor driven result and undoubtfully biased. I am aware of many enterprises which has not begun yet a SOA initiative. The reason for this finding: the survey participants are all IT professionals that "have an understanding of SOA". Those engaged in a SOA or SCS initiative are those who think they have an understanding of SOA.

Issue 2: meeting SOA Goals
The survey results show none of the respondent labeled his enterprise SOA initiative as a Fiasco and only 1.5% claiming that they did not complete the project and therefore did not achieve desired goals. 38% met all their goals and 60% met most of their goals.
Are these initiatives Real World initiatives or these initiatives executed in heaven?Were have all the damages of billions of dollars of failed SOA initiatives due to lack of adequate Governance gone (I read Research Notes by Gartner Group and by Burton Group including these billions of dollars estimation)?
Notice:
  • Failures admitting are rare in IT and SOA is not an exception.
  • Few years ago I looked for SAP ERP Case Studies and found only one failure. Unsurprisingly, the roots of the failed initiative were explained by the succeeding new project manager replacing the previous fired project manager.
  • Success of SOA initiatives gaols should be measured by quantified Business related benifits. Is the high success rate a result of such benefits in early stages adoption or the result ofIT only related goals which are not related to Business? Was the "success" a result of IT only SOA initiatives including IT only goals?
  • What was completed successfully: A SOA Project? Probably, yes, A complete Architecture? Probably not. Will the temporary success of a project or few projects turn into an Architectural disaster due to lack of Reuse, No Agility and overwhelming Complexity?
In summary, it seems that the high success rate reported is reflecting more biases of IT professionals involved in SOA initiatives than actual success.

Issue 3: Non-SOA Components involved in SOA systems
ERP and Mainframe Components are the most frequent answers. This finding is reasonable and manifesting the challenges of building a complete SOA architecture including existing Legacy and ERP and CRM systems.

Issue 4: Issues best addressed by SOA
The most prevailing isssues cited by the participants in the survey (in descending order) are: Inflexibility, Restricted Information flow due to Stovepipes, Lengthy Development Cycles and Costs.
Well Inflexibility or Agility is a common SOA justification aligned with Business expectations of Responsive organization.
What the hell are Stovepipes as an issue? StovePipes are a reason for lack of flexibility, high costs and other issues and not a reason only for restricted information flow.
Notice that improved maintenance is not a common answer (Was it posted as a valid answer option?). The benefits of improved maintenance are more significant than the benefits of shortening Development Cycle because maintenance efforts and costs consume 70% to 80% of IT budgets.
Issue 5: Topics to be addressed for successful SOA
The most frequent obstacles facing SOA implementations are in descending order:
Lack of SOA Expertise (67. 6%), Organizational reluctance to change from the status quo (58.9%), Security (51.8%), Challenge of managing SOA systems (48.5%) and Immaturity of SOA standards (43.8%).
The findings are reasonable. Notice that Organizational issues are facing SOA initiatives. Not all SOA challenges are technological.
The only missing item is SOA Governance. According to analysts research lack of Governance is one of the main reasons for SOA initiatives failures. I would expect a 50% or more votes for that topic.
Is it because the SOA experts participating in the survey think of SOA Governance as SOA Management?

The common link
The common element to all results is the participants labeled by AmberPoint as "IT professionals that have an understanding for Service Oriented Architecture (SOA)".

My discussion of Issue 2: meeting SOA Goals raises some of the possible biases due to IT only surveys, but it is not the only limitation: as discussed in Issue 1: The stage of SOA adoption most of the survey participants are probably participating in a SOA Initiative execution and therefore enterprises without ongoing SOA initative were excluded.

Vendor specific findings as VDS
AmberPoint specific results section is for sure Vendor Driven.The results are reasonable: A larger percent of AmberPoint's customers reported more SOA applications in Production (Nearly half of the non customers reported having 10 or less than 10 services in production) as well as more successful implementation (met their goals).
The devil is not hidden in the details; it is hidden in the interpretation.The vendor driven comparison is between AmberPoint's customers implementing the company's Management and Governance tools and between all other participants.
The non-customers are heterogeneous group composed of the following enterprise profiles:

1. Enterprises in Early Stages of SOA initiative
In many cases they did not implemented yet any Management and Governance tool (perhaps they do not need such a tool in this stage). 
Surely they report less successful and less sophisticated SOA implementation than enterprises in more
advanced stages.

2. Enterprises implementing a large number of services without Management and Governance
tools.
Would anybody expect these enterprises to be successful? Surely, they are leading candidates for SOA initiative failure. No doubt that AmbrePoint's customers will be more successful than these enterprises.

3. Enterprises implementing other vendors' tools.
Comparison of AmberPoint's customers to these enterprises is the interesting comparison.
In short the comparison should be between enterprises in the same sophistication level divided into three groups: AmberPoint Customers, Competitors Customers and Enterprises which did not deploy any SOA Government or SOA Management tools.

Another point raised in this section of the survey is: AmberPoint Customers deployed its tools in early stages even in Development. This point is Vendor driven, suggesting that adopters of SOA Governance and SOA Management tools at early stages are more successful.

In my opinion Governance and Management implementation at early stages is improper and costly.
The only reason for implementing these tools in an early stage is related to most frequent obstacle Lack of SOA Expertise (Issue 5). Due to lack of expertise tools implementation too early is better than tool implementation too late. However, the best timing is the implementing these tools when needed consulting by experienced SOA experts is capable of planning and implementing these tools just in the right time.

There is no need for such tools in early stages during SOA Pilot. If the SOA Pilot is planned and executed correctly, at Pilot completion a SOA application will be in production. In that case, Surveyed Enterprises completing the Pilot will be classified as In Development or Experimenting (Issue 1).

Conclusions
  • Surveys can be vendors driven (VDS).
  • Vendors Surveys should be evaluated carefully same as Vendors Tools and Vendor Architectures
  • AmberPoint's SOA Survey is vendor driven. The interpretation of the results is misleading.
  • Some of the findings are valid such as non-SOA components involvement (Issue 3) and partially Issues 4 (Issues best addressed by SOA) and 5 (Topics to be addressed for successful SOA)
  • Overcoming the challenge of Lack of SOA expertise (the most cited topic) is a key for successful SOA implementation. It is recommended to deploy external consulting by experienced SOA experts. This conclusion is based upon other non-vendors surveys (e.g. Aberdeen Group found that Best In Class organizations tend to use outside expertise more than other organizations).

No comments:

About Me

Share on Facebook

Labels