drawing the component boundary

balancing performance with flexibility

Component based development is about creating flexible families of end-products from kits of inter-compatible components. But how does one pull off this feat of architecture? Where do the components come from? What must you do to ensure you get the advertised benefits? If you are in the hot seat labelled 'architect', what should you do?

It must be recognised that CBD does not mean aquiring parts from everywhere: they are unlikely to be compatible without a great deal of glue. Instead, components must be designed to work together, and for a particular domain or business: interoperability standards for components must be agreed within a project, company, or industry. These standards involve much more than interconnection and container technology such as CORBA or EJB: the components talk to each other about Accounts, Customers, Targets, Calls, or whatever, and must speak a common language. Nor is this just a question of defining a common data model (for example in XML): the different components must have some common notion (even if partial) of what the constraints on the objects of their communications are, what operations can be performed on them, and what the effects of the operations are — in other words some semantics. All these definitions are part of the architecture on which a kit of components is based. A distinction between the tasks of product builder, component designer, and component kit (= product line) architecture must be made. These tasks require different skills and degrees of ceremony.

How to partition work between components is a common problem. Separation of concerns is the initial and key rule. Variable features should, ideally, map to separate components, decoupled with a well-defined interface. An open type system must be maintained for the communication links. After that (particularly in a distributed component system), bandwidth and continuity of service must be considered, with the important tactics being caching, replication and splitting; the need to consider how and how often cached or replicated information will be synchronised follows. A useful guide is to map large-scale use-cases onto components.

It's a feature of component based designs that different software end-products can be made by 'rewiring': substituting one component for another, or rearranging the configurations of the components. Such a kit is also open: you should be able to extend the functionality achievable in the end-products by designing more components. (If all the end-products have the same set of 'components', they're not components at all: they're merely modules!) The same principles apply to both large and small components, whether they are user interface widgets or accountancy subsystems.

Once you have worked out your ideal architecture, a migration plan must be generated about how (if ever) you're going to get there from the current situation; and how you are going to find out what the latter really is.

complete solutions to create model and component-based architectures
(consultancy, courses, workshops, mentoring, seminars, development)

email us  or  telephone   UK: 01625 850 839    International: +44 1625 850 839