January 2009 - Posts

The foundations of Service Oriented architecting
Mon, Jan 5 2009 8:31 PM

A lot has been said about the foundations of Service Orientation. But still, way to often I see people deciding to use SOAP/XML and thinking they are doing Service Orientation. You might recognize the following examples I see as getting Service Orientation wrong:

• Services are very technically oriented: service-designers know they should do something on business alignment, but say that the business doesn’t get it and using web service standards is the best we can.
• Services are point-to-point interfaces: ‘services’ are designed on the fact that some information needs to go from system A to system B and therefore a service needs to be created. They then call the service something like the InterfaceInformationService or the SetSomeDataService. Also recognizable by the fact that they always have one operation.
• Services with little responsibility: services are designed around one function and are therefore responsible for only a small bit of data.

I think that, when you talk about architecting Service Oriented solutions, the architecting part is the hardest part. There’s nothing special about that. It’s just decomposing systems into subsystems with clear coherent responsibilities and logical interfaces. But the decomposition is at a higher, abstracter level, which makes it harder. When decomposing applications, you assign responsibilities to concrete components. When decomposing systems, you assign responsibilities to abstract services. But still you need to be concrete and accurate about the responsibility of the service.

Clearly defining the responsibility of the service is the best way to get a service contract right.

Imagine you are designing an Order Management service (OM) in an environment where there is an Customer Management service (CM) available. Now you have to decide whether your OM knows the CM. Whether you want that is based on the way you assign responsibilities. Now let’s say that it’s the CM’s responsibility to manage a customers credit rating. Your options:

1. If you make the OM responsible for validating the customers credit rating before accepting an order, your OM will need to know the CM.
2. You could also decide that it’s the service consumers responsibility to perform a credit check (the service consumer could very well be a process manager) and the OM doesn’t need to know the CM.

The first option is more strict. There is now way to create an order if the customer doesn’t have a required credit rating. The second option is more flexible, the OM can even handle orders for customers unknown to the CM (imagine merger scenarios). I think that no one option is better than the other, it depends on where you assign responsibilities and that is driven by architecting requirements.

More generally I think that in any service interaction pattern there are three main parties:

• The service consumer. The service consumer knows the service provider. It knows it’s contract, it’s policy, it’s endpoint location. Ideally, the service provider doesn’t know the consumer.
• The service provider. The service provider defines the contract and provides the implementation. It’s implementation might (and often will) include a datastore.
• Other services. These services are used by the service provider to delegate work that’s necessary to realize the responsibility of the service. The service provider plays the role of service consumer to these services.

Deciding on the interacting pattern between the parties is the key to good service contract design. So far, this looks pretty straightforward, isn’t it? Well, it’s often harder then it looks. It’s easier to directly contact  a service to get some work done and if your not careful on that, soon you get a spaghetti of communication services. In following posts I dive deeper into the subject “Deciding on the contract”.

I really value any feedback you have on this topic. I hope it sparks some discussion.

by Carlo Poli | with no comments

Filed under: SOA, architecture

Restarting my blog
Thu, Jan 1 2009 8:10 PM

I haven’t been blogging for over 2,5 years (except for one off topic post). This was partly because I didn’t bother, but the main reason was that I didn’t have a goal, a story I wanted to tell the world. I’ve been doing a lot of stuff around integration and SOA/BPM, ranging from guiding BizTalk development to developing an enterprise integration strategy.

2008 to me was the year I dived into the theory of architecting and architecture on one side and understanding the core foundations of Service Orientation and Business Process Management on the other side.

On the theory of architecting I was greatly inspired by the work done by the Software Engineering Institute. I dived into Software Architecture in Practice (2nd Edition) and was lucky to receive an eight-day training from the writers through Logica, my employer.

On SOA I was greatly inspired by the work done by Thomas Erl.

These sources gave me a lot of background on the complex, and still evolving, playground of the Integration Architect.

For 2009, I’ll take up the next challenge, bringing all this theory into practice. Now, I do think that I already bring a lot of the theory in practice. In my day to day job, I work in an environment where the integration we do is greatly driven (and constrained) by existing systems, but with a vision of having a Service Oriented environment in the long run.

In the past year I’ve learned a lot on what the real key features of integration architectures are and what kind of decisions are important to make steps toward Service Orientation.

My goal for this blog is sharing my view on these topics with the world, sparking some discussion. I already have some stuff to talk about, so I guess in the short run I will sound like a teacher telling his story, In the long run I see this blog more as the diary of a tourist touring an environment that is only roughly explored and documented. 

As a side note, I don’t write today as a result of some new year blues with big new intentions. It’s more the holiday season with a lot of days off that allowed me to think about what I want to achieve. But still it is a good day to restart a blog ;-).

by Carlo Poli | 3 comment(s)

Filed under: SOA, BPM, architecture