Do/should we have "internal customers"?
posted Jul 24, 2013, 2:53 AM by Alar Raabe

If we use in the enterprise architecture framework IBM Component Business Model (CBM) and A. Osterwalder's business model canvas (BMC) for describing the business and its parts in a business domain architecture.

The CBM can be used to describe the overall business functionality and the functional decomposition of whole enterprise into business components, which can be viewed as small independent businesses. The business components in a CBM are connected through the business services that they produce and/or consume from the other business components, forming a value network. Some of those business services are produced and/or consumed by the external parties (including the enterprise’s customers). So from that viewpoint, for every business component, an external (to the given business component) party could be in two different role – customers/consumers of the produced services and suppliers/producersof the required services.

The A. Osterwalder’s business model canvas can be used to describe the overall business logic of how the business works for overall enterprise, and/or for each functional sub-division down to the business components, identified inthe CBM. Business model canvas also identifies external parties in two different roles – partners and customers. This separation is beneficial because business usually needs to employ different relationship management techniques for the external parties playing those different roles, and usually also the channels through which the value is delivered to the business, and through which business delivers value, are different.

Above described conceptual models (together with their language) provide the modularity and encapsulation, needed to manage the inherent complexity of the business functionality that whole enterprise comprises. Employing this view in business organization/operations allows us to achieve self-optimization of the operations of whole enterprise by optimizing the operations of separate business components, and robustness by encapsulating the business components behind the well formed service agreements.

In principle we should be able to separate and replace any business component (including IT or its parts) as an independent business entity, without changing the internal workings of that particular business component and affecting the operations of overall value network.

So in the behavior of a business component, there should not be any difference, whether the external (to the given business component) party is also external to the whole enterprise or just another part of the enterprise, but the business component should definitely have different behavior (down to the clear service agreements) towards the parties to whom it delivers services and towards the parties that deliver services to it.

To avoid confusions with the usage of word “partner” in the A. Osterwalder's business model ontology it would not be good to denote such business components, which do not directly deliver services to the enterprise’s customers, with the same word “partners”, for both consumers of their services and suppliers of services they need.

There might be political reasons for which we want that in our language enterprise’s customers should stand out from business components that are internal to the enterprise, and because the value network inside the enterprise uses different ways to account the value, the word “internal customer” might not be appropriate for consumers of internal services.

So should we then use the word “consumer” throughout the enterprise architecture models/descriptions to denote the business service consumers in the business models instead of word “customer”?

In case the same business component provides the same business service to both enterprise’s customers and other business components inthe enterprise (as in many cases IT related business components do), should we treat those as two different service consumer classes, and use different words to denote these?

Copyright © by A.Raabe