Architecting fast is the key, until its not...

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!