The BCA Contract Management System

Transcription

1 The BCA Contract Management System James Cole Research Scientist, Elemental Project, DSTC Copyright DSTC,

2 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 Recent References Copyright DSTC,

3 Motivation for e-contracting Contracting is a significant business cost % 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 Increasing complexity of contracts Copyright DSTC,

4 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 Continual development of prototype Researching e-contract issues (to feed into prototype) Copyright DSTC,

5 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 Structured representation of contract documents Copyright DSTC,

6 Scope of BCA (2) Facilitating other contract-related tasks 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 E.g. purchasing software checking for approval before sending order. Copyright DSTC,

7 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 Copyright DSTC,

8 Scope of BCA (4) There are a number of contracting services we have identified. Some of these are listed on the following slides Copyright DSTC,

9 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 Access to data in contracts static data Copyright DSTC,

10 Notification Send notifications to relevant parties , 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 Copyright DSTC,

11 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. Copyright DSTC,

12 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 Revoking violating party s digital certificate Automatically fining the party Copyright DSTC,

13 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, notification and enforcement Copyright DSTC,

14 -The High-level Architecture Copyright DSTC,

15 Requirements Requirements for open-ended set of services 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 Can t predict what data future services will need Copyright DSTC,

16 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 Copyright DSTC,

17 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 Copyright DSTC,

18 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 Copyright DSTC,

19 Satisfying Requirements (2) Requirement: high-level view of contracting situation Solution: Events and Contract-States 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 the contract. Copyright DSTC,

20 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 Deadline for goods delivery has just passed The Supplier has just satisfied all their obligations The value of the total number of goods bought by Purchaser has just changed Copyright DSTC,

21 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 Copyright DSTC,

22 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 Give pieces of information in contract identity Copyright DSTC,

23 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 Components configured with XML definitions Copyright DSTC,

24 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. Copyright DSTC,

25 -Architecture in Detail Copyright DSTC,

26 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 Copyright DSTC,

27 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 Presentation of system information Copyright DSTC,

28 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 I.e. fulfils event subscriptions Copyright DSTC,

29 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 E.g. recurring states Copyright DSTC,

30 -Current Status, Future Research Copyright DSTC,

31 Current Research & Development Current Status of Implementation 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 enterprise integration Copyright DSTC,

32 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 Negotiation support Copyright DSTC,

33 Summary BCA consists of Infrastructure + Components Strong focus on events XML configuration of Infrastructure and Components Provides flexibility and high-level specification Copyright DSTC,

34 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 P. Linington, S Neal, Policy 2003 Workshop Copyright DSTC,

35 Questions? Copyright DSTC,