Today, SOA SIG spring seminar was held in Innopoli II, the same place as last year. The theme of the day was “War Experiences in SOA”. Three great presentations were featured:
Samuel Rinnetmäki, The Finnish Centre for Pensions, provided insights into how to design service interfaces. He maintained that services can be discovered in use cases as well as in data stores. The contents of a service can be derived from conceptual models, vocabularies or ontologies. Operations on these data are typically CRUD functions.
Rinnetmäki argued for keeping the size of services small. Small services are more readily reusable and their implementation, testing, publishing and maintenance is easier. Only information that logically belong together should be fetched in a single service. Composite services of larger granularity can be built upon these elementary services, if needed. Reasons for this may be that information from various sources are used as a coherent set or calling of several small services bears too much performance overhead.
Jarmo Laine, TietoEnator, gave a presentation entitled “Implementing SOA — Experiences From the Trenches”. Indeed, he had a great war story to tell: a multi-year, international business process driven SOA endeavor that encompassed architecture, infrastructure, development process, service development, governance and domain data model.
The presentation brought a wealth of practical insight and sparked a good discussion. As his concluding remarks, Laine shared some of his lessons learnt in the spirit of “Do as I say, not as i do”:
- Enough time should be reserved in the beginning for the new tools, environments and resources as well as for defining the architecture. Vendor expertise and experience should be leveraged.
- Clear interfaces and responsibilities between architectural layers should be defined. First, a stub should implement the interface, then real implementations in several iterations.
- A development process/methodology suitable for SOA/BPM projects should be established. In the project, top-down and bottom-up considerations were balanced in the iterative meet-in-the-middle approach.
- Information of back-end systems and their constraints should be involved early in the analysis process.
- A standardized development guideline (e.g. naming standards, error handling, logging, common utilities etc.) must be created to unify and speed up the development work.
- Utilities and common technical services (e.g. logging, data type conversions, error handling) should be created to unify and speed up the development work.
- Supporting infrastructure should be in place and properly supported: version control, test management, change management.
- Test cases should be closely involved early in analysis and design phase to assure consistency in testing phases. Also management and ownership of related test data should be arranged and resources allocated early on.
The third presentation was given by Timo Itälä, Conceptia Oy. He proposed a top-down method for identifying the core process and the underlying core services in healthcare patient treatment. In order to find the connection points to the services, the process was only considered from the doctor’s point of view, abstracting out any other perspectives.
An interesting idea was to view treatment as a generic coarse-grain control-type service, implemented as an orchestration of more fine-grained action services that brought about the specifics of that treatment. According to Itälä, this pattern of core processes notifying the template-like control services that in turn orchestrate the action and entity services where the specific implementation resides is readily generalizable to other domains, of which he mentioned case handling in public sector organizations.
Another brilliant idea that Itälä put forward: from the process instances of a core process one can derive how much the process adds value; from the services one can reckon how much the core process costs.
