Who's smart enough to use models?

Nascent Blue — Thu, 23 Aug 2012 13:34:05 +0000

I recently saw a discussion on a question that goes something like this: "Are our [Architects | Analysts | Developers | Business SMEs] able to understand and create models?" This is a question I've been asked many times in Nascent Blue's Architecture and Delivery practices. My reaction to this question assumes the "Architect" role in question refers to the Solution Architect (as opposed to a Technology or Software Architect). The short answer is, "yes, absolutely!" In my decades of experience in various industries and across many companies - large and small - I have yet to meet an individual who couldn't interpret a model. And this is why:

Architects, Analysts, Developers, Business SMEs, etc. are all "knowledge roles". As such, these "knowledge workers" are already capable of, and comfortable with, managing and conveying knowledge. All knowledge roles have the inherent capability to read models. All they need is the key for reading them. This is very much like street maps or street signs. Once you understand the symbol key (shapes, keywords, colors), you can quickly retrieve the information needed to navigate and drive.

Just because it's inherently easy to learn how to read a map, doesn't mean its easy to become a cartographer. You'll probably be able to sketch a map to convey directions to another party, but nobody will pay you to do it. Likewise, creating adequate models is a skill that is acquired and mastered only through practice and experience. People who create models must become proficient in modeling tools and notations, in addition to being able to elicit, analyze, and structure information.

In my experience, technically trained people tend to be stronger at mastering tools and notations, while analysts and Business SMEs tend to be stronger at eliciting information. Because of this, I usually separate the capture of information from the structuring of the model. Usually, Analysts and SMEs will start a model, and then the Architect will finish the model by applying best practices (e.g., high cohesion, low coupling, abstraction) and proven patterns. This will feed back into the Analysts, who will then begin to slowly absorb the techniques and become increasingly proficient in their modeling skills. The same is true in the other direction - the Architects will become more familiar with the business and improve their skills of eliciting business knowledge.

Now for the wrinkle. The most common practice is for each of these knowledge roles to use different tools and notations for representing knowledge. This creates a lot of waste and "friction" because each of these roles are potentially working with the same knowledge, and likely need to communicate that knowledge among themselves. Capturing and representing the same knowledge many times and in many formats creates a lot of confusion and inefficiency for everybody who needs access to the knowledge. In addition to being inefficient, it creates a large gap in understanding between the Business and IT and creates room for ambiguity and misinterpretation. This in turn results in IT organizations that are consistently too costly, too slow, and generally ineffective and inefficient in matters that concern the Business most.

Whether this inefficiency and gap in understanding could be addressed through the more pervasive use of models was a major reason for the question. In Nascent Blue's practice, creating rich and precise models is exactly how we close this gap. The Architects, Analysts, Developers, and Business SMEs that we work with enthusiastically embrace this approach. They quickly realize that having better information enables them to make better decisions, and add more value to the business.

Sustaining Low IT Cost

Nascent Blue — Sat, 15 Aug 2009 16:18:54 +0000

Today, many CxOs believe IT cost can be managed predominantly by reducing the rate of labor. However, this is often not the case because doing so does not give fair consideration to measures of productivity, which are the significant indicators of cost. For example, reducing labor cost by 25% while reducing productivity by 50% actually increases cost by 12.5%.

A Winning Strategy for Lowering the Cost of IT

Nascent Blue — Sun, 02 Aug 2009 02:14:56 +0000

This article explains why the IT industry has not been able to successfully adapt the assembly line concept and why simply off-shoring commodity IT tasks will not achieve better results; and potentially worse results. This article also introduces a strategy for achieving the desired results of lower cost, uniform-quality, and higher productivity.

The Decline of Labor Arbitrage as an IT Outsourcing Strategy

Nascent Blue — Sun, 02 Aug 2009 00:58:29 +0000

Nascent Blue believes there is a better way to manage the cost of IT than simple labor arbitrage. There is a way that is more socially responsible, more economically sound, and infinitely more sustainable. Nascent Blue believes in an approach based on knowledge workers using automation technology to eliminate the need for cheap labor. In other words, we string to use machines to automate the low skill activities of developing software.

CxO Corner

Who's smart enough to use models?

Sustaining Low IT Cost

A Winning Strategy for Lowering the Cost of IT

The Decline of Labor Arbitrage as an IT Outsourcing Strategy