The Feasibility of CBOs

Component objects

One of the most important conclusions we reached in Phase I was that the object approach enabled a separation of the domain from the application in a more distinct way than had been enabled by previous approaches. We also defined the domain as consisting of fundamental stable components and the application as being concerned with the evolution, implementation and assembly of these components to meet specific information needs (see Figure 1).

By the start of Phase II in September 1992, this separation of domain and application was more widely-accepted, and people were starting to look at the possibility of producing domain objects (components), as opposed to application-specific ones. The belief being that such components were the real key to improved productivity by being able to reuse them across multiple software applications. But what was unknown was the scope of such components, and how feasible it would be to develop them, with respect to their quality and cost. We therefore decided in this project to start to address this issue of feasibility by investigating suitable domains and looking at the implications for consumers and suppliers.

Determining a common domain

Component objects are not usually directly usable as an application, in the same way that car components do not directly provide transport. Instead, the components should be viewed as building blocks, representing concepts relevant to a number of different areas.

The concepts addressed by a set of components define a domain as illustrated in Figure 2 :

For a set of components to be usable across different applications, the applications should have similar enough needs that the components can serve them all - yet still be possible to build. If different applications use concepts that are radically different, it is unlikely that a common set of components will serve them. Therefore, the job of creating a potentially useful set of components involves creating a model of the domain - ie representing the common concepts in a more precise form. But a useful rule of thumb is that a good domain is one where ‘documentation’ defining terms relevant to that domain already exists.

Figure 3 shows that any type of component may potentially be reused within applications, across applications, ie within a project, across projects - ie within a business area, across business areas, ie within a corporation, across corporations - ie within an industry. That is, the scope of a component is independent of its type.

Evidence from our own members and other practitioners shows reuse in applications across projects and business areas, ie they are starting to see corporation-wide reuse. With respect to the type of reuse being achieved, most practitioners classify reusable components into a number of categories. Although these classifications vary to some degree, in general they include low-level technical, middleware (support) and business categories, as shown in Figure 3. The evidence from most practitioners is that commercial DP departments, building a number of OO applications are creating common components of various categories to be reused within that department, ie across applications. However, despite the fact that there is an emerging market for sets of components sold direct to IT developers, built by third party speculators, ie across corporations, these have tended to be confined to the technical and middleware categories, eg database access.

The development of business objects across corporations, ie Common Business Objects, however, represents great potential. For although the most direct and easiest gains are likely to come from reuse across a few applications in a DP department, and although we may be able to pick up a few utilities from the current open market, CBOs would represent the common understanding of business and commerce, thus aligning systems development ever closer to its business purpose. Thereby, finally providing the truly significant productivity and quality gains always promised by object technology.

Issues to address

Understandably, members were concerned that object models might turn out just the same. So before getting involved in the actual development of CBOs they wanted to explore the feasibility and cost of producing stable, but understandable and usable common components and models.

The solution process once again involved members sharing their experiences which resulted in the following key issues they wanted to address :

Concepts - determining which are candidate CBOs

• What sort of concepts need to be modelled ?
• Could we identify any of their characteristics ?
• If so, could we use these characteristics to start to identify critical criteria for inclusion in the domain ?

• What would be the cost/benefit of developing components to effectively model common concepts in this domain ?
• Would it indeed possible and valuable to produce these components - what about commercial sensitivity and competitive edge issues ?

• Who would be likely candidates to develop/use such components ?
• What could we do to assure the quality of these components ?
• What actions might stimulate the creation of sets of these components, so that suppliers could enter this market and potential consumers could benefit from them ?

Concepts - determining which are candidate CBOs

We quickly produced a set of about 100 of these concepts. The majority were recognisable by all our member companies, but when we started to try and apply these concepts to particular problems (applications), the work became less straight-forward. However, what did start to emerge were a few common characteristics amongst the concepts which could be easily applied by all the members. This in turn helped us identify a few initial criteria for including a concept as a potential CBO in the domain :

• It must be relevant to a significant proportion of the potential consumers.
• It needs a name (or synonyms) recognisable by all consumers.
• It must contain sufficient behaviour to make it useful.
• It must be non-competitive.
• It must model a relatively stable concept.

Feasibility - can these CBOs be built ?

Barriers

• The work across corporations needed to be confined to non-competitive issues.
• There was a risk of never getting agreement so sessions needed to be well-facilitated.
• In avoiding the first two, the resultant components could be valueless or vacuous, ie too abstract to be of any practical use.
• Common components in manufacturing took many years to evolve. The development of useful CBOs looked likely to be the same, requiring considerable interaction between a wide variety of corporations, consumers and suppliers alike.
• The success of CBOs was likely to depend on standards which would also take a considerable amount of effort to set.
• At the start of the project it was difficult to alert corporations to the importance of CBOs before they had significant application experience.

Benefits

• The object approach with its support for encapsulation and abstraction is a richer and more powerful way of reflecting the stable concepts of a business. With components which more naturally reflect the business no meaning is lost, there are no complex relationships and therefore application objects can be directly derived. This makes the model both easier to communicate and use.

• At the application level definitions of for example customer may differ considerably depending on the context. This can then result in a number of uncoordinated models. But with the existence of components all derived from the same model, common aspects will be shared, therefore models will be coordinated and it increases the possibility of interoperability.

• Better quality.
  If CBOs can be developed from a number of corporations, it means that software can be built using widely-developed and tested, stable components which in turn will produce the required productivity and quality gains.

• The cost would be defrayed.
  Individual corporations may decide to develop business objects centrally, but this will require the infrastructural funding to be raised. With CBOs the cost can be defrayed across all the contributing corporations and should also result in a deliverable of higher quality and resilience.

• Knowing how to start using the object approach can be difficult. The existence of CBOs would provide a more secure basis from which to start.

• Similarly, achieving reuse is often perceived as the major goal of the object approach, but it is not intuitively obvious how this is attained. Again, the pre-existence of CBOs, from which detailed application objects could be directly derived, would provide immediate reuse, providing the consumer with a kick-start.

• Using accepted CBOs in products, would enable suppliers to reach a wider and more varied market.

• Faster provision and lower total economic cost
  It would also mean that suppliers using CBOs in products would be able to provide their product quicker and at a lower cost to all.

Commercial sensitivity and competitive edge issues

Development - new issues to be managed

To assure the quality of these CBOs we need to involve as many corporations as possible. This is essential to develop generic instead of general and useless components, and to ensure the components are complete.

To stimulate the creation of CBOs, we need to promote wider awareness of their potential existence and benefits. Then confirm their feasibility with a wider group of potential consumers, to ensure there is a viable market. While at the same time involving the suppliers to see if commercial CBOs can be produced.

Moving forward

To achieve anything of value meant taking the whole industry forward. The OIG was in an unique position to raise this issue and to ensure it was user-driven. However, any further activities needed to involve not only users, but also :

• Suppliers
• Consultancies
• Academia
• Research organisations
• Government agencies and
• Standards bodies, such as the OMG.

Then, if such components did prove feasible, we needed to continue to investigate some of the issues identified in Phase II, such as criteria for inclusion, while starting to address other issues such as :

• Guidelines for assessing completeness :
  How do you guarantee that a given set of CBOs is going to cover everything you will need for business ?

• Requirements for usability
  What have people found that they need to make these components actually usable ? For example, catalogues of available components, specification standards, robustness factors etc.

• Methodology support
  Given that there will be little experience available, members want to feel there will be methodology support, but first it is necessary to understand the requirements these CBOs will place on methodologies.