Solution Architecture Principles

I came across this article on LinkedIn that was “Powered by AI and the LinkedIn community”. So an AI generated article with some LinkedIn users commenting on their experience with each of the aspects. To be honest I didn’t think I would hold much water before reading it given the amount of bombarding notifications I receive from LinkedIn to contribute to their growing AI-generated knowledge-base of content but this is my honest assessment and response to each of the points in the article.

Align with business goals

…align your solution with the business goals and vision of your stakeholders…

I can’t really argue with this. At Amazon we called this Working Backwards and it’s the approach where you work backwards from the customer outcome or problem that you are trying to solve i.e. look into the future, where to do you want to be, that’s the starting point. Then work back from that point to the present i.e. what needs to be in place to get to that future point or business goal. There is a lot of literature out there about writing better requirements but essentially boils down to documenting requirements and get feedback on them (i.e. test) as soon as possible.

Balance trade-offs

…balance the trade-offs between different aspects of your solution, such as cost, quality, performance, scalability, security, usability, and maintainability…

There are a few schools of thought around this. There’s the age old Iron Triangle i.e. the trade-off between Quality, Time and Cost. This point in the article also seems to merge this with Nonfunctional Requirements. I would say that yes, there are trade-off’s between cost, quality and the time to implement (and test) a solution but I would not say that those extend to the nonfunctional requirements of performance, scalability, security, usability, and maintainability - whether a system scales (e.g. Auto Scaling across Availability Zones or across Regions) should not impact or be a direct trade-off to whether it is usable or impact on maintainability which should be Infrastructure as Code (IaC) to begin with. Finally I would say, for your nonfunctional requirements that you should use something like the AWS Well-Architected Framework to guide you in not only identifying those nonfunctional requirements you may miss but also in recommending implementation strategies to address any gaps.

Apply patterns and best practices

…apply proven patterns and best practices that can help you design and implement your solution more efficiently and effectively…

This one speaks to re-use and not reinventing the wheel. At Amazon they have the concept of Leadership Principles and one of those is Invent and Simplify meaning, yes, you should be building and creating something new but you should be looking to re-use or build on what others have already done in order to make your job easier. A good example of this is how AWS sees open source projects that have traction in the community and then offers managed services for them (e.g. MSK) so that developers who want to use that project don’t have to worry about scaling the infrastructure to support it.

Validate and verify

…validate and verify your solution throughout the solution lifecycle, from inception to deployment and beyond…

Agree with this point as well. Much better to get early feedback on your ideas than to spend ages on something that either isn’t a problem or is already solved or the way you are looking to solve it won’t work because of some blind spot or unconscious bias you have. At Amazon we did this using the Narrative Process which essentially meant that the sooner you can put your ideas to paper in a document format and share those with others to get their feedback the sooner you can qualify in or out the direction you are taking and course correct as needed.

Adapt and evolve

…adapt and evolve your solution according to the changing needs and expectations of your organization and stakeholders…

This is more around Agile vs Waterfall where it’s best to make smaller, easier to see and test changes and features rather than big bang releases where possible. The earlier you can get the functional requirements signed off by the stakeholder/customer/user the more time you can spend on the nonfunctional requirements of building something that can scale and be operated by your organisation. At Rio Tinto LEAN Six Sigma was prevalent and one of those foundation elements was fostering a culture of Continuous Improvement. The same applies for solution architecture and software engineering that applies to operating a mine site.

Collaborate and communicate

…collaborate and communicate effectively with your team members, stakeholders, and other parties involved in your solution…

I think this is more a lesson in life rather than a principle for Solution Architecture but it’s something a lot of us can improve on. Communication is key and “the whole is greater than the sum of its parts” in the wise words of Aristotle. Communicate early, communicate often, get feedback, listen to the feedback, incorporate when you believe you should, be humble, and work together towards a common goal. This is just good life advice but definitely something that is worth reiterating.

In summary

Not a bad article given it was authored by AI. I am impressed and went looking for some background info on how LinkedIn comes up with these articles i.e. what is the source material they are indexing. I found this article on the LinkedIn Engineering blog which referenced an earlier article mentioning they used Open AI and Azure ML for the LLM.