veryard projects - innovation for demanding change

business relationship modelling

veryard projects > modelling > business relationship modelling
we offer scope material links

management briefings and technical education

independent advice on tools and methods

Business Relationship Modelling is a technique for planning business processes and systems across organizational boundaries.

This technique predates the BPMI proposal, which we are currently evaluating.
white paper 

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

on this page

[purpose] [business drivers] [strategic questions] [suitability of the technique] [use of the model] [benefits] [description]
other pages

[business relationship management] [business relationship clustering] [enterprise modelling] [modelling]


notion finder

contact us

Purpose of Business Relationship Modelling

Business Relationship Modelling is a methodical approach for the exploration of 
  • organizational structures,
  • federations,
  • system networks, …
… in the face of 
  • policy changes,
  • design problems,
  • technological opportunities, …
… in order to 
  • plan,
  • achieve,
  • support,
  • design,
  • decide,
  • resolve, …
… such issues as 
  • organizational changes,
  • technical configurations,
  • technical systems policy,
  • system requirements, …

Business Relationship Modelling is 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.

The Business Relationship Model defines 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.

Business drivers

Strategic Flexibility

  • outsourcing
  • inter-firm cooperation
  • ‘Liberation Management’ (Tom Peters)

Organizational Flexibility

  • decentralization
  • transient organization

Technological Flexibility

  • portability
  • capability
  • …bility

Strategic questions to address

Business/Market Strategy

  • what are the key emerging roles?
  • 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?

Information/Communications Technology Strategy

  • what systems and infrastructure do we need:
    • to support chosen roles?
    • to support chosen alliances?
  • how do we maximize flexibility?
  • what are the technical risks of chosen business strategy?

Suitability of technique

Business Relationship Modelling is suitable for 
  • business process engineers
  • planners
    • of information technology
    • of communications technology
    • of quality systems
  • developers
    • of distributed/networked applications (including complex Client/Server systems) and infrastructures
    • of commercial information services (typically object-oriented)
  • network/market strategists, …
working for or within 
  • large decentralized organizations,
  • inter-company networks, joint ventures
  • telecommunications and value-added network (VAN) companies, …

How is the Business Relationship Model used?

When combined with commercial and technical information, the Business Relationship Model enables the production of This involves making three kinds of judgement: design, investment/procurement and migration planning judgements.
Design judgements
Investment/procurement judgements
Migration planning judgements
System specification 
  • Distribution of ‘functional’ requirements
  • Specification of ‘non-functional’ requirements
  • Specification of appropriate distribution infrastructure / topology
  • Design for flexibility
  • Integration strategy
Technology benefits & opportunities 
  • new ways of putting businesses together
  • new mechanisms for linking information systems
  • new modes of service negotiation, delivery & payment
  • reduced interaction distance
  • Decoupling actions
Object/service specification 
  • Identity (meaningful description)
  • Viability (value-added)
Business issues of federation 
  • heterogeneous financial disciplines / practices
  • lack of hierarchical authority
  • role of market regulators
  • Configuration paths
Design process 
  • Dynamic requirements engineering
  • Design without central authority
  • Negotiation of interfaces
Information management issues 
  • information as commodity
  • service paradigm
Timing issues 
  • Critical mass of demand
  • Reliability of supply

Benefits of technique

Improved judgements
  • business flexibility
  • responsiveness to customer requirements
  • opening of technological options
Clearer links between requirements
  • business strategy
  • organizational structure
  • technical infrastructure
Integration of plans
  • solution architecture
  • business case
  • migration plan
Improved deployment of solutions
  • open systems
  • distributed technology

Description of technique

What is a business relationship model?

The business relationship model consists of a network diagram with supporting definitions and other information.

The business relationship diagram is a simple picture showing the chosen area in the middle, with all other departments, companies and agencies around the outside, as a network of business interfaces.

How do we analyse each business relationship?

For each business relationship, we need to understand: At some stage, we may need to analyse some of these relationships in more detail. This would involve looking at any specific contractual mechanisms, service level agreements, monitoring reporting and exception handling arrangements, shared systems and so on.

How do we analyse the whole network of business relationship?

As a completeness check, each model should include: Carrying out this exercise from the perspective of each department or division within a large organization, or from the perspective of each player in a complex market venture, often reveals some interesting differences of view.

When we put these models together, we typically identify some interesting holes in the network of relationships.

Acknowledgements / Prior Work

Some of this paper derives from work done in the Enterprise Computing Project, a collaborative effort involving Texas Instruments Software and Architecture Projects Management, grant-aided by the UK's Department of Trade and Industry under their ODSA programme. The Enterprise Computing Project developed a version of Business Relationship Modelling specifically for Open Distributed Processing, under the name Enterprise Modelling Methodology (EMM/ODP). Some of the early publications use this name.

This work has benefited from the participation of John Dobson, David Iggulden, Rob van der Linden and Ian Macdonald. Thanks also to David Sprott.