I get the feeling every now and then, that software products or solutions sometimes fluctuate too much towards one end or the other in the technology-business scale (or bottom up – top down).
Now, although I’m a technologist, I favour a bias toward the business end as any technology should surely serve a purpose and should not be built because it can be built. I have seen this challenge play out several times in my career as I have witnessed technologically motivated people build ‘cool’ apps or tools with weak consideration of how it fits the business need. Therefore, I normally strongly argue that any software development process must be top down.
I should clarify this – When I say must, I actually mean: should predominantly be. This is because, good foresight from someone who understands the technology and appreciates enough of the business domain knowledge often facilitates the better and more successful solutions/products/tools. How many times have you heard people talk about getting software developers exposed to the everyday business challenges? A lot, right? Whilst I agree in the sentiment of this, I do not agree as passionately as some as I believe it is not an individual developer’s responsibility to ensure a solution fits a need. Instead I believe that it is the responsibility of the process to ensure that a requirement is created by those with the business domain knowledge and translated successfully along the software development journey between those who handle it, each understanding the part that means something to them.
Process itself, is something that I could discuss in a series of posts on its own so I will end that particular point here. However, the relevance of mentioning process is that it shares that same slot of being an unsung hero of importance alongside architecture.
Getting the right architecture in place facilitates the evolution of a software offering in the right direction. Architecture is just the broader blueprint for complex systems as what idioms can be for a specific coding problem.
Having a good understanding of architecture and how the various pieces can fit into it can allow an organisation to best structure their teams for success. Comparing similar offerings with perceived overlap on an architectural basis allows for rational judgement of where best to combine efforts. Such comparisons can be easily made through applying the age-old Model View Controller (MVC) pattern across systems to further disect the roles of many product teams or systems. Such architectural understanding, which can be focused or abstracted to the right level coupled with business knowledge provides that critical bottom up part, enabling and preparing organisations for the road ahead.
Danny Baggs' Blog 