Identify Indirect Stakeholders with System Context Diagrams
A Systems Flow consultant has skills that tend to fall in the triangle of technical, business and organizational excellence. One common and repetitive case of project dysfunction where this overlap brings real benefits is that of the “Operational Business Stakeholders Missing from Business Requirements.” Here’s how it usually goes:
- Architect is engaged to design project’s solution architecture (using the Investigative Architecture™ method)
- He/she is provided business requirements to review and comment on, to ensure they are fit for high-level design
- The requirements (hopefully) clearly state the end-user and product/service-centric objectives
- But how the end-users and the new/enhanced product or service will be supported operationally is completely missing
Read more
Documenting Design Decisions
Prose: Great for Novels, Lousy for Solution Design
While we often find ourselves advocating for design documentation, we typically are referring to “some” design documentation vs. “more” design documentation. When it comes to design documentation, more is actually not better. We have encountered customers, and even other consulting firms, that deliver design documentation by the inch – measuring design quality horizontally across the binding. We recommend not doing this!
Read more
Cost, Time, & Architecture – The Zen of Options Analysis
Solution architecture is typically designed within a project context. Although we focus on the right process for this design activity frequently in our blog, the intersection of that process with the process of delivering an actual production solution is very important. Constraints are a key reality in projects, and often they compete with achieving the “right” architecture. A process to guide a design through this gauntlet of project constraints is why we created our “Define Solution Options” process.