Partitioning in an Integrated System Design

Partitioning isn't a word we hear very much of.

Most of the time, when we talk about Partitioning, we are talking about breaking up the database for large-scale distribution.  But that isn't the only definition in computer science.  Partitioning for systems design is another definition, although one not commonly used any more.

That's a shame.  The concept is a good one.  The idea is that you break up your design into subsystems, each with a clear responsibility.  Robert Martin characterizes this responsibility, in his OO principles, as a "reason to change."  (As in, each class should have one and only one reason to change).

From a systems perspective, I don't believe that Martin's rather clean definition can be used in the same manner because, honestly, systems by definition have multiple reasons to change.  So we return to the original definition:

Partitioning is the design activity involved with creating clear and cohesive boundaries between interacting components in order to minimize the flow of requirements between them. 

It is a simple and elemental activity.  Most architects practice it, although some probably do it unconsciously.  It is the notion that you can look at a problem and break it up into "things" that, when interacting, solve the problem.  The "things" are your classes (in the application) or your components (in the system).  The act of breaking them up is partitioning.  In effect, you take the responsibilities of the system and you divide them up into small groupings and assign the responsibilities to components in a non-overlapping manner.

I'd like to reintroduce this term.  It's a good word to use, and in the SOA world, we should be discussing the partitioning of systems into activities to be performed in different types of services and consumers.  By focusing on this activity, we can move from "black art" to "repeatable process."

And after all, isn't that the way forward?