Is Cohesion Important for SOA?

Back in 2005 while still working for IONA, Steve Vinoski published a paper that talked about Cohesion and Coupling for services. In it he mentions 3 "good" types of cohesion that have been identified over the years:

• Functional Cohesion: when a module does only one thing. They display low coupling and are highly reusable.
• Sequential Cohesion: when a module carries out several tasks that must be ordered.
• Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

Then there are 4 forms of "bad" cohesion:

• Procedural Cohesion: similar to Sequential Cohesion, except the data that each of the tasks works on is different. As Steve says: "Such cohesion often results from artificially grouping activities [to reduce coupling]."
• Temporal Cohesion: when a module's tasks are related only by time. "Such modules cause maintenance problems if one task needs to be performed at a different time.|"
• Logical Cohesion: where a module's activities are grouped because they appear to share common implementations.
• Coincidental Cohesion: a module's tasks are related only by the fact they reside in the same module.

As Steve goes on to say:

Just as with coupling, cohesion still matters when applied to distributed objects and services. For example, if  you grouped a bunch of methods in an object only because they had similar implementations, you would be guilty of creating a logically cohesive object.

The paper concludes with:

Given that transitions to “new” computing styles are often accompanied by explicit disapproval of the outgoing style, it’s no surprise that today’s focus on SOA has created a bit of a backlash against distributed objects. What’s unfortunate is that many of the measures of quality for distributed object systems apply equally well to distributed services and SOA, so it’s a shame that some feel compelled to ignore them just to be trendy. But perhaps it doesn’t matter, because we can just go back to the days before objects, dig up measures like coupling and cohesion, and apply them all over again — for the first time, of course.

Now this may have gone relatively unnoticed for the past few years, until Jim Webber's recent posting on Anemic Service Model. Skipping over the historical discussions about good software engineering practices, Jim says some very similar things to Steve's earlier work:

Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.

 

The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.

The entry then goes on to discuss how current SOA thinking really goes against this grain:

On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?

 

No. In fact absolutely wrong. [...] this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA.

Now there are quite a few interesting comments on that posting. However, the real debate that this kicked off has been happening elsewhere, particularly with JJ's response:

Well someone who is trying single-handedly to topple SOA with a "Something Else Oriented Architecture" is Jim Webber -the MEST guy. [...] I found his post being completely erroneous. I may be missing something, but Jim is looking at the relationship between Cohesion and Loose Coupling. [...] For me cohesion sounds like a good engineering principle that looks a lot like "Dependency Structure Matrix". [...] The goal of loose coupling is precisely to mitigate cohesion as a good engineering principle. You can't be cohesive in a connected system. You can't be both cohesive and loosely coupled. Even in English, associating the two sounds really bad.

The goal of loose coupling is to make to pieces of code work together even though they may have been written at a different time, using different technologies, with a different security model, ...

SOA is about going away from cohesive systems to enable a wider range of reuse scenarios. Nested cohesive systems do provide a "nested" (library-style) reuse model: the upper layers can reuse the lower layers. Unfortunately, it forces us to create systems in a way that is incompatible with the way information systems should be architected. Cohesion is the problem, loose coupling is the solution. Jim, do you really think that people are trying to "keep stuff together in the same module"?

JJ posits that although cohesion is a well understood software engineering principle, it is not relevant to "modern" SOA:

I find it increasing irritating to see some people constantly aiming at "SOA" with ideas they cooked 5 years ago, when the only thing they are really aiming at is their own misunderstanding of SOA. [Jim is] showing pictures that are antiquated and certainly does not represent SOA in 2008.

And goes on to discuss Steve's original article as well:

... a cohesion requirement creates absolutely unnecessary constraints on the design of service interfaces and implementations that actually reduce the degree of reuse of a given service and its capacity to participate in different assemblies. Maybe it is time to become familiar with modern loose coupling concepts that include: bi-directional interfaces, assemblies, orchestration languages, extensible and semantically accessible data structures. Ancient programming techniques have been designed precisely because you did not have these concepts within your programming model.

The debate goes on though. Is cohesion fundamentally opposite to SOA? For instance, do we need to rewrite software engineering books to cover cohesion as it relates to SOA? Surely cohesion itself is not bad, but perhaps there are degrees of cohesion as there are of coupling, and one size does not fit all?