Ideas, Experiences & thoughts worth Sharing!!!
Category Archives: Architecture
Ok, I am coming back into this after rather a very long time. I have been thinking about starting to write for a while now, as it really helps you think and get clear on your head if you ask me. I do write a bit as part of my job, although mostly technical and content specific and this freedom of being able to write on anything is even more satisfying.
To the topic now, I was having this conversation this morning with one of my colleague and he asked me couple of interesting questions.
- What can you stop doing? (in the context of your job – to maximize time)
- What the best value an Architect can add?
While they both seem unrelated, there is a lot of synergy between these questions and they shape what we do on our day to day job. In my view if you answer question 2, you are answering question 1 regardless.
As an Architect (read as Solution, Data and in general IT Architect), the biggest value one can add is defining the need. The business (from top CxOs to bottom middle managers) generally comes to you as wish list. i.e. what they “think” as the requirement that will satisfy all their needs or solve their current problems. But if you are really good and able to understand the essence of the “ask or wish” in the context of the organisation, its business, underlying constraints (IT, operational, cost, risk, etc) – [see through the clutter and complexity] and able to come up with actual “need“, then you have already solved 80% of the problem. And in my nearly 20 years of experience, trust me, the need is usually very different or much smaller than the original ask.
This I believe is the biggest value the architects can add. So what you need to stop doing is taking the business wish list as a Gospel and turn the world upside down to solve it. As once you start on the wrong foot, the chances are you are multiplying the waste factor from then on.
So how do you know you have understood the problem and you have established the need. An Interesting thought that can support this here, – don’t know the source but I do remember and made a lot of impact in my life is “if you understand the problem, you should be able to articulate it in simple language under 30 seconds to anyone, failing that means you don’t any idea about what you are talking about”.
This however requires a holistic knowledge of business, (i.e. domain knowledge, how business works and its people), information being processed and churned in & out (data) and the technology in place to support and scale the above. And this comes with experience.
Some of the other techniques you can use to filter down waste from your downstream activities, you can adopt methodologies like critical chain (especially the network diagram/logic that maps the network activities), agile or recruit a bloody good project manager or scrum master who will ensure the effective usage of time & resources once he has been given the clear, concise business need and what need to be delivered.
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.