One of the best parts about being a Solutions Architect is coming up with the architectural design for new projects. You get to explore new technology, come up with new patterns, and build something from scratch. All things that software engineers love.

When asked to design project after project, people tend to lose sight of the grand scheme of what they’re trying to accomplish. Each project narrows their vision a little bit until they have complete focus on an individual project.

This leads to features that feel out of place in your application. They end up being “feature complete”, but they aren’t cohesive in your app because you had tunnel vision. You might have accidentally lost sight of the big picture because you were so focused on completing this one specific project.

It happens to everyone. We all need some reinforcement on what we’re actually trying to do. If we leave things alone without stepping back every once in a while, we tend to drift away from the bigger picture.

You can’t see the forest through the trees.

Today we’re going to talk about steps that you can take to help prevent this “drift”, leave some of the detail behind, and focus on your end-game.

Establish Guiding Principles

If you haven’t already, you should come up with guiding principles for your work. These don’t have to be specific to solutions architecture or even to a specific product. But they do need to be written down and formally agreed upon.

AWS has a set of leadership principles that drive how they operate day to day. These act as pillars for everything they do from hiring leaders to solution design.

By establishing your guiding principles, you put up a set of checks and balances that help steer your work in the direction your company wants to go.

With these principles, it is your responsibility as a Solutions Architect to make sure your designs fall within the boundaries. Follow the norms set up by your company and the big picture falls right into place.

Every design you come up with must take these into consideration. If you start to stray, you’ll start missing the bigger picture and build something you don’t want.

You might be wondering, “How do I come up with these guiding principles?” Great question!

Talk to the leaders around your organization. See what their goals are for the product you’re working on. What do they want to accomplish?

Find the overlaps. What are multiple leaders saying? Who is particularly passionate about something? These are the launch points for your guiding principles. You need to take the thoughts of these individuals and turn them into actionable pillars that drive development.

Stop Rushing

You’re going to be asked for a quick turnaround on your plans. That’s just a part of business. Everything has a deadline. But it’s your job to be responsible with the time you take. Remember, 2022 is the year of async.

Take the time to step back and see where this new project fits into your guiding principles. If it doesn’t fit, you should consider having a talk with the product owner on implementing a different solution.

Have you ever run to the grocery store to pick up one thing? You walk in, go straight to the aisle where you know the product lives, grab it, and leave. You get home, get ready to open it up, and realize that you picked up a different variety than what you wanted. Its kinda what you wanted, but not really.

You rushed to get through the grocery store because it felt like a quick “grab and go”. But because you rushed, you didn’t pay attention to the small details and see that you grabbed the wrong flavor.

The same applies to designing software as a Solutions Architect. Even a basic project could fall into the quick and easy trap and you can end up with something that doesn’t quite fit the mold.

With software you can have it fast or you can have right. You rarely, if ever, can have both.

We’ve talked about the responsibilities of a Solutions Architect before. You know the steps to being successful. Draw a diagram or two. Ask why. Pair existing pieces together with new projects. But above all else, take your time.

There is something called the 1x, 10x, 100x rule with development. The earlier you catch a problem, the cheaper it is to solve.

If you address an issue in the planning or development phase, it’s 1x the effort. If you catch it in QA or when your automated tests are running, it’s 10x the effort. If you catch something in production, it’s 100x the effort to fix.

As you get further into the SDLC more and more people get involved, which multiplies the amount of effort.

Treat Each Project Like a Piece of a Puzzle

I have some friends who love to do house projects. They are constantly doing something new. When one project finishes, they begin a new one.

The quality of their work is exceptional and looks professionally done when you look at one project in isolation. But when you take a look at their house, it feels a little….disjointed.

Each project was done without taking the house as a whole into consideration. Each project is done very well, but they don’t go together.

When approaching a design as if it were a piece to a large puzzle, your designs will be more cohesive and fit into the bigger picture better.

You must consider your application and overall ecosystem when coming up with new project designs. Don’t do what only needs to be done for that one project. Hone in how it plays with your app and identify other areas that are affected by the proposed changes.

New projects are rarely isolated. They are almost always enhancements to existing functionality or a new feature that will add to the toolset of your application.

Conclusion

Unfortunately there is no magic bullet for keeping sight of the bigger picture. But you can ask yourself these simple questions when coming up with your design.

• Does the project adhere to your guiding principles?
• Did you put in the appropriate amount of time and effort in your design?
• What role does this project play in your ecosystem?

By answering these questions, you will come up with a design that fits in with the bigger picture.

Nobody wants a Frankenstein application. Something that has a bunch of cool parts individually but they don’t make sense together. A delightful application feels cohesive and uniform throughout.

As a Solutions Architect, you are the first line of defense for making your application great. It is your responsibility to make sure the parts play well with each other and flow seamlessly.

With everything, it takes practice to make sure your design fits the bigger picture. But over time it will be easier and easier to remember the three questions to success.

Best of luck and happy coding!