Avoiding Common Traps in Solution Architecture
Experienced solution architects may fall into traps like failing to gauge team maturity, prioritizing solutions over problems, lacking consensus-building skills, and neglecting decision capture. To mitigate these risks, architects should evaluate themselves honestly, seek feedback, and strive for continuous improvement.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Four traps experienced solution architects fall into, and how to mitigate them Adrian Kearns, Geekle, Jan-2021
Quick Intro Me: Played with Lego since 1979 Developer since 2000 Solution Architect since 2008 Consulting architect since 2013 Based in New Zealand International experience in Singapore and Australia Still codes for fun https://www.linkedin.com/in/adriankearns https://morphological.wordpress.com
Why? What s In This For You Four traps I have seen architects fall into: Causes and consequences Potential mitigations Experienced architects are not immune to falling into traps of their own making. Plus, some real-world stories (anecdotal). By looking at some specific ones we can be more aware of what we do, and why, so that we can self-improve. How to use this deck: 1. Evaluate yourself honestly against each of the causes. Seek feedback. 2. Consider the mitigations; action the ones you think will work for you. 3. Repeat seek continuous incremental improvement.
Agenda The Ivory Tower a quick word. 1. Failing to gauge team maturity, 2. Putting the solution before the problem, 3. Not building consensus, 4. Failing to capture decisions. Causes Consequences Mitigations Wrap-Up
The Ivory Tower a quick word The ivory tower: a metaphorical place where people are happily cut off from the rest of the world disconnected from the practical concerns of everyday life in favor of their own pursuits, usually mental and esoteric ones. Don t become an ivory tower architect.
1 Failing to Gauge Team Maturity The Trap: Organisation the organisation as a whole, with obvious emphasis on the project s delivery team, The most valuable solutions are ones that actually: 1. get delivered, 2. work, 3. and can be supported. Includes supporting technology teams, platform teams, test departments, governance & oversight, management & leadership. Putting forward architectures that the team / organisation cannot deliver and support, for lack of maturity, stand little chance of success. Maturity not just technical maturity but also the ability to collaborate and self improve.
Failing to Gauge Team Maturity Causes & Consequences 1 1. Just not thinking about it. 2. Incorrectly assume a level of ability in others. 3. Too focused on the technology, what not how . 4. Too preoccupied with favourite technology or preconceived idea. (See the next trap). 5. Up the ivory tower; lack of meaningful engagement with relevant delivery people. 1. Solution may require delivery and/or support skills beyond what the organisation has, or beyond what they can realistically achieve in the time required. 2. Inappropriate architecture expensive, hidden costs; delivered late, or not at all. 3. Negatively affects your personal reputation.
Failing to Gauge Team Maturity Mitigations 1 1. Update your mental model to recognise that technology is implemented and supported by people. 2. Start thinking about what operational support will look like, early on. 3. Remember that technology is only part of the equation. Review past experiences: 1. Think about all the teams you ve worked with or been a part of. 2. How good were those teams? 3. How did that affect delivery? 4. Try and think about what average looks like. 5. Use as a benchmark for where you are now.
Failing to Gauge Team Maturity Mitigations 1 What if team maturity is genuinely too low? Sometimes raising a team or organisations level of maturity is genuinely needed. This is a big ask, and is typically beyond your remit as a solution architect. Carefully consider what steps to take (e.g. just calling it out), and who you discuss it with.
2 Putting the Solution Before the Problem The Trap: Solution mode when anyone: Short-cuts to what technology they can use. Rushes starts defining any aspect of the solution in a vacuum. Successful architectures are ones that take an organisations constraints into account, whilst solving the stated problem. Getting too caught-up in solution mode means you re more likely to not address the actual problem, and take relevant constraints in account.
Putting the Solution Before the Problem Causes & Consequences 2 1. Residing in the ivory tower, focusing on self-interests rather than the problems at hand. 2. Too focused on a new toy / flavour of the month / what s trendy. 3. Letting biases dominate. 4. Unwilling to leave your comfort zone. 5. Doing things fast rather than right: opting for convenience, rehashing what you did last time. 1. Sub-optimal or wrong solution. 2. 3. Not solving the actual problem... making it harder to gain consensus. Blindness to your preferred solutions short-comings which opens the door to additional delivery & support risks. 4. 5. Increased risk of solution not being supportable. Negatively affects your personal reputation. 6.
Putting the Solution Before the Problem Mitigations 2 1. Consciously remind yourself to first understand the problem. 6. Be honest with yourself: ask am I just trying to stay in my comfort zone? and am I honest in my assumptions? . It s easy for the brain to rationalize justifications challenge your own thinking, try to be balanced. 2. Identify the most significant aspects of the problem, and its context, and consider how they inform solution criteria. 7. Don t be afraid to venture into areas that are new for you. 3. Ideation: Challenge yourself to come up with a minimum of 3-5 solution ideas, and consider all of them. 8. Take time to look for other options. Where other proven options exist, take some time to understand why they are successful and think about how that applies to your situation. 4. Evaluate your prior experience with the here and now what are the differences? Are any significant? How does they stack-up against #2? 9. If you still think the familiar tool is the right choice, look for someone with an alternative view to yours and have a robust discussion to challenge your thinking. 5. Brainstorm ideas with someone else. Get them to play devils advocate.
Not Building Consensus 3 The Trap: Consensus willingly support of a shared understanding. The more consensus there is in support of an architecture, the smoother its delivery and support will be, and the longer it will enjoy investment. Investment: 1. Commit of money / budget. 2. Commit of time and effort. Not building consensus for your architecture will at best undermine your vision, at worst encourage others to circumvent or remove it. 3. Commit of people and resources. 4. Championing to others. 5. Altering their own plans to support.
Not Building Consensus Causes & Consequences 3 1. Your vision is more strongly challenged, actively resisted consuming time and effort. Diminished collaboration (and its many advantages). Governance approvals harder to obtain. Your solution is removed, replaced, circumvented or demoted: wasting everyone s time and effort; hurting business goals. Negatively affects your personal reputation. Creation of political enemies. Good staff may leave the organisation. Plus the consequences from trap 2. 1. Ego driven. 2. 3. Being too solution driven (trap 2). Trying to, but failing. 2. 3. 4. Benign causes: Accidental / ignorance An overriding imperative 5. Complications: Consensus might unobtainable 6. 7. 8.
Not Building Consensus Mitigations 3 Self: Engagement: Don t be driven by your ego. 1. Take time to engage with stakeholders. Remember that it s okay for others to have good ideas. 2. Make sure you understand their drivers (e.g. objectives, pressures) and how these relate to your drivers. Solution architecture is not a zero-sum game. 3. Identify areas of common cause, work to leverage them. 4. Identify areas of conflict, work to mitigate or minimise their potential. 5. Be transparent; demonstrate a willingness to listen, and take feedback onboard.
Not Building Consensus Mitigations 3 10. Review assumptions. Key Decision Makers: 11.Use a neutral third-party as a moderator if discussions become too fraught. 6. Where are decisions made and who makes them? Do a stakeholder map. 12.Leverage architectural principles, existing precedents and previous decisions. 7. How much consensus do you really need: Who do you need to get across the line? Consider consensus vs buy-in. 13.Communicate disagreements so that they are out in the open, try and avoid giving dissenters a platform to snipe you from down the road. Other: 8. Focus on the right problem. 9. Elevate or reposition the discussion.
Failing to Capture Decisions 4 The Trap: Decision anything that has consequence for the solutions architecture, delivery or support. Solution architecture, and delivery, can be seen as a stream of decision making. Therefore, well managed decision making is key. Successful decision capture relies on: 1. Clarity on what is being decided. 2. Transparency of process. Not capturing decisions effectively leads to needless re-litigation, disruption and re-work. 3. Visibility of the decisions. 4. Participation of those with a stake in the outcome.
Failing to Capture Decisions Causes & Consequences 4 1. Failure to reach a decision, or 2. decision reached but not recognised at the time. 3. Right people not involved. 4. Lack of discipline (you) / decision not recorded. 5. Absence of effective decision register / processes. 6. Issues around ownership / roles and responsibilities. 1. Vulnerable to re-litigation. 2. Vulnerable to governance and audit challenges. 3. Rework. 4. Delays, impacting sign-offs and stage-gates. 5. Loss of credibility. 6. Irritable stakeholders.
Failing to Capture Decisions Mitigations 4 1. Help guide discussions so that it is recognised when something is going to need a decision. 2. Guide discussion towards getting decisions made, and recorded. 3. Ensure the right people are involved. 4. Keep an Architectural Decision Register. 5. Leverage the project s decision register. 6. Take notes. 7. Circulate your notes: Here s my understanding of what we [ discussed | agreed ] . 8. Reference architectural principles where possible.
Wrap-Up 1. Don t be an ivory tower architect; always ask yourself how you can keep things real. 3. Involve others. 4. Seek consensus where possible, failing that where essential. 5. Be methodical document decisions 6. Be conscious of your biases. 2. Effective solution architecture requires effective inter-personal skills and self-reflection.
