ENTERPRISE BEHAVIOR

Enterprise Behavior

Enterprise Behavior

At present, many companies rely on third-party applications and application services for (part of) their information systems. When applications from different parties are used together, an integration problem arises. This paper describes an integration approach based on the construction of an enterprise layer. This approach is deliberately kept away from a document-based, flow-oriented approach, where business processes are hard coded into the application architecture. Interaction is based on the concurrent update of a shared underlying enterprise layer. At the same time, the application architecture becomes easily adaptable to re-engineered business processes.

The first example is related to the storage of people data. In the Sales and Marketing business unit data is stored on in-house sales people, out-house distributors and commercial contacts. The Service Provisioning application and the Customer Services application maintain data on technical contacts. The Finance application keeps track of financial contacts. Since the company mainly deals with SME, an individual often takes several of these roles simultaneously, so that data about one person will be distributed and replicated across several business units. The company could benefit from an approach ensuring that data on a single individual are stored and maintained in one place. For example, the company can then ensure that when a person misbehaves in one of the above roles, this person will not be accepted to take on the role of, say, financial contact in the future. Such a policy is only possible when all information on individuals is centralised.

The second example is related to the storage of product data. The Sales and Marketing business unit is responsible for conducting market research and offering appropriate telecom solutions to keep pace with the evolving business opportunities. What they sell as one single product can be further decomposed into a number of parts to install and parameters to configure by the Service Provisioning business unit. An example of this is shown in Table I.

These business units need a different view on products. Sales and Marketing and Finance need a high-level product view and are not interested in low-level issues related to the installation and configuration activities. Service Provisioning needs to know the parts, where to install and configure and does not bother about the high-level sales and marketing issues.

In an attempt to keep a unified view on products while accommodating for their different needs, people of the business units tend to twist the product definitions in their respective software packages. By abusing attributes and fields for cross-referencing purposes, they try to maintain a more or less integrated approach. However, as the set of products in the product catalogue will increase, a unified view is no longer sustainable. Also, in an international set-up with multiple business units, a unified view can be held no longer: what if a single product from a sales point of view requires different technical configuration activities depending on the business unit?. An example of the latter is Internet access: it can be implemented by means of an unbundled line in the Netherlands ...