Solution Architecture 101 : For Budding Architects
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 fundamentalsofsoftwarearchitecture.com.
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
Requirements:
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,
- Minimum 2 ways of business, ‘Pure Online’ and ‘Drop in Store’. [OmniChannel Commerce]
- An experience almost equivalent to cart-checkout may be required. [E-Commerce as base solution]
- Make and Model of electronics accepted would increase with time. [Increasing Inventory, Product Management].
- Starting with few hundred customers Millions of customers are expected [System should be Scalable to demand].
- Selling on other platforms like ebay[Out of scope of our Solution].
- Packaging delivery and Package Pickup [External Transport Partner like UPS Integration].
- Quote Generation would require answers to some basic questions , e.g. Make, Model and Year [Content Management]
- Some Mechanism to Generate Quote amount [Proprietary Business Logic]
- Each Device would go through some checks and balances[WorkFlow Management].
- Electronics which are not received till an year needs to be removed from catalog[Periodic maintenance]
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].
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].
Iteration 3:
Let’s Start adding external integrations to the board e.g. Delivery Partners.
Iteration 4:
Add integrations to the client components, in this case propriety logic which is exposed with a microservice.
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.
Final Iteration: Application Architecture.
This final diagram should show what all your core application is supposed to do.
All of these data flow diagrams and Application architecture combined represents what all your application needs to do.
Assumptions/Questions/Risk
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.
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.
