The Feasibility of CBOs
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
Despite the considerable potential of CBOs, a major concern for
a number of our members and other practitioners, was that many
of their existing corporate models were very complex and therefore
difficult to communicate. They also tended to become out of date
very quickly and they were difficult to evolve, which usually
meant that significant parts of these models were irrelevant.
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
Feasibility - can these CBOs be built ?
- 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 ?
Development - new issues to be managed
- 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
Common concepts which the majority of business people understand
and generally talk about quite openly include for example profit,
debt, business party, agreement, purpose and product.
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
- 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 ?
From our work during Phase II (92 - 93), the barriers that became apparent
were as follows :
- The work across corporations needed to be confined to non-competitive
- 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
- 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
On the other hand, the potential benefits were quite substantial :
- 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
- 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
Commercial sensitivity and competitive edge issues
With respect to commercial sensitivity and competitive edge issues,
conversations with and between business people showed that they
do have common concepts that they understand and that they do
talk about with no fear of losing competitiveness. After all,
its not knowing what profit is that gives a corporation
its edge, its knowing what is profitable. Similarly, with
CBOs a corporation would gain competitive edge via its skill at
successfully applying them to its own problems. Having said that,
some work is necessary with some of the concepts to separate out
any commercially sensitive information which has become entangled
with the basic concept over the years, without losing the usefulness
of the concept.
Development - new issues to be managed
From our Phase II work and from talking to other practitioners
and suppliers we feel that the development of good quality usable
CBOs is going to involve considerable collaboration between the
likely consumers and suppliers. Actual development will probably
need to be undertaken by the suppliers but business input would
most likely come from industry consortia.
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
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.
Increased interest in business objects from both the business
process re-engineering (BPR) and the framework communities has
recently brought the issue of CBOs more to the fore. We have
now tested a number of the 100 concepts amongst our member industries,
and started to determine potential CBOs from these. It is clear
from this initial work that considerable effort is required, but
that criteria for inclusion are emerging which will make the task
easier and the potential benefits are significant. Consequently,
we want to be confident of the feasibility and success of CBO
development and to ensure that the work is justified with more
complete cost/benefit information.
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 :
Throughout 1995 we promoted wider awareness of CBOs, including running a number of sessions
at the major object conferences and inviting wider participation as above. The purpose of this
was to explore the level of interest and to widen the involvement
in assessing the feasibility of such components, so that we could
position CBOs in systems development - ie are they a feasible/workable
part of the development life cycle ?
- 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
Created : 30th April 1996
Updated : 11th August 1996