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?
2 thoughts on “Partitioning in an Integrated System Design”
Back in my days at Andersen Consulting, we had a component-based design methodology that called for identifying business components that mapped to the problem domain, which we would then decompose into what we called Partioned Business Components, which mapped more the solution domain which typically was implemented using distributed component technology like DCOM or CORBA. So your spot on to recognize this as a system-level form of partitioning.
Umh, I think Software – in general – tends to be a mess. Of course you have to do some sort of partitiong and give a structure to what you do, else how do you think you can manage that?
Unfortunately people look at software development as a stream and that’s made of money for someone, pain for others.
And let me tell you something about Design. I’ve never seen nor a craftman neither a civil engineer or even a painter doing their job without sketching before starting, at least…