"So what?"

The first time somebody asked me that question in a sprint review I had no idea what to say.

I was a junior developer at the time and the question destroyed me.

I stammered. I fidgeted. I looked over to my boss for help. I was truly at a loss for words.

I had just finished demoing my first project start to finish. I was proud to say that I did this.

But when a stakeholder asked me "so what?" I didn't know what to say.

I knew how my project worked. That was it. I didn't know about how it played a role in the system.

I knew nothing about context. I didn't realize it was important. Requirements were given to me and I satisfied them with my code.

I had no idea that actually writing the code was only a tiny piece of software development.

If you want to go from an individual contributor to a solutions architect, you must learn context. You have to see the big picture. It's not about writing code, it's about how systems interact with each other.

Beginning your journey into the world of architecture can be tricky. Where do you start? How on earth can you develop the skills you need to make that move?

It might not be as hard as you think.

Take a Step Back

As a software developer, you're tasked with writing code to solve a specific problem. Depending on how your stories are written, you may or may not have business context around the change you're making.

To begin changing your mindset from developer to architect, take a step back. Ask yourself, "what impact is my change making on the app?"

Figure out the pieces that make your app work. Is it composed of multiple modules that all play together? Is it a client/server app? Is it N-tier?

Your goal is to understand how all the pieces communicate with each other. Once you figure out how your app works, try to take another step back.

How does your app play in the ecosystem? If your company offers multiple products, is your app part of a suite? Does it interact with other apps? How is yours consumed and what are the expectations of its behavior?

Imagine the code you're writing is a piston in a car engine. It performs a specific function to help the engine run. By itself, it is useless. But connected to all the other pieces in the engine it has tremendous value.

Image by Paul Brennan from Pixabay

Your app is the engine. It has moving parts and they all depend on each other to work together in order to function properly. But an engine by itself doesn't do much good.

The ecosystem and suite of products your company offers is the car. Your app is the engine to the car. It's just a piece, but it's necessary to have a working vehicle.

Continuing to step back until you see the whole image is crucial in your journey to become a solutions architect. Keep expanding your field of view until you see the big picture.

Learn To Ask Why

I'm going to go ahead and make an assumption that if you're a software developer, you love knowing how and why things work.

Which is perfect because that's a necessary trait of a great solutions architect.

Have you ever seen those tv shows where a little kids bugs the crap out of their parents by asking "why? Why? Why?" over and over again? If so, you have a perfect example of what you need to do.

It's one thing to understand how it all works. But it's another thing entirely to understand why it was done.

Why is a piston important to how an engine works? Why was it designed to be in that shape and in that location in the engine?

Asking why is key to go from understanding to comprehension.

If you look at a system that was designed by a solutions architect who only had a simple understanding of how things work, it will be obvious.

A good architect makes a complex solution out of a complex problem. A great architect makes a simple solution out of a complex problem.

Understanding how pieces fit together will give you enough to satisfy the problem. You will take the pieces you see and stitch them together. You will make a complex solution out of a complex problem.

But if you truly understand the ins and outs the components and pieces at your disposal, you comprehend them, your ability to design a better system increases exponentially.

Comprehension opens the door to creative yet simple solutions.

Relate Problems to Known Solutions

Becoming a solutions architect is no longer about coding 100% of the time. You don't get the luxury of designing a solution, implementing it, and moving on to the next one.

Once you finish your design you have to explain it to everyone. Developers, stakeholders, product folks, support, you name it, they need to understand it.

Photo by Austin Distel on Unsplash

With this being said, soft skills become incredibly important. Being able to talk confidently and effectively become your most powerful tool.

Personally, I've found the most success in communicating designs through the use of metaphors. Relating your ideas to a simple concept that others understand makes it easy to grasp what you're saying.

If you can effectively communicate a highly technical solution to a non-technical audience, you were made for this job.

Relating problems to known solutions isn't all about communication. It's also about stealing.

By stealing, I actually mean using ideas from things you see every day. There's no need to re-invent the wheel. There are thousands of design patterns and examples out there that you can apply directly to your project.

If you're building an application that manages uploading and maintenance of files, why not take a look at Google Drive and see if you can mirror some of the functionality they built.

Or if you're designing a system that builds work schedules for employees, why not take a look at Outlook or Lotus Notes for inspiration? These are wildly successful applications that would only benefit you if you borrowed design patterns from.

The great thing about being a solutions architect is that not every idea has to be original. You can stitch together pieces from multiple solutions into a cohesive design for your application. That's what it means to be great at the job.

Draw inspiration from everywhere.

Look Ahead

A great solutions architect lives in the future. They design a system for now that sets the company up for success in the future.

Photo by Slim Emcee on Unsplash

Keep an eye out for "one way door" decisions. Decisions that if you make now, you're stuck with in the future. If you can, put off decisions until the last responsible moment.

When you're designing a system, determine how you are positioning yourself. Are you enabling work in the future to be easily modularized? Are you going to get trapped in a scenario you can't get out of?

Back to the car reference, are you setting yourself up to build a Pinto or a Ferrari?

Remember that when you're trying to move from developer to architect, knowing the plan is crucial. What do you need to be intentional about? What are the company goals in the next year, 5 years, or 10 years?

Don't let today's defects alter your plan significantly. Do let it influence the design. Learn from your experience. But beyond all else, make sure you open up opportunity for the company in the future.

Practice

The best part about software developers is that they love their craft. I've never met a developer who doesn't have at least one side project at all times.

We love to work. We love to learn.

With that in mind, if you want to practice architecting solutions, do it in your spare time. Take a system that's already in place, like your favorite website, and start diagramming what you think the architecture is. Work backward.

Better yet, if you don't already have it documented, diagram the apps you work on in your day job. They will immediately get consumed by your company and it will help with your comprehension.

You have other options to teach you how to become a solutions architect as well. You can take an AWS certification exam to become a solutions architect. Becoming certified makes you more valuable as a developer, but it also strengthens your understanding of how to do the job.

Take every opportunity you can to learn. Get a mentor. People want to help you be the best you can be.

Most importantly, have fun with it. Designing systems is an incredible creative outlet that brings joy to my daily life. I'm sure it will for you too.

Good luck!