OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software OIG Ltd Capturing Business in Software

+44 1249 815081


Business Modelling

Adopting a Process



Business Builder

Component Development



Full Life Cycle

Delivering on the J2EE


OIG provides help with components and business modelling by addessing issues such as feasibility, scope, project management, completeness, usability, methodology, process and tool support.

We have worked with many companies to identify their core business concepts. This has enabled them to establish their fundamental business components, which they have then gone onto in most cases build, but in some cases buy, with more confidence that they will actually arrive at a solution that fits their business properly. We have used a variety of knowledge elicitation methods, brain-storming and meta-planning techniques to arrive at the core concepts and then built the appropriate models in whatever best met our clients requirements, for example UML. We have our own bespoke process for component and business modelling, but we often tailor this to fit in with clients' existing processes or to include elements of other processes they may be adopting such as RUP. What we have never done is built shelfware - we strongly believe that our deliverables should be immediately usable and usable by all ie the business through to the developer. To achieve this end we make particular use of the now so-called Agile methods, ensuring that any component and business modelling process does not impede development.

Would you like to know more about what we do ?

Perhaps you would like to discuss your specific issues with components and business modelling - then please phone us on +44 1249 815081 or mail us at more@oig.co.uk

Or discover how a consortium of large scale users - the Object Interest Group - determined the feasibility of business components. The page that follows details this work and although developed sometime ago it provides fundamental, basic understanding of business components, which is often missed and also provides some useful guidelines on the feasibility of commercially available components.

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).

Domain vs Application Figure

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 :

Domain Description Figure

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.

Component Scope Figure

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

  • 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 ?
Feasibility - can these CBOs be built ?
  • 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 ?
Development - new issues to be managed
  • 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 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 ?


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 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.


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 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

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, it’s not knowing what profit is that gives a corporation its edge, it’s 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 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

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 :

  • Suppliers
  • Consultancies
  • Academia
  • Research organisations
  • Government agencies and
  • Standards bodies, such as the OMG.
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 ?

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.

Created : 30th April 1996

Updated : 11th August 1996

Go to top of page


The Object Interest Group
History of the Object Interest Group
An Assessment of OO
Starting with Objects
Choosing a method
Managing Reuse
Components and BPR
The Object Interest Group Home Page
Go to OIG Ltd Home Page
© The Object Interest Group

Any comments on these pages to: more@oig.co.uk

© OIG Ltd 2002-2003