One of the questions that I always struggle with is:
What is the right system architecture?
And more interestingly:
How do I evolve the existing system architecture?
And what appears to be just a technical question, is also a very important customer question as well, but I'll get to that later this week.
A mentor of mine, Bob English, had a particular point of view, that over time I have come to agree with.
He argued the following:
A software abstraction is like a group. The abstraction defines a set of operations and rules about those operations that can have any implementation.
Going one step further, like a group is not just a mathematical abstraction, but describes a fundamental underlying physical reality, a software abstraction that has been in use for a long time also describes an underlying physical reality.
Or to put it differently, in any system that has been evolving for some time, there are abstractions that are defined by the evolving code that describe in abstract terms the real world.
What that says is that a robust reliable and successful system architecture is not an accident, but the manifestation of how the real world actually works. And that is an important realization because it suggests that successful systems are not arbitrary.
Furthermore, the notion that a software abstraction is like a group also suggests that fundamental abstractions of any software system can provide long term sustainable differentiation.
Finally the notion that software abstractions are not arbitrary also suggests that understanding the fundamental abstractions and evolving systems to take advantage of them rather than trying to replace one set of abstractions with another is the fundamentally sounder approach to system evolution.
Comments