We never really nailed this one down. I’d like to see an agreed definition for "component", or perhaps, more usefully, "business software component". (to distinguish the concept from technical, infrastructure and hardware components). Alan’s book says (pg. xvii) "Reusable parts that can be adapted, but not modified, are called components; they range from compiled code without program source to parts of models and designs." This seems fine as far as it goes, but I think we could use a more restrictive definition. How about:

Software components: Reusable and adaptable units of software that cannot be modified and that are ready to be bound into an application.

I’d like the definition to point out that a component must meet a set of pre-defined rules (the rules of the component model), but I don’t know how to express that. Further, I’d like it recognised (as in EJB) that a component will frequently be manifested as a set of objects.

Anyway, the point is that we were really tackling two problems at once on Friday, and that’s rarely a good idea. First we were trying to understand how to come up with a set of components that would support the given business process. That’s difficult enough, but we were also considering the effects of physical distribution of these components. I wonder how many people who build component systems are also building non-trivial distributed systems?

Of course, one reason we were considering the two problems at once is that we believe distribution has an impact on component design. To make progress I think we need to become comfortable with non-distributed component design. Then we need to pick some axis, such as entity versus service, and see how moving along the axis affects the characteristics of a distributed system.

All three groups were exploring techniques for localising access or knowledge. This isn’t surprising since we know that limited bandwidth and contention are major problems in distributed systems. If you can make most accesses local then you’ve got a big gain.

The Alan/Benedict/David (ABD) group were trying to apply some notion of locality to the business itself by clustering tasks taken from the business process description. The Anthony/Kevlin/Paul (AKP) group were using spoons to explore the connectivity between poorly-defined "things", with the aim of partitioning the system to minimise cross-locality coupling. My group (Charles/John/Peter CJP) was heading towards (we never got there) clustering functions derived from the process tasks on the basis of information locality, the theory being that functions using the same data should be co-located. This suggests some ripe areas for further research:

A key step for me in designing any software system is to make explicit the boundary between the software (Jackson’s "machine") and its environment. We must state precisely what the software is responsible for. This allows us to explore the nature of the interfaces between the software and its environment.

As far as I can tell, the AKP group didn’t really address this point; their approach had a very "elaborational" feel about it, with a seamless transition from problem to solution. I’ll let that lie on their conscience. :-) I think the ABD group were addressing this point, albeit in a round-about way, via their "views" on the system - but I might be wrong. I was a little concerned to hear this group talk about use cases while still describing the problem domain - surely use cases are only appropriate for describing interactions across the software boundary.

My group tackled the boundary upfront by considering each business task in turn. My Syntropy training encourages me to define specific external stimuli for each cross-boundary interaction, but we didn’t go that far. I believe strongly that any process for moving from business processes to software components must be explicit about the boundary.

I still can’t understand how I missed this one at the time. It seems obvious to me now that we should have assumed the creation of an object that encapsulates and instance of the whole business process. Either that or we must use some proprietary software that has the same effect (perhaps a workflow system). One of the business process steps was specifically concerned with process flow (notify warehouse). If we don’t separate out the process flow we must include some aspect of it in the implementation of each step, which is surely bad.

None of the groups reified the process, AFAICR. :-(