Selecting an SOA Delivery Strategy
Recently I wrote a scientific paper with Joeri Terlouw and Slinger Jansen on “An Assessment Method for Selecting an SOA Delivery Strategy” based on Joeri’s master thesis.
The article can be downloaded from http://www.icris.nl/wp-content/whitepapers/SOAdelivery.pdf, the full master thesis from http://www.icris.nl/wp-content/whitepapers/thesis_joeri_terlouw.pdf.
Let’s have a look at the abstract.
Abstract
Organizations should carefully consider which SOA delivery strategy, for instance top-down or bottom-up, to follow in migrating toward a service-oriented environment. Selecting a suboptimal strategy can result in spending more time and money than required, or in complete failure of the SOA project. However, selecting one is not easy. Organizations are often unaware of the existence of the different strategies and their situation-dependent pros and cons. Also, it is impossible for organizations to make a well-founded choice since a method for selecting an SOA delivery strategy is lacking. This paper bridges that gap by proposing an assessment method to select a delivery strategy based on specific characteristics of an organization. The method comprises a matrix that includes the influencing factors with their corresponding value ranges, and a weight calculation to determine their impact. Another contribution of this paper is the elicitation of four different delivery strategies that have never been chartered properly.
Making a service catalog work: 3 do’s and don’ts
A couple of years ago many organizations were taking their first steps into the world of SOA. Their main concern was which ESB to choose. After deciding whether to use the ESB from Tibco, Cordys, IBM, Oracle, or Microsoft, they thought the hard part was over. They started building web service like crazy and ended up with JABOWS (Just A Bunch Of Web Services) instead of a decent SOA. At the moment, I’m getting a lot of questions from clients regarding service identification and service specification (and SOA governance, but this will be topic of another blog post). Service identification is the process of determining which services the organizations actually needs. A while ago two colleagues and I wrote an article about ten frequently used approaches (http://www.soamag.com/I13/1207-1.asp). You’re welcome to comment if you see any approaches we did not describe. Of course, an organization cannot implement all the candidate services at the same time, nor does it need to. It starts out with the services having the highest priority and gradually builds its service portfolio. Now, as the portfolio grows, it is hard to keep track of the functionality of all these services. The service catalog becomes an important artifact for the service consumers to discover services and determine whether or not they fit their requirements. Even if you don’t ‘believe’ in the concept of reuse: consumers need a precise and unambiguous service specification to be able to use the service. If provider and consumer have different expectations of the behavior of a service, you’re bound to get problems. Let’s have a look at three do’s and don’ts for the service catalog.
Do’s:
1) Appoint a service catalog manager
A Business-Oriented Specification for Services
This is the abstract of my article for the CIAO workshop at the CAISE conference. Please let me know if you would like to read the complete article (published by Springer).
By far the best known standard for registering and searching for services is the UDDI. A great weakness of this standard is its technology-driven way of specifying services; it is still inadequate for specifying the majority of aspects that are relevant from a business point of view. This stands in sharp contrast to the main premises of SOA, i.e. increased flexibility by the reuse of services and better business/IT-alignment by speaking the same language. A more comprehensive approach to specifying services is the business component specification framework. One of the aspects that needs to be specified according to this framework are the business tasks. The framework, however, does not define precisely what a task is and how a task should be identified. In this paper we propose taking the enterprise ontology as a starting point for specifying these tasks. Furthermore, we demonstrate our approach using a life insurance company case.
The First International SOA Symposium
| October 7, 2008 | to | October 8, 2008 |
October 7 and 8 the First International SOA Symposium took place in the Amsterdam Arena (the soccer stadium, home of the Dutch soccer club Ajax). Let me give you a short impression of this event by describing the presentations I attended (providing just a very limited view!).
Thomas Erl (SOA Systems) opened the conference with his keynote “The State of SOA”. Also, he launches two of his new books at this event: “SOA Design Patterns” and “Web Service Contract Design and Versioning for SOA”.
Dutch National Architecture Conference
| November 25, 2008 | to | November 26, 2008 |
November 26 my colleague Art Ligthart and I will organize the SOA track of the 10th (!!) edition of the Dutch National Architecture Conference (LAC). The program is as follows:
11.45 – 12.30: A Canonical Data Model for a Common Semantics
Drs. Guus van der Meulen, Systeem Integratie Specialist, Ordina
12.30 – 14.00: Lunch
14.00 – 14.45: A Case Study at the IND (Dutch Immigration and Naturalisation Service)
Simone Dobbelaar, IND
14.45 – 15.00: Break
15.00 – 15.45: SOA belongs to the professional sports leagues! About the (un)usefulness of architectures and methods.
More info can be found at this website: LAC website.
CIAO! meeting, Antwerp
| November 20, 2008 | to | November 21, 2008 |
Motivation
In every university or research institute that belongs to the CIAO! Network, there will in principle be doctoral students that are supervised by a professor who belongs to the CIAO! Research Staff. In order to meet the quality standards of the CIAO! Network, these students should be guided to improve their work as much as possible. To this end the CIAO! Doctoral Consortium is constituted.
Objectives
The first objective of the CIAO! Doctoral Consortium is to encourage doctoral students to write, submit and present papers and to help them to improve the quality of the papers. The second objective is to be a platform for meeting each other as well as the members of the CIAO! Research Staff.
Organization
The CIAO! Doctoral Consortium consists of all CIAO! Doctoral Students and all members of the CIAO! Research Staff. Because of the geographical distribution of the CIAO! Network, it is practically impossible to let them meet all together. Therefore a local CIAO! Doctoral Consortium will be set up at every university or research institute that belongs to the CIAO! Network. Out of the local CIAO! Research Staff a Referee Board is selected. This board may invite persons from a CIAO! Company to be member of the Referee Board, provided (s)he has a doctoral degree. One of the members of the Referee Board is appointed to be the chair.
Mode of Operation
A local CIAO! Doctoral Consortium meets as often as is necessary to have every student present a paper once per year. At such a meeting of one full day, at most four students will present a paper. This guarantees that there is always sufficient time for discussions and for fulfilling the platform function. A presenting student has to distribute the paper (of 10-12 pages) in advance such that all members of the consortium have sufficient time to prepare for the meeting.
The MVVEIS workshop at the ICEIS conference
| June 12, 2008 | to | June 13, 2008 |
Yesterday and today I was at the workshop about Modelling, Simulation, Verification and Validation of Enterprise Information Systems (MVVEIS) at the International Conference on Enterprise Information Systems (ICEIS). I was here to present my paper “Comparing Methodologies for Service-Orientation using the Generic System Development”.
I especially enjoyed the keynote presentation of Jean-Marie Favre titled “Engineering the Power of Babel the Community Engineering and Software Language Engineering”. It was about software languages in a very broad meaning. When we speak about software languages we tend to focus very much on programming languages like .NET, Java, Cobol etc. Jean-Marie took quite a different approach and took into account all types of languages that have to do with software. This included, for instance LaTeX, HTML, and OWL. He also stated that languages for communicating ABOUT software (e.g. UML, Z) are software languages. In fact, he regarded all software languages as being meant for humans (which is of course true! A computer only “understands” 0010101011101101). Jean-Marie is trying to create a link between the fields of computer science and linguistics. He defines the field of software language engineering as follows: the application of a systematic, disciplined, quantifiable approach to the development, use, and maintenance of these languages.
If you’re interested, take a look at this site: http://planet-sl.org
Why BPEL is a wrong name
Looking at the name Business Process Execution Language (BPEL) one would expect that it is a language for executing business processes. In reality BPEL is a standard for service orchestration. There is a huge difference between the two.
Let me start by making clear what a business process is. Probably the first person to describe a business process was Adam Smith (1776). He described it text-based without the use of any process diagrams.
”One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”
Service interface specification is not enough
Abstracting the functionality a service offers from its implementation is the main idea of SOA. A potential service consumer does not care whether a service is written in Java, .NET, Cobol or is even performed by a human actor as long as he knows what the services does. Many people think an interface specification is enough and that UDDI is a great standard for discovering services. This is, however, not the case.
