Delivering and Surviving a Project’s Architecture Peer Review

Architecture reviews at my company are brutal.  Not brutal in a bad way, per se, but in the sense that if you are not completely prepared and organized, you’ll leave with a slight limp and self doubt that you know anything about anything at any time, ever.

So what should an architect do when preparing to share their project and corresponding design with a group of their distinguished peers?  I’ve compiled a short list that stems from my own failings as well as observations from the architecture bloodbaths involving other victims.

During the Project

• Be a critical thinker on your project.  A vital part of the architect’s job in the early phases of a project is to challenge both assumptions and initial strategies.   This can be difficult when the architect is deeply embedded within a project team and begins to lose a bit of perspective about the overall enterprise architecture objectives.  It’s our responsibility to always wear the “architect” hat (and not slide into the “generic team member” hat) and keep a close watch on where the solution to the business problem is heading.
• Understand the reasons behind the vision and requirements of the projects.  If an architect blindly accepts the scope and requirements of a project, there is a great chance that they will miss an opportunity to offer improvements or force the team to dig further into the need for a particular capability request or even the project itself.  We can only confidently know that a new system will actually satisfy business complaints if we’ve fully digested their underlying needs. What’s the business problem?  What is the current solution failing to do?  I’ve come across many cases where a delivered requirement was actually something we eventually discovered was either (a) something to address a negative behavior of the legacy solution that wouldn’t be relevant in a new solution, (b) a technology requirement for what is actually a business process problem, or (c) a requirement that was dictating a solution versus addressing a core business issue.  We can only determine the validity of a requirement by fully understanding the context of the problem and the stakeholders involved. 
• Know the project’s team structure, timeline and work streams.  The architect needs to intimately know who the key members of the team are, what their roles are, and the overall plan for project delivery.  This helps us better align with other enterprise initiatives as well as communicate when important parts of the solution will begin to come online.

Preparing and Delivering the Review

• Know your audience and their expertise.   Our architecture team contains serious horsepower in the areas of software engineering, computer science, infrastructure, data architecture, collaboration, security strategy and process modeling.  This means that you can’t get away with glossing over areas relevant to an attendee or presenting half-baked concepts that bastardize a particular discipline.
• Explain the business vision and what role technology plays in solving the problem.   One of the key objectives of an architecture peer review is sharing the business problem and providing enough context about the core issues being addressed to effectively explain why you’ve proposed a particular solution.  Since most of us know that technology is typically not the only part of the problem, it’s important to call out the role of process improvement and logistics changes in a proposed solution.
• Don’t include any “fluff” slides or slides with content you don’t agree with.  I’ve learned the hard way to not just inject individual slides from decks authored by my business counterparts unless I am fully on board with the content they produced.   A good architecture team is looking for meaty content that makes them think, not vaguely relevant “business value” slides that contain non-measurable metrics or items I can’t share with a straight face.
• Be direct in any bullet points on the slides.  Don’t beat around the bush in your slide bullets.  Instead of saying “potential challenges with sourcing desired skill sets” you should say “we don’t have the right developers in place.”  Or, saying something like “Solution will be more user friendly” means nothing, while “Solution will be built on a modern web platform that won’t crash daily and consolidates redundant features into a small set of application pages” actually begins to convey what you’re shooting for. 
• Carefully select your vocabulary as to not misuse terms.  When you have an experienced set of architects in the room, you have little wiggle room for using overloaded or inappropriate terms.  For instance, I could use the term “data management” in a presentation to my project team without cause for alarm, but our data architects have a clear definition for “data management” that is NOT some sort of catch all for data-related activities.  In an architecture meeting, terms like authentication, high availability, disaster recovery, reporting, reusability or service all have distinct meanings that must be properly used.
• Highlight the key business processes and system-oriented use cases.  As you begin to convey the actual aspects of the solution, focus on the business process that represent what this thing is supposed to do.  Of even more interest to this particular audience, highlight the system use cases and what the expected capabilities are.  This properly frames the capabilities you need and helps the audience think about options for addressing them.
• Show a system dependency diagram.  Since members of an architecture team are typically dispersed among projects all across the organization, they need to see where your solution fits in the enterprise landscape.  Show your solution and at least the first level of systems that you depend on, or that depend on you. 
• Know the specific types and formats of data that make up the solution.  You can’t only say that this solution works with lots of data.  What data?  What entities, formats, sizes, sources are we talking about?  Are these enterprise defined entities, local entities, entities that MAY be reusable outside the project?
• Explain critical interfaces.  What are the key interfaces within the system and between this new system and existing ones?  We need to share the direction, data, and strategy for exposing and consuming both data and functionality.  It’s important to identify which interfaces are new ones vs. reused one.
• Spell out the key data sharing strategies employed.  The means for HOW you actually share data is an absolutely critical part of the architect’s job.  Are you sharing data through batch processing or a message bus? Or are you relying on a shared operational data store (ODS) that stores aggregated entities?  Whether you share data through distributed copies, ODSs, or virtual aggregation services has a large impact on this system as well as other systems in the enterprise.
• List off existing in-house platforms and technologies that are being leveraged.  This helps us outline what the software dependencies are, and which services or systems we were able to get reuse out of.  It also creates discussion around why those platforms were chosen and alternatives that may offer a more effective solution.
• Outline the core design constraints and strategy.   This is arguably the most important part of the review.  We need to point out the “hard questions” and what our answers were.  As for “constraints”, what are the confines in which we must build a solution?  Do we have to use a specific product purchased by the business team?  Are users of the system geographically dispersed and on mobile devices?  Is the delivery timeline hyper-aggressive and requires a simplified approach?  My strategy for a given solution reveals how I’ve answer the “hard questions” and which options I considered and how I reached my conclusions.

  There you go.  The primary reason that I enjoy my job so much is because I work with so many people smarter than me.  Architecture reviews are a healthy part of the architect’s growth and development and only make us better on the next project.  To make my future architecture reviews less frightening, I’m considering a complimentary strategy of “donuts for all” which should put my peers into a loopy, sugar-induced coma and enable me to sail through my presentation.