These are some common mistakes for growing architects when working in the various levels of architecture. Without further adieu, here is our top 10 list.
Technical Architect (Technology, Security, Application, Database, Process)
The main risk is, that if your architectures are too new, people need more runway. This includes more templates, examples, code patterns, starter data, and samples of output precedence since it’s not just there on Google. Build in more prototypes, knowledge transition, iterations, root cause analysis, grooming of the unknown and please avoid grooming to hope.
2) Peer Reviews for New
Avoid relying on automated code reviews and lint checkers for new code. There is more to correct with notations, indentations, and comments on the first pattern. There is also catching the right principles of error checking, business rules, screen set, service API, data integration, level of completeness needed, and so much more.
Furthermore, a new screen, data model, ruleset, and requirements translate poorly into systemizing something too early. Most importantly, it is a good chance to see if they take the model diagram and requirements and then translate them into physical code. This is also great for the team to do the first review from a user’s point of view. Hold human test hours to generate an “X” amount of bugs (your developers could even do it to see how the user feels!).
3) Think Automated Testing When Grooming
You should be able to decompose your stories based on requirements when you go to test. What will the test scripts need to do? Craft the requirements like you would digest on the output and go backward. If it’s a proven pattern, this is easy. If it’s a new pattern, it’s harder, yet sets the bar. You can improve your requirements and diagram documentation thinking this way.
Solution Architect (Data, Information, Knowledge, Wisdom Stacks)
4) Use Conceptual Diagrams and Requirements
Document during or right after initial ideation the stack or flows visually. Modeling out the flow, app stack, logical data model, code pattern templates, screen/database workflows, process diagrams and swim lanes, or other artifacts is more valuable than pseudocode or requirements as it provides the connecting tissues. If you cannot capture in real-time, bring a non-technical person to take notes. Make sure they have mad typing skills and are trained in your diagramming tool.
5) Use Sign-Off as a Gate to Protect Yourself
Do NOT proceed on chat thread level documentation, verbal head nods, text messages, or inline code documentation. Have a sign-off from the business architect as your external review. It creates an immovable object that you need to get and can even use to motivate the team. It even creates a way for you to defend the process without being the bad guy and be more focused on ongoing quality.
6) Document Best Practices Like Team FAQs
If you see common mistakes that are in the wiki, runbook, or models, make a best practices page that links to the most common misses as a way to get feedback. You can add automated reviews and testing as well. However, teaching will get it ahead of time. This could be in capturing common pointing on components to create estimation best practices, assumptions, and environment setup. Your role is not only 1-on-1 coaching chats and whiteboarding. It is also shared with the rest of the team to model it as standing guidance. Remember, you’re the overall solution architect, and if you can’t pass on common guidance, you will get sucked into the technical architect level. Then you will be left covering and correcting your leads.
Business Architect (Roadmap, Epics, Runway, Operating Model)
7) Have Clear Role Clarity With Your PM on Staff Guidance
Your team can experience the Office Space TPS report syndrome if you both are doing the same thing or if no one minding specific tasks. Know who helps staff ideate, groom, resource balancing and aligning capability/skill training, create acceptance criteria, accept items, push to the environment, communicate release status, and manage the various teams (dev, ops, QA, etc.). Where you can push tracking and administration of the process to PM, and creativity and early acceptance items to you. Find the rhythm, document it in a RASCI, then check monthly or quarterly to find improvements
8) When Transitioning to Solution Architect, Accept Nothing Less Than a Clear Operating Model, Documented Assumptions, and Epic Constraints
Solution Architects struggle at ‘less sooner’ almost more than their developers. They want to skip to versions 2 and 3 as the thought is they think the requirements won’t change. Or tech won’t mature over time. They may even forget the perishable nature of the reason we’re doing fewer sooner MVPs in the first place. Constrain their MVPs with documented assumptions, and even sit in on first MVP roadmaps with their tech leads to assure nothing is lost in translation or, worse yet, hijacked.
9) Once a Month, Dig Into One Story to Watch for Underlying Translation Issues in Architecture Guidance
As JW Marriott would check blueberries in one muffin to see if the whole batch was off, it is the same here. Pick an unguided story coming in a future sprint or coming out of a current sprint. Watch the grooming detail, test it out, and even look at the code. Is the team sticking to principles? Are they scope creeping? Are they losing discipline in quality? Use this as guidance for coaching sessions for your solution architect.
Strategic Architect (Investment, Vision, Concept of Operations)
10) This Level is Programmatic Transformation and Pre-investment– Not a Single Solution
This role is the top advisor to your client on investment strategy. It asks questions like where to invest next, what the overall portfolio risk and value assessment is, and what areas need business transformation vs. technical modernization. The role also defines investment opportunities and ties everything into an overall vision. You will need an SME help from your business, solution, and technical architects from time to time, yet do not get sucked into that.