What makes a conceptual component?

One of the first hurdles to overcome in using the concept of object oriented design is understanding what constitutes an object. The difficulty arises because of its vagueness: it can literally be anything at all. Even more confusing, an object can consist of other objects, which blurs the idea of an object even further. However, this vagueness is the strength of objects. They can consist of people, software programs, concepts, processing procedures or any combination of these and all kinds of other things.

A conceptual component is an object. It can be a database. More usefully, it can be a person with a database who will provide a database service and do all the necessary work associated with its functioning. In this way the component will provide a function where the user does not have to learn how to use it or have to maintain it.

A component can be a programmer, or, a Web site designer, but, more usefully, it can be a generic Web site design that covers a site owner's needs and comes with somebody who will set it up and handle all the running and future developments of the Web site.

A conceptual component might be a knowledge of bandwidth and load balancing for Web sites. It might be a suite of programs that can be used to optimise the functioning of a Web site. More usefully, such a component will come as an inexpensive service that someone can provide.

Similarly, with a software product. A component can be a programmer who'll create a custom made design. But, far better if the component is an off-the-shelf design that can easily be customised by a service that will be continuously responsible for its efficient performance.

It is such components that will be in the cafes of Information Age auteurs and entrepreneurs who are looking for opportunities to create e-businesses in the post dotcom world. These components will involve no capital outlays or costs until they are profitably used. They are known as FSPs (function service providers) and are a reincarnation of the old concept of Asps (application service providers). We shall be dealing with these FSPs in more detail in a later chapter.

Vital to this object oriented scenario is intangible conceptual components. These are the little mental models that have been abstracted from past experiences. The previous two books in this trilogy were full of these little mental models, mostly consisting of metaphors, similes and anecdotes. These intangible components can be combined in various ways to create a plethora of different organising frameworks for the more tangible components to fit into.

In subsequent chapters we shall be examining how conceptual components and frameworks combine together to explore and take advantage of opportunities, but, before going there, it is vitally important to understand some of the more subtle aspects of bottom up design.