Charlie Alfred’s Weblog

Importance, Difficulty and Centrality

Importance, Difficulty and Centrality

The volume of information is growing at an unprecedented rate.  In his 2008 blog post “The Expansion of Ignorance”[1], Kevin Kelly wrote:

“According to a calculation Hal Varian, an economist at Google, and I made, world-wide information has been increasing at the rate of 66% per year for many decades.”

Search engines, like Google, have enabled us to search the Internet and find needed information in a few seconds.  But, has our ability to ingest and understand this much information been keeping pace?

There’s a joke about this that goes:

Managers learn less and less about more and more until eventually they understand nothing about everything.  Engineers learn more and more about less and less until eventually they understand everything about nothing.  Architects learn more and more about more and more until eventually people stop listening to them.  Buyers learns less and less about less and less until eventually they star in their own DirecTV commercial.

The different ways that managers, engineers and architects deal with a rapidly expanding knowledge base is also relevant to architecture.  However, before exploring this, let’s quickly review the role of architecture challenges in formulating an architecture.

Challenges Shape Architecture Decisions

“An architecture challenge is a situation where one or more limiting factors make it more difficult to satisfy one or more value expectations.”  In other words, an architecture challenge is an obstacle or barrier that the system must overcome to provide value to an important stakeholder.

Every complex system must overcome a large number of challenges.  Furthermore, challenges and their solutions frequently conflict.  Many conflicts are inherent – the result of natural interdependencies between uncontrollable factors, outside the scope of the system.  For example, the distance an aircraft can fly is determined by its fuel capacity, but fuel weight of the affects the fuel burn rate.  These constraints hold for all engine and fuel tank  designs.

However, many other conflicts are internal, resulting from constraints that early decisions impose on downstream challenges.  The selection of a no-SQL database over a relational approach will impose significant constraints on the viable approaches for many other challenges.  In fact, the question “why should one approach be preferred” is a clear illustration of the importance of challenges.  Throughput concerns for ultra-large databases, availability of 3rd party replication or report writing tools, and skill sets of existing developers are different challenges.

To paraphrase the great George Orwell, “all architecture challenges have high priority, but some have higher priority than others.”  When tradeoffs must be made, decisions should be biased toward higher priority challenges.  Specifically, given two challenges: H (higher priority) and L (lower priority):

  • An approach chosen to address H might preclude a solution to L, but not the reverse.
  • An approach chosen to address L may limit the outcome of H, if the incremental value of L exceeds the negative impact H, after considering the respective weights of H and L.

In other words, the relative priority of challenges is a very significant factor in determining which architecture decisions should be made for a system.

Where Are Your Priorities?

The conclusion that it is important to prioritize architecture challenges is nice, but it doesn’t say much about how to do this.  Let’s start with the conceptual hurdles.  Three concerns motivate the priority of architecture challenges:

Importance                How much value does the challenge contribute to the system’s stakeholders?

Difficulty                     How much effort is required and how complex or risky is that effort?

Centrality                    How dependent are other challenges on the solutions to this one?


Value has many important characteristics to consider.   The most valuable value is:

  • Universal             perceived by many or all stakeholders,
  • Tangible               directly traceable to increased revenue or reduced cost,
  • Continuous         present all or most of the time, not highly situational,
  • Differentiable    recipients perceive it to be unlike the alternatives
  • Sustainable         the above factors can be delivered over an extended time

When one or more of these factors is limited, then importance of the challenge should be reduced.


Effort affects time and cost.  It also displaces resources from other activities.  Complexity reduces the number and completeness of well-understood approaches, as well as the relevant experience of  the development team.  It also increases risk of failure, and unanticipated side effects on other challenges


The solution to a central challenge affects many challenges, and is less affected by other challenges.  By contrast, a peripheral challenge has less of an effect on other challenges.  While centrality is seen as an immediate concern, its more significant impact occurs over time.  Central challenges have a greater effect on modifiability (changes to existing behavior) and extensibility (new capabilities) of a system.

Sometimes these concerns align, but frequently they pull in different directions.  Each concern is necessary, but none alone is sufficient.  It is important to balance them, but in practice, it can be extremely difficult to achieve this.  The reason is connected to the rate of expansion of information and differences in how different types of stakeholders cope with this.

You Are What You Focus On

In 1637, French philosopher Rene Descartes wrote, “I think therefore I am[2].  Nearly 200 years later, French politician Anthelme Brillat-Savarin said “You are what you eat.[3]  Since learning is mental consumption, a frivolous extrapolation is “You are what you focus on”  and its corollary, “What you ignore defines what you are not.

Learning is work and takes time.  As complexity grows at a faster rate than mental capacity, having everybody be proficient in everything becomes an unaffordable luxury. Specialization is a natural consequence.  Consider five common stakeholder roles and the topics each typically focuses on:


Focus   (driven by responsibility)

Buyers / Users Acquire capabilities which deliver value that is relevant to their   intended context of use
Business Managers Achieve profitable revenue growth and competitive advantage, while   reducing development time
Engineering Managers Direct engineering resources to deliver user value, while reducing   development time, cost and risk.
Engineers Deliver working system, while leverage their specialty.  Also, get challenging assignments and learn   new skills in areas of interest.
Architects Ensure system quality attributes such as performance, security,   reliability and extensibility

Complex subjects require specialized vocabularies to precisely describe their concepts.  Specialists must become proficient in these domain-specific languages to learn and communicate with other specialists.


Subject-specific   vocabularies

Buyers / Users Varies by industry.  Medical, pharmaceuticals,   insurance, investments, manufacturing, logistics and journalism each have   their own jargon.
Business Managers Market segmentation, sustainable competitive differentiation,   monetizing value, and risk-adjusted return on investment.
Engineering Managers Work breakdown structures, task dependencies, risk mitigation,   resource utilization, requirements traceability and quality procedures
Engineers Design, implementation, testing and integration.  Nuances of particular technologies, such as   processors, circuit boards, devices, operating systems, databases, networks   or user interfaces.
Architects Quality attributes, challenges, interface contracts, dependencies,   components, connectors, control mechanisms and error detection

Blind Spots Due to Knowledge Gaps

Specialization results in leverage, and as any M.B.A. will tell you, leverage is neither good nor bad.  Rather, it amplifies outcomes.  When leverage works for you,  it makes positive results even better.  However, when it works against you, it magnifies the negative.

As we’ve discussed, specialization permits individuals to focus on the areas in which they are the most qualified and most interested.  The result is that all of the important skills are covered by those who are the most talented and most prepared to contribute.  That’s the good news.

The bad news is specialization creates  knowledge gaps.  This can impair collaboration in three ways:

  1. It constrains the ability to comprehend.
  2. It inhibits the ability to communicate, which limits the potential for learning
  3. It can make a subject be perceived as being less important or relevant

In Mythical Man Month[4], Frederick Brooks takes the Tower of Babel from the Old Testament and recasts it as the first recorded project management failure.  It fits perfectly, because the root cause of the Tower of Babel catastrophe was overspecialization and a failure to communicate.

Today, our poisons do not take the form of Hebrew, Arabic, Persian and Greek.   We have translators to deal with these barriers.  Instead, our toxins take a different, if no less deadly, form.  Successful collaboration relies on the effective transfer of information and knowledge.  When communication fails, we recognize this as people “not being on the same page” (or in more extreme cases, not being in the same book, or not even in the same library).

A few real world scenarios you may have encountered include:

  • Buyers / Users withhold their true priorities because they believe that the provider doesn’t “need to know” them, or assumes they should already know them.
  • Buyers / Users tend to devalue system capabilities which benefit other contexts.  These features are seen as adding cost or increasing complexity, with little or no perceived benefit.
  • Business or Marketing Managers who do not comprehend the internal complexity of a system may undervalue it.  As a result, they fail to commit enough resources, create unattainable schedules, and/or magnify project risk.
  • Business, Marketing or Engineering Managers who lack a clear understanding of how the evolution of technology affects their customers often undervalue the need for extensibility.  They are prone to emphasizing short-term fixes which incur technical debt.
  • Engineers who are highly specialized in certain technologies can fall prey to the adage “to the man with a hammer, every problem looks like a nail.”  These engineers resist new methods, or use them as if they were familiar tools (i.e. treating distributed systems like they were local, or multi-threaded systems running on many cores as if they were running on one).
  • Engineers who are specialized in one technology failing to understand the challenges or constraints of another.  This includes electrical engineers with a limited understanding software and vice versa.  It also includes engineers who complicate testing, or hamstring support technicians with inadequate logging or indecipherable error messages.
  • Architects with an inadequate grasp of core technologies are prone to making naive or overly constraining decisions.

Is There a Remedy?

There’s good news and bad news.  The bad news is that unlike Erectile Dysfunction, you can’t take a little blue pill to fix this problem.  The good news is that there is a remedy, but it’s more like physical therapy.  While it may be painful at first, the remedy can yield some very positive results over time.

  1. Teams must place higher value on improving depth of understanding.

People communicate though a shared understanding in the subject matter.  Communication is efficient and knowledge is transferred quickly when the parties share a deep understanding.  However, when one or more parties have shallow understanding, the flow of knowledge is obstructed, like when a dam blocks a river.

However, we all know that the acquisition of subject matter knowledge requires effort, and the the payoff from this investment is longer term, not immediate.  There always seems to be pressure to produce, to “focus on the real work”, and defer the investment in  knowledge.

However, in the long term, this approach fails.  When a factory runs at 100% capacity and ignores preventative maintenance on its equipment, eventually the equipment will fail.  Successful teams recognize that their long term-effectiveness depends on “a fully-connected knowledge circuit.”

  1. Pay close attention to importance, difficulty, and centrality of subject matters

A project requires mastery of several subject matters.  The set of relevant subject matters varies from project to project, as does their importance, difficulty and centrality.

Each of the subject matters is important, but some are more critical than others.  Each subject matter has difficulty, but some are more difficult than others.  Some subject matters are more central than others – many other subjects depend on them.  Other subjects are more peripheral.  Forming a clear model of importance, difficulty, and centrality of subject matters is a necessary first step.

  1. Be aware of the “knowledge transfer circuit”

A team has participants.  Each participant has three skills relative to each subject matter:

  • Mastery – How well does the individual under stand the subject?
  • Expression – How well can they individual express their understanding to others?
  • Comprehension – How well does the individual process input on the subject?

For relatively simple projects with very small teams, it may be reasonable to expect all participants to be strong in all subject matters.  When you have a 2 person volleyball team, both members are expected to set, spike, block, and dig.

However, as complexity increases, this expectation becomes increasingly unrealistic, and greater levels of specialization are needed.  When this happens, two things are critical.

First, each significant subject matter needs to be covered by at least one person with strong subject matter knowledge. This is the item that most teams and organizations recognize right away.  “We have a risk.  We’re missing an XYZ specialist on our team.  We must recruit one.”

But the second thing is at least as important as the first, and far too frequently overlooked.  The flow of knowledge in a team is like the flow of water in a river.

If person X has subject matter knowledge in S, they must be able to express it, and there must be another person Y with similar subject matter knowledge in S who can receive it.

  1. Be aware of leaks in the “knowledge transfer circuit”

For any significant subject matter, lack of mastery, expression, and comprehension act like dams to block or distort the flow of knowledge.

When X explains something to Y, there can be many ways for knowledge to be distorted or lost:

  • The topic is more complex than X’s mastery of the subject
  • X has sufficient mastery to understand the subject, but has trouble expressing it
  • Y does not have enough mastery to understand the topic well
  • Y does not have enough ability to comprehend what they read or listen to

For flow to occur, knowledge must be relayed through several links.  It may not be sufficient for X to tell Y.  Knowledge may need to flow (in full or condensed form) to A, B, C and D.  Some of these people may receive their input directly from the source, most will receive it second hand.  The presence of multiple links and transfer leaks at each one leads to the “E=nX effect”:

Var Description Case 1 Case 2


average effectiveness of knowledge transfer on a link (0 <= n <=   1),




number of links




effectiveness of knowledge transfer over ‘x’ links:  E=nX



  1. Focus knowledge acquisition effort in the areas that provide the best potential benefit

Knowledge acquisition requires time and effort.   Ironically, these same quantities that always seem to be lacking during a projects.  If improvement in knowledge levels is going to be made, it will need to be done incrementally.  And for improvement to be effective, it must be focused on the areas which have the greatest opportunity for contribution.

So how do you find these opportunities?  Eli Goldratt’s book, The Goal[5], provides guidance: “Identify the dominant constraint, then identify what you can do to relax it or work around it.”

A high-level overview of one approach is to:

  1. Rate each subject matter on importance, difficulty and centrality
  2. Identify and evaluate dependencies between subject matters:
  • How much does each subject matter depend on the high centrality ones?
    • Which project-specific subject matters are joined, where neither is central?
  1. Rate each team member’s mastery, expression and comprehension of each subject
  2. Evaluate this matrix for first-order gaps which impede knowledge transfer:
  • Subject matter with one master and many novices
  • Subject matter with one or more novices/intermediates with low comprehension
    • Subject matter where each masters is deficient in expression
  1. Evaluate this matrix for second-order gaps which impede knowledge transfer.  Second order gaps involve subject matter dependencies.  Some examples are:
  • Two subjects are joined and individuals strong in one are weak in the other.
  • Two subjects are joined and
  • individuals strong in a subject are weak in expression, or
  • individuals weak in a subject are weak in comprehension
    • Individuals who are weak in both a subject and a central subject it depends on
  1. Rate the first- and second-order gaps on the combination of the significance of the subject matter and the magnitude of the gap’s impact.

In summary, what we are trying to identify are:

  • gaps in knowledge, or the ability to effectively communicate knowledge
  • that affect critical individual subjects or subjects which depend on each other
  1. Exploit knowledge transfer amplifiers

Closing gaps to reduce knowledge transfer leaks is like applying a bandage to stop someone from bleeding.  Exploiting amplifiers is like participating in a work out program to build strength or stamina.  The first addresses an area of inefficiency; the second builds a source of leverage.

These three areas amplify the effectiveness of knowledge transfer:

  1. Having subject matter experts hone their expression skills so that they can simplify complex subjects.   This step is most effective for subjects which have well established central-organizing principles (like math, physics, chemistry, physiology, etc.).  It is not as effective for subjects requiring mastery of detail, such as law.
  2. Improving the mastery of central subject matters for all team members.  The leverage created by this step is that it will improve comprehension in all subjects that depend on the high-centrality subject.


Small teams can be effective working on moderately complex projects, especially when there are few subject matters and all team members have reasonably strong expertise in each subject.  Due to the small size of the team, the size of the network used to communicate knowledge is small.  Because all team members have good to moderate mastery of each subject, knowledge transfers are efficient, rarely subject to leaks or distortion.  As a result, when risks or tradeoffs arise, the team members are able to leverage their shared knowledge and ability to communicate effectively to frame them in a consistent manner and resolve them efficiently.

As problem complexity increases, team sizes usually grow. This is usually driven by an increase in scope (resulting from the increase in complexity), but is often compounded by an increase in the number of subject matters (requiring more experts).  When team size increases, communication effectiveness goes down.  One big reason is the number of 2-way links is proportional to the square of team size.  An equally big reason is that the effectiveness of each communication link decreases due to: more subject matters, increased specialization, and knowledge transfer leaks on a high percentage of links.  This latter issue is a big contributor to increases in the number of misevaluated risks and improper tradeoff decisions.  Having many team members failing to understand each other is an expensive business to be in.

Because increasing people’s knowledge is an expensive investment, and because this investment usually competes with project schedules, projects often defer the effort and suffer the consequences.  Like the lumberjack who doesn’t take time to sharpen his saw, the loss of efficiency takes its toll in productivity.

Investment to improve knowledge transfer effectiveness is essential, but it must be done incrementally, and effort must be focused on the high priority areas.  The first priority is to identify the links that cause the biggest leaks in knowledge transfer in the most significant subjects.  The second priority is to focus on high leverage areas, such as enabling experts to simplify complex subjects and focusing on subjects that are very central (have many other subjects which depend on them)

[4] Brooks, Frederick, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley Professional, 1995

[5] E. Goldratt and J. Cox, The Goal: A Process of Ongoing Improvement, North River Press, 2004

TrackBack URI

Blog at

%d bloggers like this: