Skip to main content

SOA and SCS

The presenter in the 15th meeting of the SOA Forum of the Israeli Association of Information Processing (June 2007) was Brent Carlson, Founder and CTO of LogicLibrary who was named to InfoWorld’s ranking of the Top 25 CTOs in business today.
His presentation topic was: Service Lifecycle Governance: Principles and Best Practices.
Unfortunately, he was stuck in a traffic jam, so I talked to the forum members until his arrival.
I discussed the current status of SOA implementations in Israel. The two main points were:
1. Only few enterprises have a significant SOA production implementation
2. I am able to identify two enterprises that will surely fail in their SOA imitative just
by a short discussion with them.

One of the participants argued that my first point is not valid. He said that he is aware of enterprises implementing hundreds of Web Services.
I answered that implementing hundreds of Web Services is not necessarily implementing SOA.
Unsurprisingly, Brent Carlson's opinion was similar to mine when asked the question about these enterprises having hundreds of ungoverned Web Services. Brent named the ungoverned hundreds of Web Services: A Bunch of Services (ABOS) and not SOA.
I use the term So Called SOA (SCS) for describing initiatives which may be called SOA, may include Services (usually Web Services) Interfaces and Processes but do not form coherent Architecture.

The following attributes are common to these SCS implementations claimed to be SOA implementations:

1. No measurable Business Value measured by Return On Investment (ROI) or other criteria.
2. No Business and IT alignment
3. Low or no Reuse
4. No Agility or Flexibility for Business driven changes

Linking the last paragraph to my second point in the discussion about the initiatives I mentioned in the second bullet, I would say that I identified these two initiatives as SCS. However, there are a lot of definitions to SOA and SCS may be classified as SOA according to some of them.
When predicting that these enterprises will fell I did not predict that they will not complete SOA projects, I predicted that their implementations if realized, will be characterized by the four attributes of SCS cited above, especially the first attribute.
SOA initiatives costing more than returning in Long Term are failures.

The following characteristics of SOA initiatives may serve as "red lights" (warning) alerting creation of an SCS implementation:

1. Information technology (IT) only initiative.
No Business management involvement in the initiative.

2. Inadequate Organizational Maturity
Organizations which lack the required maturity level should postpone their SOA initiative and try to achieve adequate maturity level.
Do you expect an Enterprise which did not succeed in building any Enterprise Architecture to succeed in paradigm shift to abstract and layered SOA architecture? Of course not, a thousand miles walk begins in a single step.

3. Too ambitious effort
Big Bang style projects or three or four concurrent SOA pilots could be an indication for a doomed to failure initiative.

4. No usage of external expertise
"We do not need consultants" attitude of an organization which never implemented or planned SOA may result in creating non-SOA architecture e.i. SCS architecture.

5. Too Technical initiative
The term too Technical refers to the point of view that SOA is only collection of technologies. It is not. The result of the SOA initiative could be installation of SOA infrastructure products (ESBs, Registries, Application Servers etc.) without significant Services usage.
An example is an enterprise with multiple ESB's tools from various vendors, with no production SOA implementation. I let some of their leading experts know about another Infrastructure SOA tool installed in that enterprise.
How did I know about a SOA software product installed in that enterprise?
Well, I read a White Paper and asked the vendor for additional information. The vendor told me that although they do not have yet official distributor in my country they already installed the product in that enterprise.

Two questions related to this post will be discussed in next posts:
· Defining SOA
As there are many SOA definitions (some time incompatible and contradicting) the discrimination between SOA and SCS could be related to the SOA definition selected.

· What are the Worst Practices of SOA?
Worst Practices could lead to SCS failures as well as to other failures.

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