Being a solutions architect is a difficult yet rewarding job.

It’s fun in that you get to be creative all day, but it can be exhausting when it comes to putting together all the resources needed to share your ideas with your team.

How do you know what to include? Who do you need to talk to?

As we already know, being a solutions architect is just as much talking to people as it is being technical. This means that you need to include enough resources to create a shared understanding with the developers who will build your solution and the product owners who will be responsible for it.

Today we’re going to talk about the pieces of an inspiring architecture proposal that will build a shared understanding and give you credibility so your stakeholders have confidence in your solution.

1. Diagrams, Lots of Diagrams

The best tool a solutions architect has in their belt is the diagram. They illustrate difficult concepts by abstracting them to circles, ovals, and arrows. Anyone can look at a diagram.

When written properly, technical and non-technical people alike can pick up on the idea you are trying to convey just by looking at it. By creating diagrams you are opening the door of understanding to all your stakeholders.

A picture is worth a thousand words. But when you’re talking about a conceptual system design, they’re worth about 100,000.

There are several types of architecture diagrams you can use when building a proposal. In fact, I’d recommend using multiple. You can use different types of diagrams to show different levels of fidelity in your solution.

Start with high level business process diagrams, then drill into specifics with more technical diagrams.

NOTE - When making a proposal for a major architecture change, implementation details are not required. Your level of detail can stop at a service diagram (for example, which AWS services connect to each other as part of the solution).

2. Acknowledge the Iterations

Software is meant to be iterative. My approach to software comes in three phases: “Do it, do it right, do it better.”

A perfect software solution doesn’t exist. Acknowledging that from the beginning is important in establishing your credibility. From the beginning you should be offering what needs to be done to do it. What is the minimum it would take to solve the business process?

Break down silos of work into a maturity model for your project. For example, I recently gave a proposal on restructuring the authorization mechanism across our entire cloud-native product suite. Part of the new solution is creating internal APIs and having our different products register for API keys for them.

To avoid any “gold plating”, I built this maturity model to show that I know what I’m proposing we start with is not a long term goal.

Maturity model for application registration with internal APIs

Deciding how to iterate a solution is a business decision.

When it comes to choosing what to do, it’s the decision of the business, not the solutions architect. So providing the paths the business can take makes your proposal easier to accept.

3. Work Backward Through Prerequisites

In almost every major project, there will be some sort of prerequisite work. In fact, you’ll often see your prerequisites with prerequisites. As a solutions architect, you need to specifically address every one of them.

When giving your proposal, start with the end goal. What does the final solution look like?

After you get a consensus on the finished product, start discussing the steps it will take to get there. Then talk about the steps it would take to get to those steps, and so on.

The reason we start at the end and work backward is for early agreement and to maintain focus. Get your primary objective completed, then start talking about details on the prerequisites.

If you began with your bottom level prerequisites, your audience might not have the context necessary to follow your train of thought. You might also get caught up in conversation early on and run out of time before you talk about the primary solution.

4. State The Problems With Your Solution

Everyone would like to believe that you have designed a flawless system that will never have issues. But as solutions architects, we know that unfortunately isn’t true. It is important to bring up possible shortcomings in your proposal to make the stakeholders aware of the risk. You might also get ideas from your team on how to better solve the problem.

Possible issues with your solution could include:

• Bottlenecks at scale
• Traceability issues through the system
• Dev team upskilling
• Difficulty of enhancements if access patterns change

This is not a complete list of issues, but it should give you an idea of things you need to point out when discussing your solution.

Be up front with risk. Nobody likes surprises.

If you are unsure about a particular implementation detail, be sure to bring it up. If your technical solution requires skills that your team doesn’t have, mention that some learning needs to take place before the development work.

If you bring up risk from the beginning, your audience will have confidence in the thought that went into your solution. Try your best to have recommended solutions to the problems you bring up instead of leaving them open ended. An open ended problem will make your audience believe that your solution is incomplete.

5. Get Industry Backing

It’s always a good idea to bounce your ideas off someone else. I have found great success in asking people outside of my organization how they do things. If you want fresh opinions on what other companies do, head over to the internet.

If you’re designing a system in the cloud, talk to a rep from your cloud vendor. With every project I do, the first people I run my proposal by is AWS. The solutions architects at AWS know everything about scale, pain points, and gotchas with the services used in my plans.

They help identify potential bottlenecks and offer higher performance and lower cost alternatives.

If you’re unfamiliar with a new concept, ask the community. Twitter has a wonderful tech community full of professionals who have a genuine desire to help. Ask a question out loud or to a specific individual and you will almost always get a diverse range of answers.

The benefit of going outside your org is to further enhance your credibility. By working in comments like “when I spoke to XYZ company how they do this, they said X” to your presentation, you share the work you’ve put into your plan. You continue to build trust that you’ve done a thorough job researching the best solution possible.

Balancing both internal and external approaches will provide you with a strong understanding of how to solve the problem in both an industry standard way, and a way that isn’t too foreign to your teammates.

6. Include a Data Model

There likely will be people ranging from developers to product owners in your proposal meeting. An easy way to get them to conceptualize data flows is to present a data model.

Creating a data model is important for a number of reasons:

1. It shows the intent of your solution
2. It helps people visualize what your solution looks like by knowing what fields you intend to capture
3. For NoSQL applications, it demonstrates how you satisfy the access patterns
4. It spurs conversation about how data should be collected and transported

Product owners will appreciate a data model because they can see what fields you are planning to record. They can bring up use cases or potential access patterns that you might have missed.

The data model provides detail at the lowest level for your proposal. It is your best chance at getting a complete shared understanding of your solution.

Conclusion

The objective of a proposal is to build a shared understanding of the details in a major architecture project. Building a shared understanding will help improve the confidence of the stakeholders and developers that your solution is the right way to go.

Drawing diagrams and building data models help drive that shared understanding with your entire audience. They will understand your objectives and point out anything you might have missed.

Pointing out problems and getting outside opinions help improve your credibility. You want people to trust that you have spent the time to fully process the solution and identified as many problems that could possibly occur.

Armed with this information, you will be able to take your proposals and elevate them to the next level.

Good luck and happy coding!