Modelling Business Relationships
Business Relationship Modelling is a methodical approach for the exploration of organizational structures, federations and system networks. It may be prompted by policy changes, design problems and/or technological opportunities. It is used to make judgements about such issues as organizational changes, technical configurations, technical systems policy and system requirements.
Business Relationship Modelling is intended to be used by various people working within or for federated organization structures, including: business process engineers, planners, software developers and network/market strategists. It may also be used when planning for inter-company networks and joint ventures. The method is also of considerable interest to telecommunications and value-added network (VAN) companies, developing commercial information services.
Business Relationship Modelling can be used to explore the business and technical implications of a proposed federated configuration. It can be used to analyse the market opportunities of a given solution, as well as to identify new business opportunities. In this paper, we discuss it as a method of establishing the required topology of client/server solutions to federated business problems.
When combined with commercial and technical information, the Business Relationship Model enables the production ofThis involves making three kinds of judgement: design, investment/procurement and migration planning judgements.
- to support chosen alliances?
The main impacts of modern application development automation are on the ability of organizations to deliver comprehensive IT support to business processes extremely rapidly, and then to be able to adapt them on an ongoing basis. Automated development contributes to system quality in several ways:Business Relationship Modelling contributes to system quality in two ways: Concepts: modelling agents and responsibilities
Business relationship modelling (also known as responsibility modelling) establishes how responsibilities are shared across a network of interacting agents, each possessing partial knowledge and partial authority.
We define responsibility as a three-part relationship, involving two agents and a state. A state is typically a property of an entity. (An entity may be an activity or a process, a product, an organization, a system or a person, or any combination thereof.)
There are dependencies between states, which can be represented as dependency hierarchies.
Responsibilities can be delegated, but (at least in theory) not escaped. Responsibility modelling is a technique for mapping out these delegation structures for specific responsibilities across multiple agents. Delegation structures may be informal or formal, hierarchical or contractual. Delegation structures should be reflected in contracts and agreements between agents.
Previous techniques for responsibility modelling, such as RAEW analysis (Crane 1986, Texas Instruments 1990), have regarded responsibility as a two-place relation between an agent (or role) and an activity. This has proved extremely useful for identifying inconsistencies between responsibility structures and authority structures, or between responsibility structures and the distribution of knowledge. What the present approach offers in addition is the ability to model delegation structures, especially where these cross organizational boundaries.
The television news industry is an information intensive one. Video news images are passed around the world, in various stages of editing and production. Editors, producers and (in some countries) censors require accurate descriptions of the content of these videos, and must keep on top of the logistics of many things, including satellite transmissions, crew locations, and programme requirements. All parties need an ability to predict and monitor developing news events as they develop. (Information modelling for the television news industry is described in Veryard 1992.)
The television news industry provides an interesting example of increasing agent specialization (or role differentiation), with increasing use of short-term contracts, permanent subcontracts, free-lance crews, independent productions and multiple distribution channels.
When designing client/server systems to support the television news industry, you need to consider the present and likely future structures of information handling:(Note that, in a competitive world, these apparently equivalent questions do not yield the same results.)
The entire set of contractual relationships along the production chain can be represented in terms of such agent-responsibility relationships. This forms the business relationship model.
Business relationship modelling takes it as axiomatic that information systems are used primarily to fulfil and enforce business responsibilities, which may be based on:Therefore the business relationship model indicates some important aspects of the requirements for information systems. These aspects are particularly crucial in client/server networks.
Using the Business Relationship Model
One use is to understand the political and commercial implications of client/server design. There is always a political or commercial-strategic dimension to topology. Business relationship modelling helps us understand the implications of design choices.
Some businesses may use innovative software mechanisms to attack their competitors, or to protect themselves from attack. (We expect to see some examples of this in the home banking arena.)
Some of our associates (Iggulden 93) have done considerable work in the health service, exploring how apparently neutral technical decisions turn out to have significant implications on the working relationships between different groups (doctors, nurses, administrators, and so on).
Another use is to support requirements engineering, in a context of reducing technical constraints.
Whereas in the past, topologies were largely chosen because of the limitations of available technology, this is decreasingly the case. While the commercial and political structures become ever more convoluted, new technological solutions are emerging to enable a range of different topologies to be implemented. Although the designer cannot (yet) entirely ignore technological feasibility, this may cease to be the primary concern.
To give just one example of the growing technical choice available to the designer, Texas Instruments Software is currently building Internet capability for serious commercial applications.
Finally, various planning and design guidelines can be formulated, based on the structure of the business relationship model.
If software is designed to support agent specialization, this increases the overall flexibility of the configuration. Delegation structures should be reflected in information systems. The system sponsor may want to reinforce some delegation structures, and undermine others.
Control over key information resources, and the provision of access to these resources, is a source of commercial and/or political power. The television news agency in our example will want to maintain certain types of information on its own servers, providing external agents with just enough access to discourage them from duplicating this information elsewhere, thereby ensuring that other companies cannot construct alternative delivery channels that bypass the news agency. The broadcaster will want to design its information systems to support both in-house and independent production units.
Adaptability is promoted by the following design precepts, which are
supported by the technique of business relationship modelling:
|Design systems by composition from smaller units.|
|Decentralize control subsystems|
|Use responsibility clustering to divide a system into subsystems.|
|Improve the overall robustness of a system by improving the robustness of individual components.|
Thus in a federated world, it is not enough to do a business case from your own perspective. You have to work out ways of making a system or process profitable for each of the participants, as well as making services attractive and affordable to the customer. This means that you need to have an estimate of the likely business case from the other stakeholders' perspective. You need to have some appreciation of each stakeholder's intentions. An indication of intentions can be based on an analysis of responsibilities.
Business relationship modelling helps identify significant benefits & opportunities from client/server technology, including:Business relationship modelling therefore helps improve the deployment of open systems and distributed technology.
In the modern world, business needs are complex, and typically include communications across organizational boundaries. Among the most interesting and challenging client/server opportunities are those that cross organizational boundaries. Adaptable systems should allow for future business changes, such as outsourcing.
Therefore the systems designer needs an awareness of the internal and external business relationships of the user. This is provided by Business Relationship Modelling.
This paper was first presented at IEE International Seminar on Client/Server Computing, hosted by IBM La Hulpe, Belgium, 30-31 October 1995.
D.A. Iggulden, J.E. Dobson & R.A. Veryard, 'ODP as an Instrument of Hegemony', in Proceedings of ICODP93 (Berlin, September 1993)
ISO 9126, Information Technology - Software Product Evaluation - Quality Characteristics and Guidelines for their Use (Geneva: ISO/IEC, 1991)
I.G. Macdonald & R.A. Veryard, 'Modelling Business Relationships in a non-Centralized Systems Environment' in A. Sölvberg, J. Krogstie & A.H. Seltveit (eds), Information Systems Development for Decentralized Organizations (IFIP Transactions; London: Chapman & Hall, 1995)
T. Peters, Liberation Management (New York: Alfred Knopf, 1992)
Texas Instruments Inc., A Guide to Information Engineering using the IEF™ (Second Edition, Plano TX: Texas Instruments, 1990)
R.A. Veryard, Information Modelling: Practical Guidance (Hemel Hempstead: Prentice Hall, 1992)
R.A. Veryard, Information Coordination: The Management of Information Models, Systems and Organizations (Hemel Hempstead: Prentice Hall, 1994)
R.A. Veryard, 'IT Implementation or Delivery? Thoughts on Assimilation, Accommodation and Maturity', in Proceedings of Working Conference on Diffusion and Adoption of Information and Information Technology, (Oslo: IFIP WG 8.6, October 1995) .
R.A. Veryard, 'How Business Relationship Modelling Supports Quality Assurance of Business Objects', to be included in Proceedings ofAQuIS 96: Third International Conference on Achieving Quality in Software (Florence: IFIP WG 5.4, January 1996)
R.A. Veryard & J.E. Dobson, 'Third Order Requirements Engineering: Vision and Identity', in Proceedings of REFSQ 95, Second International Workshop on Requirements Engineering, (Jyvaskyla, Finland: June 12-13, 1995)
R.A. Veryard & I.G. Macdonald, 'EMM/ODP: A Methodology for Federated and Distributed Systems', in A.A. Verrijn-Stuart & T.W. Olle (eds) Methods and Associated Tools for the Information Systems Life Cycle (IFIP Transactions; Amsterdam: Elsevier/North-Holland, 1994)
|Contact Ian Macdonald||Contact both authors||Contact Richard Veryard|
Technical update May 24th, 1999.
Copyright © 1995 Ian Macdonald & Richard Veryard