Modelling Business Relationships

veryard projects - innovation for demanding change

Modelling Business Relationships
for Effective Client-Server
and Open Systems Delivery

Ian Macdonald & Richard Veryard

October 1995

Introduction

This paper provides a brief description and illustration of the Business Relationship Modelling technique, as it may be applied to the planning and delivery of client/server solutions to federated business problems.

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 of

a flexible internal structure, consisting of reusable and relocatable business objects - we call this the solution architecture. Thisdefines the topology of a distributed system, in which many autonomous agents interact commercially and technically to perform one or many decentralized business processes, or to deliver one or many business services.

a business case for each participant

a migration plan for getting from the existing situation to the solution with minimum disruption and risk - for example, how long will it take to reach commercially viable volumes

This involves making three kinds of judgement: design, investment/procurement and migration planning judgements.

Background: changing paradigms of systems development

In the past, software developers worked with the following assumptions. Although they were never entirely valid, they provided some useful simplifications which underlay the old tools (including early CASE tools), methods and working practices.

Central problem ownership, central design authority, central funding authority

Complete understanding of a given problem/situation

Comprehensive solution to a given problem

Stable or slow-moving market environments, technical architectures and policy frameworks

Traditional life-cycle model of systems development (waterfall, spiral, tornado or whatever)

Federation provides a strong challenge to these old assumptions. Federation can be understood as the distribution of authority. In the 1990s, we can see two important trends running in parallel.

From the supply end, technology is becoming more federated.

From the demand end, business is becoming more federated.

Further challenges to the old assumptions can be found in current trends towards system openness and adaptability at three levels:

Technological: portability, interconnection, interoperability, distributability

Organizational: lifetime evolution of applications (openness to new functionality), unboundedness (lack of barriers to information crossing organizational boundaries), decentralization, transient organizations

Market/Strategic: low entry barriers, low exit barriers, outsourcing, inter-firm cooperation, 'Liberation Management' (Peters)

Client/server technology is particularly relevant to federation, openness and adaptability. It is therefore particularly necessary for client/server developers to understand the implications of abandoning the old systems development paradigm.

Goal: defining and aligning business and system strategy

Strategic questions for the business supported by Business Relationship Modelling include:

what are the key emerging roles in our markets?

which roles do we want to play ourselves?

what alliances do we want with other role-players?

what are the business risks of chosen technical strategy?

Strategic questions for information and communications technology supported by Business Relationship Modelling include:

what systems and infrastructure do we need:

- to support chosen roles?

- to support chosen alliances?

how do we maximize system adaptability?

what are the technical risks of chosen business strategy?

Goal: achieving software quality

We can see how Business Relationship complements automated systems development by looking at the characteristics of software quality as defined by ISO 9126, which provides a hierarchical decomposition of software quality into six characteristics: Functionality, Maintainability, Reliability, Usability, Efficiency and Portability.

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:

When combined with a good management process (as measured by the SEI Capability Maturity Model, for example), automated development adds predictability and productivity to the systems development process. Techniques of software reuse contribute to the efficiency of the software development process.

The main impact of automated development on the delivered system is in the areas of reliability and portability. System efficiency is improved by the ability to reconfigure client/server systems for optimal technical performance without recoding

Client/Server and GUI improve the usability of management information systems, by enabling integration on the desktop.

Business Relationship Modelling contributes to system quality in two ways:

Firstly, it provides insight into the business process, and the functional requirements of information systems to support the business process.

Secondly, by analysing the roles and responsibilities, and identifying possible changes to these, it allows the system designer to create designs that will be stable in the face of business reconfiguration.

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

Figure 1

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.

Example: television news industry

Let us look at an example.

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.

Figure 2

When designing client/server systems to support the television news industry, you need to consider the present and likely future structures of information handling:

who is responsible for providing what information to whom?

who wants access to what information from whom?

(Note that, in a competitive world, these apparently equivalent questions do not yield the same results.)

Detailed example: managing copyright clearance

Within the television news example, let us analyse one responsibility chain in a little more detail, to illustrate the concepts. Responsibility for copyright clearance is passed from agent to agent along the production chain. Each agent needs adequate information to fulfil and enforce these and other responsibilities.

Figure 3

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:

contract terms

commercial practice

internal service level agreements

legal requirements

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.

Design for adaptability

Designers need to specify adaptable yet integrated solutions. In the past, adaptability and integration were often opposed goals: the more you had of one, the less you had of the other. Client/server technology helps the designer reconcile these goals.

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.	The business relationship model shows (perhaps many) ways in which an organization may be decomposed. The enterprise model also shows (perhaps many) ways in which the parts of an organization, or separate organizations, may gain by being connected.
Decentralize control subsystems	Bottlenecks of command and control, in which opportunities for massively parallel operations are frustrated by central (decision-making) authority and lack of local empowerment.
Use responsibility clustering to divide a system into subsystems.	The business relationship model should tell us enough about the intentions of the various agents to indicate what are the important states (conditions) for which some agent needs to be responsible. The business relationship model should also tell us which agent (if any) is currently responsible for which states. Where an agent is responsible for two contradicting conditions p and q, convert this into a responsibility for maintaining a proper balance between p and q. Where one agent is responsible for p and another agent is responsible for q, and there is a positive or negative correlation between p and q, consider making one agent responsible for both conditions (and for the balance between them). Where one agent is responsible for too many different things, look for a way of subdividing these responsibilities into separate agents, with low coupling between them.
Improve the overall robustness of a system by improving the robustness of individual components.	The business relationship model may indicate particular areas of uncertainty where early commitment may be unwise.

Cost-benefit analysis

Costs and benefits are distributed in three ways:

They are more or less likely to occur. (In other words, they are distributed in 'probability space'.)
They are likely to occur at different times. (In other words, they are chronologically distributed.)
They affect different people, in different organizations, units, locations, enterprises.

Traditional cost-benefit techniques cater for these three dimensions of distribution in the following ways:

Various (more or less mathematical) techniques are used to reduce the complexity of many different possible futures down to a single expected outcome.
To compare costs and benefits occurring at different times, accountants use discounting techniques to reduce all cashflow to its net present value.
Various (more or less political) stratagems are used to reduce the complexity of many different stakeholders with competing perceptions and preferences. These include power politics (where a single stakeholder dominates the decisions), compromise, log-rolling, consensus-seeking and various forms of voting.

But if the procurement decisions are also distributed, there is little point in artificially centralizing the costs and benefits. Instead, each stakeholder needs to develop a business case from his/her/its own perspective, while considering the likely procurement behaviour of the other stakeholders.

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.

Benefits: improved judgement

Business relationship modelling improves the designer's ability to specify the 'functional' and 'non-functional' requirements of systems, and of object/services, and to identify any business constraints on their distribution. It improves the planner's ability to develop a meaningful business case for investment or procurement, and to establish a low-risk implementation strategy. It enhances the ability of both designer and planner to identify future business trends and analyse the impact of these trends for information systems and services.

Business relationship modelling helps identify significant benefits & opportunities from client/server technology, including:

new ways of putting businesses together

new mechanisms for linking information systems

new modes of service negotiation, delivery & payment

reduced interaction distance

Business relationship modelling therefore helps improve the deployment of open systems and distributed technology.

Conclusions

Technology progresses. The system designer now has many more different technical options. The choice of option is not determined solely by the technology. The designer can and should choose the option that best suits the needs of the business.

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.

Acknowledgements

This paper derives from work done in the Enterprise Computing Project, a collaborative effort, grant-aided by the UK's Department of Trade and Industry under their ODSA programme. This work has benefited from the participation of John Dobson, David Iggulden and Rob van der Linden. Thanks also to David Sprott.

This paper was first presented at IEE International Seminar on Client/Server Computing, hosted by IBM La Hulpe, Belgium, 30-31 October 1995.

References

R.R. Crane, 'The Four Organizations of Lord Brown and R.A.E.W.' (Doctoral Thesis, Kennedy-Western University, 1986)

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 Details

Target Business Improvement
Contact Ian Macdonald	Contact both authors	Contact Richard Veryard