Ideas, Experiences & thoughts worth Sharing!!!
It Depends … (really???)
It is a very short blog and more like rant rather!
Nothing gets me more annoyed than people answering “It depends…”
Especially when asked about what is your organization reference architecture? Associated principles, guidelines, recommendations, etc. To me it is one of the laziest answers and having no foresight whatsoever.
To start with, it depends on what? I mean what are the variables that control the decision making process? What are their ranges? What are the constraints that could influence these decisions? Considering the underlying infrastructure, have we done any benchmarking exercise and have recommendations so that not every project ends up doing the same thing over and over again? What are the limits of current systems, framework & infrastructure? How do you govern architecture compliance if all you have is “It depends” – especially in a multiple vendor scenario?
Some of the key problems in leaving decisions to individual projects (otherwise called “it depends” operating mode) are,
- Deviations from the organization level architecture strategy.
- The quality & effectiveness of a solution is left to the competency of an individual/team, despite having an architecture practice (or) capability.
- The by-product of the above two would be “Technical Debt”.
- Wasted effort in repeating items and worst still end up with different solutions each time
So what can you do?
No individual organization will need to solve endless spectrum of problems (to leave the solution until the problem arises). Depending the organization business, domain, capabilities, products, infrastructure, etc., the spectrum could well be defined from various dimensions. Some of the dimensions / variables could be,
- CRUD transaction volumes (low, med, high – sycn/async – consistency rqmt, etc),
- Rule engine ,
- Calculation engine,
- Integration models (p2p, pub/sub, req/response),
- User Interface models (web, mobile, desktop, apps, etc.)
- MI capture/report
- , could go on…
And based their values, and current capabilities status, have recommended solutions (templates/patterns/POCs) readily available, so that an individual projects could simply adopt them rather trying reinvent the wheel every time and worst still end up with completely different / inconsistent solution to a single problem.
One may question the need to solve or have a solution for a problem when it isn’t even arisen yet. That is the investment you make in order not to end up with the longer term problems stated above. The level of detail one need to go could be controlled depending on the likelihood of occurrence of a particular problem. For e.g. a small scale retail organization need not go all the way down to having a fully working Proof of concept for high volume, real-time information management. But could just define parameters on what would require such a solution so that when a project team encounters a requirement they know they need to build something new.