From the requirement specification point of view, components offer a more powerful and predefined way of communication. Instead of the drawn-out process of specifying each and every detail of the requirements we can just identify a known component or specify the services that we want. In many sectors of industry, this has resulted in an improved efficiency within the sales process of the forerunners of component-based product architectures. Thus, the component approach itself is a key strategy in extending your market share by covering more segments and niches. This important mechanism deserves more attention on the component agenda - which in high- tech enterprises generally tends to focus on product and production.
The communicative power of a component is similar to a technical term in natural language: if a financial analyst mentions something like 'a black Monday scenario' to a colleague, they probably save pages of detailed text because the scenario has previously been analyzed, described, and labeled. So, if you talk about the Accounts Department (as a high-level software component in, say, a Web shop), you can easily mention the services you expect for your solution, for example, take a credit-card payment, check the 'hot list' for defrauders, and alert when accounts are overdue.
Where solutions are assembled from bought-in parts (and where they are wholly constructed from the ground up by the development teams), the specification work and business analysis don't simply walk away. It's critical for the stakeholders to specify the (business) services required in the new solution and to discuss the resulting component models to ensure these services will be delivered.
Specifying Components for Wet-Liquids.com
If we return to our 2080 example for Wet-Liquids.com, we can identify a number of components that represent the obvious business elements: sales department, product, distribution, Accounts Department, and customer. These components are at a 'near-top' level.[4] Large component libraries,
such as IBM's San Francisco (SF), are typically at several levels of
granularity. Both in SF and in OMG's view of components, our 'product' and 'customer' (see Figure 6-2) are standard examples of so-called business objects. They're far above the technical level, but still frequent in most kinds of systems.
Distribution (in Figure 6-2) is an example of SF's top level, originally called
application frameworks or San Francisco Towers, that is, 'Lego-brick towers,' assembled of business objects (other examples at this level are financials, HRM, or manufacturing). Figure 6-2 shows these components, as well as another one added within the Accounts Department to deal with the online credit-card banking service. This is an example of wrapping components up in other components (or nesting). The dotted line shows the dependencies between the components,[5] that is, sales needs to know about all the other components, but all the other components don't need to know about each other. If we reconfigure the system to run some new process in addition to the current order process, then we probably just add some more
Figure 6-2. Example components for Wet- Liquids.com.
Once these components are identified, we now outline the responsibilities
allocated to each one:
Sales Department: responsible for processing each customer's drink request (listing products, validating choices, submitting orders to distribution), managing customer subscriptions, and issuing sales orders.
Customer: responsible for recording personal and subscription details, knowing their own account balance and payment status, and holding a history of sales.
Product: responsible for knowing details of the product including restrictions (for example, age/alcohol), providing pricing and discounts, recording stock levels, and monitoring the shelf-life status.
Distribution: responsible for managing the product inventory and distribution channels [sic], accepting new products from suppliers, dispensing the product to customers, and reporting the status of the distribution channels.
Accounts Department: responsible for issuing customer statements, collecting payments, updating customer payment records, and reporting defaulters.
CC Banker: responsible for validating credit cards and charging payments to customer credit-card accounts; an online authorization service.
These are high-level components. Some of them can be bought as
components, some can be rented as Web services, some can be bought as parts of a package, some can be reused from previous projects, and some can be developed now.
From this 'Lego kit,' we can, in principle, configure a process chain, for example, the order cycle. Now, suppose we have a merger a few years later, resulting in a new marketing policy. Because of this, before adding a
customer address to the mailing list of the sales department component, the current credit rating of the customer must be checked automatically to invest Wet-Liquids.com's sales efforts in customers with proper liquid assets. The dependency between the sales department and accounts is already in place. We simply adjust our sequence diagram (activating the credit-rating check in
the Accounts Department component) and reconfigure the system. The credit-rating checker component can be nested within the Accounts
Department from the beginning or easily purchased otherwise, for example, from Dun & Bradstreet or from a component broker.
In fact, this modest change can evolve into a rather extreme example of
Reuse before Buy before Build. The traditional build and deploy approach ('supply-side' control) could easily spend weeks specifying and designing this upgrade. A new proprietary rating component could take years to develop and another year to fine-tune, especially with business-to-business customers. If you're serious about making computers interpret and analyze complex financial information (producing credible, realistic credit ratings), you need a lot[6 ]of financial data, smart information-mining tools, a couple of
sophisticated knowledge bases, a panel of credit-rating experts to keep the knowledge current, plus a skilled team of IT people. In our humble opinion, reusing a component of proven quality developed by someone else is more realistic.
[4]Some other people might choose to make each activity of a process a
component (to increase configurability), which isn't at 'top,' yet is at quite a high level.
[5]These dependencies are of the «communicate» stereotype, to be exact:
technically, the sales-department component will be sending requests to the other components whenever necessary.
[6 ]Although the results, i.e., the ratings per company, might fit on a CD-ROM
or three, the raw material necessary for producing them can be hundreds of gigabytes of financial databases.