The BCA Contract Management System

The BCA Contract

Management System

James Cole

Research Scientist, Elemental Project, DSTC

Contents

• Motivation for e-Contracting • BCA – Background

• Scope of BCA • Scope – Services • Requirements

• Satisfying Requirements

• Satisfying Requirements – Summary • Issues with Solution

• Infrastructure and Components • Definitions

• Current Research and Development • Future Research and Development • Summary

Motivation for e-Contracting

• Contracting is a significant business cost

– 0.5-1.2% of total transactions (Goldman Sachs)

• Greater efficiency and more effective management

• Importance highlighted by

– Increasing use and greater significance of contracts

• Adoption of new business models

– Outsourcing, value chains and similar collaborations

• Requirements for regulatory compliance

– As prescribed by various regulatory bodies

BCA - Background

• Grew out of role-based contract framework

– Proposed in 1994 (SDNE’94 and INET’95 papers) – Facilitate inter-organisational transactions

– Proof-of-concept prototype (CORBA)

• More complete design started in 2001

– As part of Elemental project - enterprise modeling – In response to increasing business need

– Utilising more recent technologies / concepts

• XML, Web Services, Event-based paradigm, Policy Languages

• Current work

Scope of BCA

• “General Contracting Support”

– The support necessary for managing all or most contracts, regardless of their type

– Automation of typical contract management tasks

• Drafting, validation, negotiation, archiving, monitoring, enforcement etc.

– Applicable to wide variety of contract situations

• Different contracts and contract management needs • Different IT systems

– ERP systems, In-house systems, etc

Scope of BCA (2)

– Tasks associated with a specific contract-type

• Examples: procurement for certain defence contracts; tendering for certain construction contracts

• Create ‘plug-ins’ for supporting these tasks

– (or have system interact with pre-existing systems for handling these).

– Tasks using software with independent existence

• Examples: business workflow, word processing, spreadsheets • Provide these with contract-related data

– E.g. data on state of contract, that workflow uses to select a branch

• Receive data from these

• Potential for tighter coupling

Scope of BCA (3)

• Providing both general and other types of

support in an

integrated

manner

– The services and facilitated tasks must be able to interact with each other and share data

– Don’t want them to be islands

– Make use of common infrastructure • Triggering notifications from both

Scope of BCA (4)

• There are a number of contracting

services we have identified.

• Some of these are listed on the

following slides

Repositories

• Contract Forms Repository

– Material for construction of contracts

– Including: standard contract forms and clauses

• Notary – agreed contracts

– Secure storage of signed contract instances

– Links to related contracts and business documents

– Role-based views of contracts

• E.g. only show clauses of relevance to a role

Notification

• Send notifications to relevant parties

– E-mail, instant messaging …

– In response to

• Any type of event; e.g. deadline, contract violation

– Data may be dynamically substituted in

notification text

• Facilities pro-active management

– reminders, warnings …for contract-related

actions

Contract Monitoring

• Only possible for some conditions

• Many different types of conditions

– Dependent on contract

– Generally, conditions involving

• actions of parties, temporal conditions, states…

• Different conditions may be more amenable to

different monitoring strategies.

Contract Mediation, Arbitration

and Enforcement

• Violation detected but …

– … parties disagree on who is at fault

• First step ? Mediation

– Attempt to settle a dispute through Mediator – May result in contract amendment

• If settlement not possible ? Arbitration

– Involves third-party authority ? Arbitrator

– Instructs Enforcer to effect some corrective measures For example

Summary of Scope

•

Support an open-ended

yet integrated set of functions associated

with the fulfilment

and management of contracts.

•

Some specific functions to be supported

include the repositories, monitoring,

Requirements

– There will be interaction between some of them

• Example: Notification about violations picked up by monitor

– There will be some services using the same input data

• Tendering ‘plug-in’ system may use same states as monitor

– Avoid conflicts between the services

• Who gets to update shared data?

• (some are problems inherent to an open-ended system:

– If components ‘disagree’ about meaning of data – If components have overlap of functionality)

– Services’ data-requirements depends on its nature

Requirements (2)

• High-level view of contracting situation

– Required for many of the contracting services

• E.g. monitoring and notification

– Interpreting raw input about contracting situation in terms of contract

• Dynamic modification requirement

– Run-time addition, modification, removal

• E.g. of notifications

– E.g. because of contract amendment or changing needs of signatories

Requirements (3)

• System applicable to wide variety of

contracting situations

– Definitions required (notifications etc)

– Integration required with external systems

• Structured representation of contract

• Also, security and trust

Satisfying Requirements

• Requirement for open-ended, integrated, services

• Solution: Centralised infrastructure, managing

data

– Used by the Components implementing services

– Enables data-access, to any service, present or future

• The default way of storing data

– Enables safe data sharing / interaction

• Infrastructure controls updating of, and access to, data • Results of processing are distributed by this infrastructure

Satisfying Requirements (2)

– These make up the major component of the data managed by infrastructure

• Distillation of raw input from signatories systems

– Converted to higher-level (complex) events and state updates

• In other words:

– The raw input interpreted in terms of the contract

• Monitoring is also a form of this

– Result of a check is an event indicating contract (non-)violation. – I.e. interpreting contract situation in terms of its conformance to

Satisfying Requirements (3)

• The data managed by centralised infrastructure

– Contract States

• Total worth of the goods bought by Purchaser

• Number of days the delivery of goods are currently late

– Static Data

• State date of contract

• The minimum monthly purchase amount (that was defined in contract)

– Events

• Purchaser has just sent payment

Satisfying Requirements (4)

• Requirement: dynamic modification

• Solution: input via event subscriptions

– Components subscribe with infrastructure to

receive types of events

– When modification occurs, data required by

component changes - change subscriptions

Satisfying Requirements (5)

• Requirement: system applicable to wide variety of

contracting situations

• Solution: input via event subscriptions, and XML

definitions of services

– Definitions of notifications, conditions to monitor etc

• Requirement: Structured representation of contract

– We have an XML schema for this

• Defines clauses

Satisfying Requirements

-Summary

• Data managed by central infrastructure

– Controls access to, and updating of, data

• Events, Contract-States and Static Data

– Higher-level constructs for defining events and states

• Components interact with each other via

infrastructure

– Events, and events causing updates to states

Issues with Solution

• Centralisation

– Performance – Scalability

• Multiple components accessing data

– Race-conditions, logical consistency

• Transactional controls

• Updates being managed by the infrastructure • When event occurs, states always updated first.

• Issues should be addressable.

Infrastructure and Components

• Intermediary

– Raw input, basic formatting as events

• Event Distributor and State Manager

– Distributes events

– Updates states (in response to events)

• Event Manager

– General event generation: complex events,

temporal events…

Infrastructure and Components (2)

• Monitor

– Event infrastructure enables multiple monitoring strategies

• E.g.s of strategies: production rules, neural net, etc.

• Notifier

• Contract Repository, Notary

– Contract construction material

– Secure storage of agreed contracts – static data

• User-Interface

– Control of system

Infrastructure and Components (3)

• Events are XML, and have a type

• Components subscribe to types of events

• Components make requests for contract-state and

static data

• Components generate events

• Event Distributor receives all events

– From Intermediary and other components

• Event Distributor distributes events

Definitions

• Most definitions (notifications, policies, events etc) make use of

– General expression language

• >=, +, -, if-then, for-loops, etc etc.

– Event pattern language

• Event sequences, parallel sequences, predicates over event contents etc etc etc.

– E.g. in a notification

• May use expression language to include calculated value in notification text.

• Generated on occurrence some event pattern

• As well as custom constructs for each type of definition

Current Research & Development

– Core of infrastructure, monitoring, notification, user-interface, notary

• Fleshing out implementation

– More complex states and events (e.g. sliding windows), etc etc.

• Implementing Community Model in BCA

– Community in ODP sense of the word.

– Roles, assignment of obligations to roles, delegation of obligations etc etc.

• Relationships with other enterprise concepts

– processes, actions, events, decisions …

Future Research and Development

• More formal representation of contract

semantics

• Extensions to prototype

– For better trust support

– For discretionary contract enforcement

• tools implementing subjective logic principles

– Add analytical and predictive monitoring

• Longer-term

– Options for checking legal purpose of contract

• compliance with legal rules of an outer system

Summary

• BCA consists of Infrastructure +

Components

• Strong focus on events

• XML configuration of Infrastructure and

Components

• Provides flexibility and high-level

specification

Recent references

• On Expressing and Monitoring Behaviour in Contracts,

– Z. Milosevic, G. Dromey, EDOC2002, Sept.’02

• Discretionary Enforcement of Electronic Contracts,

– Z. Milosevic, A. Josang, T. Dimitrakos and M-A Patton, EDOC2002

• Establishment of Virtual Enterprise Contracts,

– G.Quirchmayr, Z. Milosevic, R. Tagg, J. Cole, S. Kulkarni), DEXA2002, Sep’02.

• Enterprise Federation through Web Services based Contracts Architecture

– S. Kulkarni, Z. Milosevic, OMG Web Services Workshop, Feb’02.

• Checking of Business to Business Contracts