Solution Architecture 101 : For Budding Architects

Solution Architecture 101

Importance of good Architecture in technology can be looked at the same way as architecture in any civil project. A Building with good architecture would ensure years of durability under any weather, calamities or situations. Vice versa is also true, a bad architecture would make sure the structure come crumbling down at the first sight of trouble. The very first step of becoming a good architect is asking the right questions. E.g. , WHY this new system is needed, WHAT all is expected out of it, what all NOT expected out of it, WHO will use this system etc. Answers to These questions will help you lay down firm base for your architecture.

Bare minimum prerequisite of this course would be of good understanding of any business domain, some latest technological trends in the market for the business and some hands-on experience of working in a software project and know-how of various diagrams used in SDLC. At the end of this Article you would have functioning knowledge of what solution architecture is and what separates a good one from bad one, and how you can start architecting on your own.

A Solution architecture is usually an answer to a problem, so creating an architecture more or less has same steps which one would employ to solve a problem. To understand concepts better we’ll use this amazing architecture Kata I found at

Going Green

A large electronics store wants to get into the electronics recycling business and needs a new system to support it. Customers can send in their small personal electronic equipment (or use local kiosks at the mall) and possibly get money for their used equipment if it is in working condition.

Users: Hundreds, hopefully thousands to millions


Customers can get a quote for used personal electronic equipment (phones, cameras, etc.) either through the web or a kiosk at a mall.

Customers will receive a box in the mail, send in their electronic, and if it is in good working order receive a check.

Once the equipment is received, it is assessed (inspected) to determine if it can be either recycled (destroyed safely) or sold (eBay, etc.).

The company anticipates adding 5–10 new types of electronic that they will accept each month.

Each type of electronic has its own set of rules for quoting and assessment.

Additional Context:

This is a highly competitive business and is a new line of business for us

If we haven’t received a type of electronic equipment in a year we will remove it from our system

We need to maintain a list of electronic equipment we are willing to accept as it changes often

Each piece of equipment has it’s own assessment (inspection) rules

We have the right to change the original quote to the customer if the product isn’t in the condition they said it was

Approach the problem.

The very first step of solving any problem is understanding it. A mis-understood problem would guarantee a mis-placed solution. e.g. — getting a car would be an answer to a commute problem, but if appropriate parking is not available, getting a car would only convert the problem and not fix it.

In the same way, understanding what all problems should be solved by a software solution and what all problems should not be caused by it is crucial to approaching a tech architecture. Keeping this in mind lets approach the current problem at hand.

Electronic store in question needs a new system altogether to help customers recycle the old electronics and may make some money in the process. So lets write down what all we observed from the problem statement,

Approach the solution.

Let’s get to the board and start plotting whatever we know so far. Why a board, because it helps in visualizing and help in building up a complete picture.

Iteration 1:

Let's Draw How customers can approach the system[OmniChannel Commerce].

Customer Interaction through Browser on Laptop/Mobile and Kiosk in Store.

Iteration 2:

Lets List down what all this system should be able to do it e.g. Add to cart, checkout.[Ecommerce as base solution].

Typical Ecommerce Data Flow involving Product Search, Add to cart, Checkout and Order Placement.

Iteration 3:

Let’s Start adding external integrations to the board e.g. Delivery Partners.

Delivery Partners would be responsible for delivering packaging material and pick up the final Package.

Iteration 4:

Add integrations to the client components, in this case propriety logic which is exposed with a microservice.

Integration with Estimation Engine (Managed by Client)

Iteration 5:

Business would be responsible for quality checking which requires management of various rules and workflows. All these operations would be part of the core application and would be performed by employees.

Employee will submit a more detailed questionnaire to the estimate engine to get the exact price info back

Final Iteration: Application Architecture.

This final diagram should show what all your core application is supposed to do.

Core Application would be responsible for listed functionalities.

All of these data flow diagrams and Application architecture combined represents what all your application needs to do.


Sometimes It's relatively easy to come up with a solution, and whole different ball game to actually sell it ;) .

At times when we start solutioning to a problem we realize we don’t have answers to some questions. Some of these questions can only be answered by business , but at times some of these can be ‘Assumed’ on our past experience and recommended industry best practices. But this ‘Assumptions’ must be clearly called out in the solution, as it may look too obvious to you , but may imply something else altogether to other person.

Same way, external dependencies should be called out as risk. e.g. in our case if we manage to develop whole solution within time but if client’s Estimation Engine is not ready in due time, it would all be for nothing.

You should come up with a table like this to substantiate what all you have accounted for during solutioning.

Assumptions , Questions and Risk.

I hope all of this has been helpful to you. I am planning to add more content in this series soon.

Don’t get Stuck, Keep Solutioning :)

To be Contd..— Non-Functional Requirements, Right Platform Selection, Cloud vs On-Prem infra, Monolithic vs Microservices, Effort Estimations, Staffing, Delivery Plan.



Principal Architect | SAP Hybris Commerce Architect | SAP Certified | E-Commerce Expert | Technical Manager | Accenture

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Vipul Gupta

Principal Architect | SAP Hybris Commerce Architect | SAP Certified | E-Commerce Expert | Technical Manager | Accenture