Know when to open the box
I’ve added a new principle to the way I work as a solutions architect that I thought I would share. It has helped me navigate recent experiences working as an AWS solutions architect and approaching a companies cloud architecture for the first time . A “box” in this context.
Everybody I seem to encounter believes they have created something really unique in the cloud. They can’t wait to share the amazing combination of tools and services they’ve glued together to create their solution.
So on day one, before you’ve had a chance to have your first coffee break, they open the box.
They open up Visual Studio Code (if you’re lucky!), unload on you a plethora of technologies and before you know it you’re in the box with them. You’re discussing low level problems and the longer you do so the longer it’s going to take to work your way out of it mentally.
Before that happens force the engineers to step back. Honestly, ask them what the box is for in very simple terms.
Every system is a matter of inputs and outputs. You put something in, you get something out. What is this systems purpose? What are the inputs and the expected outputs?
Don’t be afraid to ask if there is a box that already does a lot of what they need. Because usually there is. The uniqueness signals a lack of understanding.
This is especially true of seasoned engineers as they approach the cloud. They concoct some reason for why lambda functions are evil (usually observability related) and run off to put a combination of Java apps in docker containers on EC2. Because you know, high availability is an Amazon sales pitch.
They have also learned that they can generally end conversations by tying people in knots. I have seen it time and again. They do it by dragging people into the weeds of their problem and focusing on those details rather than the grander picture.
This is the challenge most cloud architects will face as they try to bring out an organisational cloud revolution. So before you get dragged into the details, step back and think about the purpose of the system conceptually. Use low tech tools like event storming and example mapping to refocus on the purpose of the system.
And from there you’ll likely be amazed by how few people know what their box does. In my experience, most of them need to be flattened and recycled.
Me
An AWS Certified Solutions Architect Professional with a passion for accelerating organisations through Cloud and DevOps best practices.
If you want to work together contact me over on brianfoody.com, on LinkedIn or Twitter for a chat.
And don’t forget to follow the Lambda Lego publication!
