Skip to main content

SOA Pilot: Do we get second chance to do it right?

The SOA Pilot is a crucial part of the journey to SOA.

The result of an unsuccessful pilot could be the end of the SOA initiative.

Therefore you have to plan for successful pilot in order to transform the enterprise to SOA based enterprise.

However, the analysis of a SOA Pilot is not as simple as described above.

For instance, a well known SOA expert, Ronald Schmelzer, Zapthink's co-founder wrote a Zapflash titled: The Best SOA Pilots Don't Get the Services Right.

Ronald Schmelzer's thesis is that it is not important to get things right from the beginning because this kind of attempt will surely fail: neither the Business people nor the IT experts knowledge of the specific enterprise Business and IT context is perfect. In addition, the enterprise business requirements are very dynamic, so the probability of significant changes during Architecture planning, Services analysis, design and build is high. Therefore he argues that Agility is the most important goal of the SOA pilot because it will minimize the penalty for changes.

In my opinion minimizing the penalty for changes is very important, but not getting things right in the first steps could be very risky.

SOA is multi layered and complex therefore it is important to get right some aspects from the beginning, while the tolerance level for wrong things in other aspects on the first steps is higher.

In one layer SOA pilot is a specific project addressing well defined project goals similarly to other non-SOA pilot projects.

In a more abstract layer the SOA pilot is a first partial iteration of the SOA architecture, which may require refactoring i.e. its components and their relationships may be "wrong" and changed in the next iterations.


Things to make right from the beginning

  • Choosing the right pilot project

In this respect SOA pilots are similar to other projects pilots. Evaluate possible pilots using criteria such as Visibility, project team, Service Reuse potential in other systems etc..

A successful pilot with very low Visibility could be the last stop in the journey to SOA.

For my consulting assignments I am using a checklist based on my experience. Together with the enterprise's business and IT experts I map and rate potential pilot projects and choose the highest ranked pilot project.

  • Defining "right" measurable criteria for evaluating the pilot

  • Evaluating the pilot according to those predefined measurable criteria

  • Addressing real pain points which SOA is capable for addressing in relatively short time

  • Adequate organizational maturity level

Evaluate the organizational maturity level and if it is too low postpone the pilot and make

the necessary preparatory steps.

  • Metadata model


Things with higher tolerance level for wrong decisions in the beginning


  • Service functionality
  • Service Interface
  • Service Contract
  • Process steps
  • Service implementation
  • SOA initiative Organizational structure and roles assignments


Notice that higher tolerance is not a recommendation for unplanned or intentionally wrong architecture. It is a recommendation for balancing SOA planning efforts with expected future benefits and current limitations.


Summary

On one hand do not assume that you would be able to define a perfect, on the other hand a wrong SOA Pilot could be the end of the SOA initiative, because it could be the end of Business management sponsorship of SOA. Balancing is the key. You should allocate a reasonable amount of resources for good enough SOA Pilot. Distinguish between those elements which should be done correctly in the first time and those which could be corrected in the next iterations.



Comments

Popular posts from this blog

The mainframe: still alive and kicking

Recently, I was interviewed by  Pcon   (unfortunately the link points to an Hebrew only site) as part of debriefing on Legacy Systems.  Pcon is an Israeli company investigating IT topics by quoting professional articles and interviewing experts. They publish the results of the investigations including practical recommendations. This post is mainly about topics raised by me during the interview, but not included in the debriefing, which will be published.    What are Legacy Systems? The term Legacy Systems refers to old application systems and/or veteran technologies still in use.  Usually, the term Legacy Systems is associated with: 1. Mainframe Hardware e.g. IBM System z and its Operating Systems or Proprietary Servers and Operating Systems such as HP Alpha and OpenVMS Operating System, IBM AS/400 and OS/400   Operating System. 2. Development and Production Environments, e.g. COBOL , Natural and DBMS systems such as Adabas  ...

Will Business and IT Aligned?

For decades we are talking about closing the gap between business and IT , but the gap is still as wide as it was. In the beginning of the ERP era, we focused on aligning Business Processes and Core Systems, but in most enterprises we failed. SOA was the next alignment promise: defining the SOA Services in Business boundaries instead of Technical boundaries, should narrow the gap. However, despite of SOA Business Value ( Agility and Reuse )  in most enterprises,  the large Business-IT Gap remained as large as it was.  The IT Community aimed at the next alignment attempt: SOA is technical and BPM is its Business related complement.  Will the current BPM based alignment attempt succeed? I do not know, but Nick Heath's article  titled: Stop doing what the vendors tell you, CIOs told , published in  Tech Republic , suggests that the root of the problem is not Technological .   Stop Doing What the vendors Tell You Nick Heath's article is based ...

Vendors Survival: Will Software AG Survive until 2019?

This post is another post in the Vendors Survival series following posts on Microsoft , Google , HP , Sun and EMC . On July 14 th Software AG and IDS Scheer announced that Software AG is going to take over IDS Scheer . The intended acquisition is an opportunity to add another post in my Vendors Survival posts series. A brief history of Software AG Mainframe products Software AG is larger than any German software company except SAP . It was established in the Mainframe age (in 1969). I worked with many customers, who used and some of them are still using, its two flagship products Adabas and Natural . Although these products support many platforms, their main platform is IBM Mainframe. Adabas is a database and Natural is a development environment. Like other pairs of Database and Development Environment in the mainframe environment (e.g. Ideal and Datacom , Mantis and Supra) build by the same vendor, they are tied together. As a result, although it is possible t...