In my 8+ years career as a developer, consultant and recently as Cloud Architect, I have worked with companies of all scales. I have had a taste of multi national corporates, mid size product companies and startups alike. All these places have had different set of challenges, but there was always a common theme I could see everywhere. Most of these challenges were rarely related to technical complexity. These mostly had developers struggling to understand what they were supposed to produce. The architects, product managers tried hard to be precise, but despite of all the efforts the result wasn't any different.
Looking at those scenario's in retrospect with a trained brain; a brain that has gotten a little better at finding patterns over time, I found root cause for most of the misery pointed to one direction. Someone, somewhere in the organisation decided to put technology before business. This phenomenon occurs when it is decided that the business vision can be achieved by throwing software at it. If you hear "Hey this can be solved with K8s" (insert any other tech) early into the process of defining project, it has already been set on a slow path to graveyard.
As a relatively young architect, the more I reflect on these scenarios, the more I am convinced a dire need in shift of our focus from "it can be solved by tech x" to spending time to understand the intricacies of the core business. Inspired by Domain Driven Design approach, the problem should be tackled in 3 steps. Each step provides a separate set of outcome that helps to realise good software.
Step 1 : Ask questions starting with WHY to domain experts
These would generally look like -
- Why are you looking to build this?
- Why now? Why not earlier or later?
- Why use technology to solve it?
- Why cannot it be addressed via processes or new methods?
- Why does the business or its end users need this?
These questions will vary a lot from domain to domain, project to project. At the end of the exercise however, you should get a set of reasons that will help you define the Non Functional Requirements for the software system.
Step 2 : Ask questions starting with WHAT to domain experts or end users
These would generally look like -
- What do you expect the software to look like?
- What are the functions you expect your software to perform?
- What kind of operations do you plan to support via this software?
- and many more
These questions should set you in the right direction of setting up your high level requirements. This exercise should be strengthened by performing the exercise of Event Storming.
More about event storming
Following the why questions and event storming, you would have
- wonderfully descriptive business process that need to be modelled into the software
- great idea on how to draw boundaries in software
- how the stakeholders envision the end state of the software
This would turn into actionable user stories, which in turn lead to well defined tasks. Everyone is happy!
Step 3 : Ask questions stating with How to technology stakeholders
This is where you should set your inner techie free. Since you now have the elaborate requirements, you can focus on using the right technology for the right job. Now is the time to deliberate technology choices with yourself or tech peers. You have NFR's as well and tech needs. You have been set with right details to make accurate choices for the software.
This isn't a gospel and things might work for you differently. The core message is, we need to slow down a little and make technology work for business, not the other way around.
Happy Architecting!
Top comments (4)
Score 5: Insightful 😁
Nicely put, I would also include when questions in the list, to help prioritise more urgent / important things (especially with your users, not so much the domain experts who will express their biasses - but even then a range of biasses can provide guidance!), and finally, include thoughts on how often these decisions (for that is what requirements are) need to be revisited in the agile flow your organisation is using...
Thank you Phil! Lovely ideas. The reason I haven't included these is because they start falling into the gray zone between project management and solution design. At the end of this exercise, there should be enough details for any seasoned Technical project/product manager to make the scheduling priorities (when) and fill in any loop holes. Thanks Again!
you mean Even Brain Storming. Even Storm is an issue in technology.
There is non-technical architecture and technical. Love how you split these out!
Thank you! Event Storming is an integral part of Domain Driven Design methodology of software design. The linked resource and this should help clarify.