Abstraction and Business Processes
Part of my new role at APR is to make sure we are learning about the most useful technology. When thinking about technology it is easy to get caught up in the allure of artificial intelligence and how it is going to ‘revolutionize actuarial work’, but there are probably some basic computer science lessons we should master first. In fact, there may be relevant lessons from before computers even existed. Chapter one of the seminal computing textbook ‘Structure and Interpretation of Computer Programs’ begins with an exert from 1690, in which John Locke explains the three ‘acts of mind’ which explain how humans can solve complex problems:
- Combining several simple ideas into one
- Comparing two ideas
- Separating ideas from their context
The third of these items is called ‘abstraction’ and that is the topic of this article. If this sounds too theoretical or too focused on computers, then fear not – the purpose of this article is to explain how this principle can be applied to activities that almost certainly affect you at work: writing documents and organising teams and processes.
What is abstraction?
The word ‘abstract’ is sometimes interpreted as meaning ‘difficult to understand’, but we need a more precise and nuanced interpretation here. In programming there are two popular ways to abstract code: object-oriented and functional programming. I think of object-oriented programming as the abstraction of nouns and functional programming as the abstraction of verbs. To illustrate this distinction imagine you have just sat down for a team lunch. First, you pick up the menu and consider your options, thinking about how hungry you are, your tastes and allergies and whether you are trying to diet. Everybody else is weighing up similar considerations. We are all different, but we share some common traits and abilities, one of which is being able to choose from a menu. In technical terms we are all objects of the abstract class that I call ‘hungry co-worker’.
Now consider the waiter. He arrives at the table and methodically works his way round the table collecting the orders. Some people ask questions about the menu, some want modifications, and some want to start a conversation with the waiter, but having done this many times before, the waiter manages to collect each order without having to think about all the subtasks like smiling at the customer, offering recommendations, and writing in his notepad. From the experienced waiter’s point of view ‘take a customer’s order’ is an abstract function, which converts a customer’s words into the shorthand required by the kitchen staff.
I’ll admit that this metaphor isn’t perfect, but it does help illustrate some important aspects of abstraction:
- Abstraction is a ‘black box’ that hides a lot of the complications. The waiter doesn’t need to know why the customer chose a dish and the customer doesn’t need to know the shorthand for the dish she ordered.
- As a corollary, if the waiter or the customer insisted on seeing inside the black box, then there may be little benefit in using abstraction in this way.
- In both types of abstraction there are ways to turn inputs into outputs and the format of those inputs and outputs is clearly defined e.g. ‘menu into order’ and ‘order into shorthand’.
- The choice of how to abstract things makes a difference. Imagine if the waiter was in charge of picking the food or the customer had to convert the order into shorthand. This does happen in some restaurants – but it can be a very different dining experience.
- Abstraction is a bit like delegation, where the implementation details are left to someone or something else.
- Abstraction makes it easier to describe (and execute) more complicated processes e.g. taking an order is one part of a waiter’s job; a waiter is one member of staff in a restaurant; managing staff is one part of running a restaurant, which is one part of managing a chain of restaurants.
Over the past fifty years, computing programming has transformed from manually configuring 1s and 0s on a punch card to typing high level commands that can retrieve complex data with a single line of code. Programmers use the concept of abstraction to build their own functions and objects on top of those defined by other programmers. By refactoring, debugging and observing successes and failures, a good programmer learns when and how to apply abstraction. The concept of abstraction is therefore both fundamental and explicit in computer science. I believe that the concept is just as fundamental to all actuarial work – but perhaps less explicit.
How does abstraction apply to things other than programming?
A typical novel is linear and requires the reader to start from the beginning and read to the end. In programming jargon this would be described as ‘procedural’. However, technical or business documents are consumed in different ways and the concept of abstraction can be applied:
- A good executive summary tells the complete story as concisely as possible. By convention, the reader knows that detail is available in the body of the document but expects to understand the conclusions without referring to it.
- Good technical documents use references (e.g. contents pages, footnotes and hyperlinks) so that the reader can navigate up and down the ‘pyramid of abstraction’ zooming into the detail to answer a question and then zooming out to see the big picture.
- Although jargon and acronyms are often discouraged, these are forms of abstraction and should be used in certain circumstances: when the abbreviation is clearly defined; when the abbreviation is sufficiently shorter than the full definition to make it worthwhile, and; when the abbreviation makes the text easier to understand.
If you have ever read a 100+ page technical specification, you will probably have seen a fair amount of duplication and inconsistency. Of those I have seen, I believe most could be shortened and made easier to understand by better applying the concept of abstraction. But let’s shift the focus from reading the documents to writing them. Often, they are compiled by teams, where each individual is asked to contribute a section. The problems arise when the requirements are not sufficiently well defined for the section author to write the section, without constantly referring to what is being written elsewhere, or asking what the target audience would like to see. Another common situation is for a manager to ask a team member to produce some slides to present to a committee, only to be disappointed that the team member has adopted the wrong style or focussed on the wrong things.
In both cases, there is a friction caused by the fact that there is ‘delegation without abstraction’: the problem is not so clearly defined that the delegate could produce what the delegator had in mind. There are two easy solutions to this situation: the manager should only delegate tasks that are clearly defined; or, the manager should recognise that this is part of the learning process and should lower their expectations. Perhaps an even better solution would be to recognise that this is a learning process and so use it as a prompt to develop training materials for the next delegate in that position.
Writing documents is just one of many business processes but the concept of abstraction could be applied to many others. Some processes are well defined, repeated and easy to manage, while other processes vary or require expert judgement. It does not make sense to try to organise the teams, tasks and information for all of these tasks in the same way. By looking for the conditions of good abstraction we might conclude that the quarterly financial reporting process is well defined with strict controls and is therefore suitable for abstraction leading to project plans, delegation and top-down briefings. On the other hand, financial transformation projects may have evolving requirements and so an Agile approach with widely shared technical detail might be better.
Most finance and actuarial departments have some concept of ‘end user computing’ (EUC) to refer to tools that are used in business processes but aren’t supported by the IT department. Many people use this phrase as a euphemism for Excel spreadsheets, but that oversimplifies the situation. I believe the key distinction between systems and EUCs is trust. A system is tested and guaranteed by the manufacturer so that the user can trust it will do what it is supposed to. The danger of using a spreadsheet is that someone else has changed a formula or the upstream of downstream processes have changed, meaning that the user can’t trust that the spreadsheet is doing what it should. Most companies institute EUC controls and guidelines which mitigate some of the risks, but certainly not all.
The residual risk stems from the fact that spreadsheets are often chained together as steps in a long process, much like the chapters in a novel. This is ‘modularisation without abstraction’: changing one spreadsheet necessitates changes to lots of other spreadsheets. If the principle of abstraction were applied, spreadsheets would be arranged not in a chain but a pyramid, so that changing one spreadsheet changes the numbers, but there is no need to change formulae in any other spreadsheets. I have never seen this idea described in any EUC guidelines, but I will keep making the case.
Conclusion
Abstraction is a concept that most people apply without really thinking about it. Learning to code has forced me to think about it and thinking about it has helped me organise my thoughts, documents and processes. It has encouraged me to structure things so that problems can be solved once, and the solutions reused. It has helped me theorise why some things failed e.g. ‘delegation without abstraction’ or ‘modularisation without abstraction’. And it has made me wonder what other lessons I should be learning from computer science.
Phil Creswell
September 2020
