I have recently read a book called Lessons in Grid Computing: The System Is a Mirror. The central theme of the book is that the systems we build mirror us - what we like, how we do things, etc. I am sure most of us have experienced this throughout our lives. For example, by looking at the car (including the interior decorations) you can sort of guess the owner's personality and interests - You Are What You Drive/Eat/Build...
An important corollary of the mirror theory is that if you want to develop and improve your system effectively, you must structure your organisation to mirror the system that you are building. For example, if your software system consists of closely collaborating modules, then the respective teams who are managing those modules must be communicating closely also, or perhaps have them built by the same team; on the other hand, if the system consists of autonomous modules that can live independently, and they communicate through a broker, then the organisation structure should also reflect these characteristics - the team who is responsible for the broker must keep all the other teams informed about design decisions and collect feedbacks from them.
It is sad but true that many ISVs do not orient themselves to reflect what they build (hence the market they are serving). I have witnessed companies (large and small) that do not develop their products in a collaborative manner when it's needed. Instead, strategic decisions about the product architecture were made by individual teams without any cross-team reviews, and even worse, such decisions were made by one individual in some companies.
The system is a mirror, and to correct inadequacies we see in the reflection, we should not simply cover the mirror, or replace it with another.
1 comment:
The concept can also be extended to service organisations, not just systems/products.
Post a Comment