Abstraction & dealing with complexity
Abstraction is a strange and wonderful concept that can mean different things to different people. To a painter, it means painting something that is unlikely to be an accurate depiction of what we see but instead use shapes and colours to represent the picture in their mind.
An object orientated software developer may use abstraction to provide a simplified view of the software design by representing something with some or many of its details missing.
How do some people seem to know everything and often be that ‘go-to’ guy or gal? Lets uncover the secret….
In everyday life we use abstraction to help us simplify what could be complex ideas based upon large amounts of information. Without it, we would simply not be able to function
The human brain is a truly wonderous thing that helps us process vast amounts of information every second from our eyes, ears, smell, taste and skin to mention just some of the sensory inputs we receive and with the help from the conscious and subconscious mind, it dramatically filters most of this away. In essence we just get the ‘highlights reel’ of anything that our conscious or subconscious minds thinks is important.
This may mean that the information is inaccurate but as long as it is ‘good-enough’ for our purpose, well…..that is good enough.
For an architect, it is helpful for us to understand and use abstraction for our own purposes. When i consult for a new organisation in a sector that is new to me, i take a quick tour of all of the key systems in my area of concern and what they do (the key high level processes), the people (or roles) that use it and the key information it holds. During this initial exercise, if often find information that is sometimes inaccurate or just too detailed for me at this stage, but i use abstraction to capture the key highlights of each system that are important to me at this time.
I also use my experience to fill in the gaps – for example, imagine i come across an application that manages the product purchases for resale. I may have come across this application before but even if i haven’t, i can pretty well guess at the core functions (supplier management, product management, pricing, supplier invoice matching, etc.) the information it holds (supplier details, product details, etc.) and the people who use it (product purchase processing team). I will also at this stage begin to gain an initial assessment for each of these key components, but that is another story.
After doing this same process for decades, i now can usually gain a relatively detailed (but still abstracted) insight to the key problems and potential challenges even with large enterprises within a week or two. The key is to try and capture the key elements at a consistent high level, ignoring anything that is too detailed or follows a known pattern. Of course it is just as important to identify the resources who hold this information (subject matter experts, documents, etc) as you will need more detail later, but if your goal is to find out details of the key systems then to prevent you getting bogged down early in a sea of information, then aggressively filter out anything that is not needed at this stage – abstract away the complexity that remains.
There are however dangers lurking with abstraction you should be aware of. To get this abstracted overview, you discarded information you thought was not relevant and you filled in the gaps with your experience. The dangers here are hopefully obvious and you need to be on your guard for these.
Sometimes you discard information that you feel is not important but later on you find that this snippet was vital to creating a complete picture. In the example above, it may turn out that the system we use to manage purchases only deals with the majority of products we resell, but some of the most important products or suppliers are actually managed on a spreadsheet or by a different team.
When you fill in the blanks with your knowledge and experience, you are basically making things up that you think are sensible. Now in many cases you are likely to be roughly right, but you need to be on-guard for that unexpected wrinkle. Suppose our purchasing system doesn’t actually hold the supplier details but simply a reference to some other information held in another system. Once again knowledge and experience can minimise this by asking questions about the information held or how the key generic purchase processes are implemented or what system integrations there are or how the teams who are part of this system work with other teams.
So the next time you are faced with mountains of partially accurate and overly detailed information remember to use abstraction as one of your key weapons of choice and soon you will be that go-to guy or gal…..
References: Information theory – Physiology | Britannica Provides an overview of the Physiology. A little old but offers a good abstraction from the detail (see what i did there).
