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:

  1. Architect is engaged to design project’s solution architecture (using the Investigative Architecture™ method)
  2. He/she is provided business requirements to review and comment on, to ensure they are fit for high-level design
  3. The requirements (hopefully) clearly state the end-user and product/service-centric objectives
  4. But how the end-users and the new/enhanced product or service will be supported operationally is completely missing

Unless the architect is also capable and experienced in business analysis, he/she will proceed to draft and refine the architecture based on just the product/end-user requirements, together with key non-functional requirements like security, resilience, simplicity, adherence to organizational standards, etc.

But eventually someone will point out that little thought was given to how the new/enhanced product’s full lifecycle will be supported in operations – e.g.

  • What reporting is needed?
  • If there’s financial transactions involved, how will accounting be done?
  • What compliance and regulatory impacts are there, and are we sure they were elicited and documented as non-functional line items in any BRD?

This often requires ancillary business departments to be quickly engaged to assess both the requirements and the emerging architecture design, usually in fire-drill fashion and with recriminations (“What about us??“) aimed at the architect, who is now the focal point of the project since it’s fully in the design phase. The primary/sponsor business department (the “product” people) will claim that their objectives are all that matters to the business requirements phase of the project, and any fallout or implication of ancillary business stakeholders are subject for design, i.e. the architect’s problem. It can get ugly and silly.

To see a way out of this frequent dysfunction requires an understanding of business and needs analysis, design process best practices, and political/inter-personal savvy. Our Investigative Architecture™ method recommends a classic artifact to encourage indirect (e.g. reporting, accounting & compliance) stakeholders to be considered: the System Context diagram:

System Context Diagram

This short little sample diagram clearly depicts a new solution functioning as a kind of catch-all self-service system for health care consumers. Designing the correct type and number of integrations to achieve these objectives will usually be the first task of the architect. But imagine that the organization has a central “Complaint Management” department that was left out of the requirements definition phase, and only the investigative efforts of the architect turned up this missing group and their need to audit all customer complaints in the enterprise. Not only is it clear now that additional functionality is required, but its clear that Complaint Management is an indirect stakeholder group in this new solution. Further, they have functional requirements that were missed.

Since this diagram is more a business analysis than architecture artifact, it goes great as a summary of business requirements. We use it to bridge the gap between requirements and design (both from a process and artifact perspective).

The System Context diagram simply needs an update and use of a specific notation to show the Complaint Managers and their indirect reliance on (not direct use of) of the Health Care Solutionator. We accomplish this with a dotted line, which signifies an “indirect relationship,” like an external auditor may never use the system, but may require capabilities of the system.  Or, in our case, the Complaint Manager:

System Context Diagram with Indirect Stakeholder!

Problem solved.  Plus, being on the diagram makes a stakeholder feel more included!  If you’d like to get trained on the diagram, and its use and application in IT architecture – please drop us a line!

The following two tabs change content below.

Ben Sommer

was a Principal Consultant with Systems Flow, Inc.

Latest posts by Ben Sommer (see all)


Comments are closed.