In a recent post I stated that “abstraction and concretion are quite useful in technical problem solving because they cause us to focus on the simplicity of the problem at hand without the clutter and noise of the surrounding environment.”
Just how does that work?
Abstraction is the synthesis of general concepts and principles from specific entities and applications. It is the opposite of concretion, which is the conversion of a concept or principle into an application-specific reality. Abstraction is the transcension from the concrete domain to the abstract domain; concretion is the return trip.
The concrete domain is where we exist, where our processes and systems operate, where goods are produced and services provided.
I get it – it’s the real world.
It’s also a place of difference and distinction. It’s characterized by complexity and diversity; it’s where commonality dissipates in the presence of uniqueness.
Maybe I don’t get it.
The abstract domain is just the opposite – things are simple there. But nothing gets built, no services are provided and no money is made. And … visiting too long can be hazardous.
Together, however, these two domains coexist and complement one another. It’s this latter point of complementarity that I was alluding to in the opening statement, and elaborated upon in the post entitled “Universally Inherent Characteristics”. In that post, the six core attributes of the process input were identified:
These six universally inherent characteristics are the result of synthesizing the attributes of disparate processes into core principles. This is an example of an abstraction.
I’m starting to get it now.
By doing this early in a technical problem solving situation, the problem solver has simplified the problem into manageable, constituent parts that are more easily investigated during root cause analysis.
Concretion brings the problem solver back to the concrete domain, where the specific problem in question resides, for inquiry and examination. Using this domain translation method, the problem solver will determine the ultimate root cause of the problem and develop an effective and permanent solution.
Oftentimes, though, problem solvers will attempt to solve the problem without leaving the concrete domain. This leads to partial fixes – i.e. band aid solutions – that only temporarily relieve the symptoms of the problem, but fail to address root cause.
I know that’s right!
It’s difficult to develop solutions in the concrete domain because
• ideas originate at ground level where perspectives are narrow
• creativity and innovation are severely limited
• the solution space is small
• potential solutions are design- , technology- and experience- specific
When we do so, we find the solutions are unremarkable, partially effective, and difficult to sustain.
However, by synthesizing the problem and solving it in the abstract domain first, we find
• panoramic idea space
• unlimited creativity and opportunity for innovation
• boundless solution space – approaching infinity
• solutions that are design- , technology- and experience- neutral
• solutions that are effective, lasting and revolutionary in their simplicity
How do I know it will work?