10 years, 8 months ago

Cost, Time, & Architecture – The Zen of Options Analysis

Link: http://www.sysflow.com/blog/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.

A common model in project planning is the project “triangle” comparing cost, time & quality as competing constraints. In layman’s terms, you can pick for your project two of the following three attributes:

  1. Run fast (time)
  2. Run cheap (cost)
  3. Deliver goods (quality/completeness)

The point of the model is to impress upon newbie project managers the near impossibility of a Goldilocks project that delivers its objective perfectly, on time, and on budget. The message? Better get used to contingency planning and expect trade-off analysis from the start.

Architects instinctively know this model, but few understand how it applies to their discipline and the activities they perform in support of projects. Systems Flow specifies a clear approach for grappling with these project constraints as they relate to architecture, documented in our Investigative Architecture methodology.

Software or solution architecture is a product of a project – a deliverable. Thus it belongs in the “Good” / “Quality” sector of the Project Management Triangle. An architecture can:

  • Be Brittle or robust
  • Be Extensible or hard to extend
  • Be Secure or vulnerable
  • Simplify the application portfolio or complicate it
  • Etc.

These are all measures of quality, usually along non-functional lines. Our architecture triangle is not specifically concerned with functional scope. Functionality either happens or it doesn’t – it’s in scope or it’s not.

So what do you do if, in the course of designing the architecture of a solution, a contentious issue arises that requires a decision with cost and time implications? You define your options.

Defining Solution Options

Systems Flow’s approach for defining solution options is common sense, but draws on our consultants’ decades of personal experience resolving complex project issues, as well as industry standard methods such as the Pugh Matrix and other quantitative-based artifacts.

We’ve found that the most successful method to assess subjective quality is with a simple picture and some informal scoring of

  • Architecture Advantages (Pros, Benefits)
  • Architecture Disadvantages (Cons, Risks, Impacts)
  • Cost
  • Time

First we kick it off with a condensed – but complete – summary of how we got here and how we get out:

Then we lay out the options, both strategic…

and tactical…

Including options ranging from the sublime to the ridiculous.  Leading a project team through this exercise brings several benefits:

  • Makes clear the tension between architecture quality and project time & cost. Architectures are usually built to a standard which, if your organization is forward-thinking, stands apart from project implementations and helps guide them. Cost & time are implementation concerns. Standards and their implementation are forever the source of contention. This is an artifact that clearly separates them for inspection and decision.
  • Takes heat out of the debate by focusing on facts, simply depicting options and giving just enough narrative to guide a civil discussion. All experienced project professionals can appreciate how structure will have that effect.
  • Encourages a focus on the one artifact, rather than allowing multiple competing version of the debate float about and cause disagreement on the terms and facts of that debate, rather than on the actual merits of one option or another. Thus, the Design Options Analysis report becomes a standard artifact that the IT architect can govern, and whose use the project organization can mandate for resolving large issues. This last benefit actually helps to enhance the role of architecture in projects.

To learn more about how options analysis can improve your architecture or project practice, contact us!