Deriving abstractions for a given problem description is always challenging. No matter what your experience level is, a new scenario will always be challenging to model. At the core of the problem is something known as "Inverse Problem" i.e. it is often easy to observe abstractions in hindsight than in foresight.
The modeling that we do, deals with IT systems and people operating those systems. What transpires from it is that the observed behaviour of a system is always a reflection of interference of multiple responsibilities of that system. To give an example, a lock is a lock because of the key. Should we lose the key, the lock is just another dead weight. So when we verbalize lock, certain properties come to our mind and weight is not one of them. But the properties that we perceive as properties of a lock are indeed interactions between a lock and a key.
It is very easy to extrapolate the lock example for unknown scenarios. In such cases we struggle because we have no clear idea about the underlying components and their interactions. So our best attempts are guess work. And if it works for scenarios at hand, we should stop generalizing. By extension of this argument, we can see that we should not strive for universal abstraction but try and model based on certain heuristics and create a workable domain and leave our abstractions incomplete. At the same time, we should have the humility to accept that our abstractions may be wrong but we should be ready to change them if such a need arises. To conclude, in the session, I want to highlight difficulties faced in creating abstractions and how to cope with such difficulties. This is useful from developers to system architects and even CTOs to some extent.
More details: https://confengine.com/agile-india-2020/proposal/12042
Conference Link: https://2020.agileindia.org