TDT4252 Modelling of Information Systems Advanced Course

1. TDT4252Modelling of Information SystemsAdvanced Course Sobah Abbas Petersen Adjunct Associate Professor sap@idi.ntnu.no Lecture 2: Why model?

2. Lecture 2 – Why model? Today: • Why model? • Illustrate the roles that modelling could play in real world situations, using an example. • Pensum: Dellarocas, Chrysanthos and Klein, Mark. A Knowledge-Based Approach for Designing Robust Business Processes. W. van der Aalst et al. (Eds.): Business Process Management, LNCS 1806, pp 5065, 2000. Springer-Verlag Berlin Heidelberg 2000. Lecture 2: Why model?

3. Motivation for this Lecture • To show how models could be used for reasons other than IS design. • To analyse a real world situation using simple modelling ideas. • To illustrate how a simple model could help identify serious gaps in organisational processes and management. • To highlight the roles a model could play. Lecture 2: Why model?

4. Case: Barings Bank • The collapse of the Barings bank (1762 to 1995) is one of the most dramatic disasters in the financial world. • In February 1995, 233-year old Barings Bank went bankrupt! The entire bank collapsed because of losses of $1.4 billion (~8.3 billion NOK) incurred in a matter of days by a single trader. Lecture 2: Why model?

5. Collapse of Barings Bank • A trader engaged in unauthorised futures trading in the Singapore exchange of the bank. • He was able to maintain his unauthorised and highly risky trading activity undetected by the bank’s head office in London until nearly the very end. • This was possible due to inadequate internal controls and other process failures! Lecture 2: Why model?

6. This Lecture A Knowledge-based Approach for Designing Robust Business Processes • Methods: • Exception handling • Model-based fault diagnosis Lecture 2: Why model?

7. Background for this work • Previously managers had relied on their experience and understanding of experiences to handle exceptions. • Such experiences could be captured in a process handbook. • Knowledge-based approach. • Agent coordination, e.g. in automated processes. Lecture 2: Why model?

8. Exception Handling • Definition: • “An exception is any deviation from a normal collaborative process that uses the available resources to achieve the task requirements on an optimal way.” Lecture 2: Why model?

9. Exception Handling – an example Contractor Role Subcontractor Role Correct and reliable message handling Create Request for Bid (RFB) RFB is not cancelled or changed Create Bid Subcontractor is available Cost doesn’t change Bid is correct and timely Select Bid Atleast one accepted bid Contract matches RFB No better options appear Contract is not cancelled or changes Perform Work Correct and timely results Subcontractor does not cancel Receive results Lecture 2: Why model?

10. Knowledge-based Approach to Exception Handling • Identify possible exceptions associated with each element in the normal process. • Use information from the exception taxonomy to find ways to avoid or detect exceptions and identify ways to handle them. Lecture 2: Why model?

11. What happened at Barings Bank in 1995? Let’s model it! Lecture 2: Why model?

12. Why is this case interesting? • “It was a result of a series of undetected exceptions in one of the bank’s secondary business processes…” • The approach described earlier (knowledge-bases, exception handling) can be applied to: • Design new processes. • Test the robustness of existing business processes: • Expose potential dangers and suggest possible fixes. Lecture 2: Why model?

13. The Barings Future Trading Process Customer Place request Buy Futures Contract Receive Certificate Send Payment Trader Transfer Funds Bank Treasury Prerequisites Flow Lecture 2: Why model?

14. Identify Exceptions – prerequisites and flow Wrong certificate Unauthorised trade Customer Place request Buy Futures Contract Receive Certificate Send Payment Trader Transfer Funds Bank Treasury Funds misused Prerequisites Flow Lecture 2: Why model?

15. Avoid or detect exceptions • Use information stored in the taxonomy to find ways to avoid or detect exceptions. • In Barings, since the trading process involves several independent entities (customer, bank, exchange) and requires initiative from the trader: • No practical mechanisms for avoiding exceptions. Lecture 2: Why model?

16. Detecting exceptions - Logging Main Process A B Update Log B Update Log A Exception Avoidance Process Prerequisites Exclusive access Periodic Consistency Check Lecture 2: Why model?

17. Logging • Logging is one (out of several) generic mechanisms for detecting prerequisite violations. • It involves recording all occurrences of activities in some reliable storage medium and checking periodically for violations. • For logging to be successful, there are two important requirements: • i): All occurrences of processes (A and B) are logged reliably • Ii): The logs can only be modified by the processes that do the logging. Lecture 2: Why model?

18. Prerequisites Barings Process with Logging Flow Exclusive access Customer Place request Update Commits Update Rec Update Paid Buy Futures Contract Receive Certificate Send Payment Trader Update Reqs Update Funds Transfer Margin Funds Bank Treasury Periodic Consistency Check Lecture 2: Why model?

19. Looking for Gaps (1) • We can compare the process derived using this approach to the Barings process. • Although Barings did log some processes, it had two major gaps: • 1. It failed to log and compare the amount of funds forwarded by headquarters to the trader to the amount actually paid by the trader for the customer trade. • Violation of requirements (i) (log all processes reliably). Lecture 2: Why model?

20. Barings Process: Gap 1 Customer Barings failed to compare funds transferred against funds used for client transaction Place request Update Paid Buy Futures Contract Trader Update Funds Update Reqs Transfer Margin Funds Bank Treasury This was missing!!! Periodic Consistency Check Lecture 2: Why model?

21. Looking for Gaps (2) • Although Barings did log some processes, it had two major gaps: • 2. The trader was also in charge of the back room operations in the Singapore branch and he was given authorisation to modify the trades logs • Violation of requirement (ii): modification of the logs. Lecture 2: Why model?

22. Barings Process: Gap 2 Barings failed to safeguard against exclusive access violations because trader was given log modification privileges Update Commits Update Rec Update Paid Buy Futures Contract Receive Certificate Send Payment Update Funds Transfer Margin Funds Periodic Consistency Check Lecture 2: Why model?

23. Barings process: Gaps (3) • One single trader had two (conflicting) roles: • Trader • Head of the settlements operations (inside office) • He was his own boss! • These gaps were the bank’s own deficiency in internal audits and risk management. Lecture 2: Why model?

24. What does this case illustrate? • A very simple model of the Barings Bank trading process allowed us to identify significant flaws or gaps in the process and helped to suggest ways to improve or avoid problems. Lecture 2: Why model?

25. What support can models and modelling offer? • Study problems encountered – why something happened or is happening? • How can a business or work process be improved? • Ideal processes – design robust processes for any situation. Lecture 2: Why model?

26. Models and IS Customer Place request Update Commits Update Rec Update Paid Buy Futures Contract Receive Certificate Send Payment Trader Update Reqs Update Funds Transfer Margin Funds Bank Treasury Periodic Consistency Check Lecture 2: Why model?

27. Models and IS • Models can also help to identify IS needs and requirements. e.g. • Logs or databases to support the Barings processes. • Access rights for modifying the logs. • Automated consistency checks and comparisons. • Others. Lecture 2: Why model?

28. Models and Business • Models can help management understand fully the business they manage: • Business risks • Audit requirements • Dual roles and violations • Clear processes and their needs Lecture 2: Why model?

29. Summary • We have considered the roles that modelling could play in an enterprise, using a real life example. • This example highlighted the importance and the benefits of modelling for organisational processes and management. Lecture 2: Why model?

30. Next Lecture • Thursday, 19 January, 08:15 – 11:00hrs, room MA21Prof. John Krogstie will take this lecture. • Topic: Perspectives of Modelling. Lecture 2: Why model?