Reflections on SOA

One way I expand my professional knowledge is by reading "good" books on software engineering; those books that are either commonly referenced classics or highly recommended (see sidebar for short reviews of some recommended books).

I have recently been reading "Pattern-Oriented Software Architecture, volume 1", by Buschmann, et al. (commonly referred to as POSA), which includes one of the early (1996) formalisations of the Layers pattern.

What does this have to do with SOA?

Well, the topic came up in a recent training course of what is SOA / what is a service. The training course level was such that only a basic description was appropriate, but what immediately jumped to my mind as important is that a Service Oriented Architecture usually consists of both coarse-grained business services, as well as fine-grained implementation services (often with a workflow component as a means to aggregate them).

Although a lot of knowledge can be learnt on the job, being passed on by other software engineers, it can sometimes be an eye-opener to actually go back and read the original description.

In this case, when defining an Service Oriented Architecture I would strongly suggest reviewing the Layers pattern and think about how your services might be structured in layers. Think about the different abstraction levels you have in your system, name the different layers and assign tasks to each of them. In particular, think about some of the issues from step 4 ("Specify the services"), and step 5:

"5. Refine the layering. Iterate over steps 1 to 4. It is usually not possible to define an abstraction criterion precisely before thinking about the implied layers and their services. Alternately, it is usually wrong to define components and services first and later impose a layered structure on them..."

One way I have seen service oriented architectures broken up is with different layers for Business Process Services, Business Function Services and Data Services, each with their own responsibility and features.

For example Data Services encapsulate business data entities specific to a slice of the business and are usually atomic, stateless, don't change often and are highly reusable, whereas Business Process Services are designed to encapsulate business process and workflow, are implemented through a stateful orchestration and will change more often.

There is a good diagram of how the different abstraction levels (Layers) of services can interact in "Understanding Service Oriented Architecture" in the inaugural January 2004 issue of the Microsoft Architecture Journal.

A kernel of software engineering practices

Ivar Jacobson has written some recent columns for Dr Dobb's Journal about the similarities between different development methodologies, and specifically the difference between processes and individual practices.

The thread has picked up and gain some momentum through columns by other well known industry figures such as Scott Ambler:

A key part of Ivar's proposal is that what's really important is not so much the overall method but the individual practices.

This is similar to Steve McConnell's analysis,  in Code Complete Second Edition, of the improved defect removal rates of methodologies such as Extreme Programming, which are really just the expected effect of the combined individual practices.

Ivar also talks about a "kernel" of practices -- activity and work patten spaces (groupings) and "alphas" (prototypical deliverables). Without going through the detail of EssUP (Ivar's lightweight method based on this), the kernel consists of the following:

Process Area Activity Spaces
(Things to do)
Alphas
(Things to produce)
Competencies Pattern Spaces
Customer
  • Understand the Need
  • Ensure Stakeholder Satisfaction
  • Accept the System
  • Opportunity
  • Customer Representative
 
Solution
  • Specify the System
  • Shape the System
  • Implement Software
  • Test the System
  • Release the System
  • Specified System
  • Implemented System
  • Executable System
    • Test
  • Analyst
  • Developer
  • Tester
 
Endeavour
  • Establish Project
  • Steer Project
  • Support Team
  • Conclude Project
  • Team
  • Backlog
    • Task
    • Defect
    • Change
  • Project
    • Risk
  • Way of Working
  • Project Lead
  • Collaboration
  • Control
    • Feedback
    • Lifecycle
    • Measurement
    • Planning
  • Organisation

 

Different processes, e.g. EssUP, Scrum, MSF, etc, can then be mapped to this kernel of concepts.

 

Joined Readify

I joined Readify this week.
 
Readify are a specialist Microsoft.NET consulting firm and have been at the forefront of Microsoft technology since I did training with them in December 2001, on .NET 1.0 beta.  They have developed their reputation as experts because they strongly support professional development of their staff, allowing them to skill up on new technologies "ahead of the game".