Facts: The Architect’s “Big Stick”

“Speak softly and carry a big stick: You will go far.”
– African Proverb

Diplomat is a key role that Systems Flow’s architects often fill for our clients. Software projects and change initiatives inevitably bring disputes and disagreements over requirements, scope, priority, standards, architectures and solutions. While most project management disciplines offer approaches to managing issues, we have found a basic mantra that keeps us on track:

“Stick to the facts.”

It sounds simple, but actively discovering and clearly documenting the facts of a project disagreement is never easy. Whilst spelunking into the murky depths of these types of problems, here are some “Dos” and “Don’ts”:

  1. Give them options. It may come as a surprise but good IT Architecture consultants don’t make decisions, they facilitate them. We don’t run our client’s business, or develop or support their software portfolio. What we do effectively is understand technology and its business context, and know our stakeholders’ motivations. Lay out all options to resolve the problem, from the sublime (e.g. a full-blown costly, solution) to the ridiculous (e.g. do nothing).
  2. Be Switzerland. This is a instruction we frequently give our new consultants. The only way to make true peace is to not take sides in a battle. Be impartial, stick to facts, faithfully advise of any risks and benefits for any option you propose and know your escalation path if the debate becomes too heated to resolve on your own. Also, even when tasked with representing one party in a dispute, the perspective should not change. This is not debate club – deal in facts! Systems Flow is frequently looked to in times of trouble – by all parties in a dispute – because we are consistently fair and fact-based in our approach. Follow these rules and you too may become indispensable.
  3. Don’t get emotionally attached. Part of defining options involves some level of solution design, architecture best-practices, etc. Pride in your options analysis artifact is inevitable, but beware of over investing in your own idea. Be focused on resolving the dispute at hand, focus on facts and remember that your value will always be in acting as the Switzerland of your organization. Let your solution go if it doesn’t pass muster with the team.

Here are some example problem cases and approaches to “get at the facts”.

Situation Fact-Based Response
Vendor Pushback?
Software vendor says flatly “no” to a request to swap a component of their architecture for one that the client’s support organization prefers.
For a vendor, “no” is never an acceptable response to a request to do work. Anything should be possible with time & money. Press for an estimate, or else specific technical reasons why the component can’t be swapped at any cost.
Business Line Arm Chair Architecture?
Business Line “pre-ordains” a solution for their problem
Push it back to requirements: what’s the business objective and how does the solution meet it? For cases where the solution in question is itself a large project, this can get very dicey and political. But for smaller cases, take the initiative to elicit requirements and assess the presumed solution against other options.
IT Zeal?
Information Security czar demands that all data flows in an architecture be encrypted
Document the data flows, classify their sensitivity and propose a risk-based approach to secure the data that needs securing.


Stay tuned for a more detailed series from us on Architecture Issue Resolution.



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.