"I have a problem... Where do I start?!"¶
Working through Situations as a Solution Architect¶
So, the day has come where you are “crowned” as a Solution Architect. Wait, what does this mean? Wait? What am I supposed to do as a Solution Architect? Is this the same as a Software Architect?
Well, first off, congratulations. You may not know this but a perspective I’ve seen in my career is that you are now expected to know and be able to do everything. This includes having a background in coding, software and solution design, cloud providers, and the services they provide, architectural patterns, etc… It can be overwhelming!
The Situation¶
What’s worse, your often now faced with something this isn’t covered in many cloud certifications, or university courses. The reality now is it sometimesisn’t what you know, but how get to the end game of architecting a “solution”.
A typical situation faced by a Solution Architect is one where you have existing (brownfield) and new ( greenfield ) elements ( aka components ) that need to be brought together relative to the goals of a solution. Oh, and I forgot to mention. These “element” are the responsibility of different teams in your organization, or external.
Welcome to the United Nations. Not only do you find yourself needing to have a good understanding of the business, the requirements of the solution, and the existing and new technologies that you have available, you also have to work through/with many different groups of people. So how have I handled it in my career?
Well, the good news is that as far as learning and getting up to speed you have increasing number of tools at your disposal. Just think of the power of GenAI solutions ( e.g. ChatGPT, Google Gemini) to serve as your ‘assistant’ to help in understanding the concepts and details of various technologies. [ I’ll cover more on this in a separate blog post ]
The Issue¶
BUT… these fancy tools are less helpful in dealing with the realities of trying to design and implement a Solution in, or for, a business organization that has complicated business requirements, compliance needs, contractual constraints, political issues, legacy issues, etc… This is where good old fashioned Critical Thinking comes into play.
According to the “all knowing” Google Gemini, Critical Thinking is: Critical thinking is about thinking clearly and rationally, understanding the logical connection between ideas, and evaluating information to form your own informed judgments. It's about being an active learner rather than a passive recipient of information.
This typically means understanding 1) the problem that needs to be solved, 2) why you need to address the problem, 3) what assumptions you have, 4) the issues related to the problem, 5) your options and the pro’s and con’s related to each option, and then 6) your decision and why you chose it.
Makes sense right? By the way… you need to write this down. I cover my thoughts on that later in this post.
A Path to Sanity¶
You’re probably thinking, “ well this looks like an Architecture Decision is required? .. Right?” . Well, yes and no. The trick, based on my experience that often the situation you may find yourself in isn’t just about one architecture decision. It’s often a set of decisions. In addition, the decisions you need to make are not just technical in nature. There may be political, compliance, budgetary context that needs to be understood and considered.
Ok Gary, then what do I do?
Well… Historically, I just cranked out “architecture decisions”. However, after reading a book on Critical Thinking, which you will find a link to in the supporting information section, I began to change my focus.
Document the Situation¶
I realized that given the complexity of the “situations” I was dealing with, what I really needed to do was to focus in on doing some “Situational Analysis”. Essentially, I organized my thinking along these lines:
- What’s the Current Situation which encompassed a review of the current situation to understand where we as a project, organization, company, are.
- A review off the Complications/Issues related to the situation
- An itemized list of Questions that I had relative to the situation & issues that need to be researched more.
- Hypothesis: A list and analysis of the proposed paths to address the situation & related issues
- Supporting Information that I had to support the above items
The way I approached this was, and still is, to create an individual document for each Situation. Then I used a pre defined template that had the 5 sections ready to go.
I find that the review of the current situation was best done as a journal approach where I organized my thoughts as to what I understand and saw. Often, I added in assumptions, lists, etc… Generally, everyone I could capture relative to how I saw the situation.
I also find that filling out the following sections occurred in an interactive manner generally occurred. As I organized my thoughts re the situation on “paper”, it’s typically a natural flow to start to see issues, or questions that need work.
One key here is to not get too “over your skis” and start to jump to answers how to address the situation until you feel comfortable that you have identified the issues you need to address to fix the situation. Remember, this is where the Hypothesis come into play. Make sure you know the problem you’re trying to address and think through some pro’s, con’s, and implications of the ideas you have.
Concluding Thoughts¶
I can envision what you are thinking: this seems like a lot of work. Why do I need to write this down? Why can’t I just get on a web call and explain what I think we should do. Well, I know there are types of situations that align with this scenario. However, In my long experience as a Solution Architect, I often find that those that take that leap are making many assumptions and are in a rush to get it done. “it doesn’t need to be perfect”.
Well… perhaps. But here is how I see it. Being successful is based something known as the “4 C’s”. 1. Being able to Clearly Communicate your thoughts and ideas with others. 2. Working with others to Coordinate work and solving problems ( be organized ) 3. Cooperating with others while you are doing it. (i.e. no fighting ) 4. Demonstrate to others that you have Credibility.
I have found that documenting your analysis using the approach I’ve laid out above is a key enabler of being able to Clearly Communicating and to build Credibility. Each of these are key, in my view to enabling cooperation and coordination of work. If you can’t clearly demonstrate that you know what you are talking about, you, as a Solution Architect, will find you spend more time trying to get your point across. In the end, I’ve seen teams consume so much time on calls trying to TELL others their view, when sitting down and developing a clear and agreed to understanding of the current situation go along way in reducing this sort of churn. It also greatly your credibility with others.
Supporting Information¶
- Item 1: A good video by Grady Booch where he covers the differences as to what a Software Architect is vs a Solution Architect. https://www.youtube.com/watch?v=u7WaC429YcU&list=WL&index=14
- Item 2: An excellent book on Critical Thinking and Situation Analysis. https://www.amazon.com/Critical-Thinking-Logic-Problem-Solving/dp/B0CMV13NN8/ref=sr_1_1?crid=303KFD23WSWRL&dib=eyJ2IjoiMSJ9.ZxK2e9GF8pvYqeq4UnX9DiPcYOpfR9QV1Rzd7-hP1tt4AJ9qU1PR87QQRaUvv6XxwuEFIjYCx277sDhDWk9fKluDW1gL4Lr73Ycgv8ZxCOueRe0ajs-gv5eh8clcVa4vWKJTsrKdgM4cQxwDnBzSjUqeDvJ7nL1Qepg7QDGvW0goGkqfp1yDkl2YRPdFEnGOjxz8qjW2h8pubFFxr_7Md5Ny3E1qmsNhyaxIUumF36I.PZJOVKBT2QIvi6j_MEyyNzLybIYHo5IwkZchggVC7Qc&dib_tag=se&keywords=critical+thinking+and+problem+solving&qid=1737386320&sprefix=critical+thinking+and+prob%2Caps%2C132&sr=8-1