Gregor's Ramblings

Explaining Stuff

AUG 30, 2014

Gregor HohpeHi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also an Enterprise Strategist at AWS.
ALL RAMBLINGS  Architecture (12)  Cloud (10)  Conversations (8)  Design (26)  Events (27)  Gregor (4)  Integration (19)  Messaging (12)  Modeling (5)  Patterns (8)  Visualization (3)  WebServices (5)  Writing (12) 

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home:

At a recent presentation, Martin Fowler introduced himself as a guy "who is good at explaining things". While this certainly has a touch of British Understatement™, it also highlights a critically important but rare skill in IT. As technology invades all parts of personal and professional lives, causing companies to absolutely depend on software and systems, decision makers often can no longer keep track of technical details. While no business executive is expected to code a solution, complete ignorance of technological evolution and capabilities undoubtedly leads to missed business opportunities or unpleasant surprises of IT systems not being able to deliver what the business needs or want.

Because architects live at the intersection of technology and business, it is their responsibility to highlight the ramifications of technical decisions to the extent they influence development and operational cost, flexibility, agility, or other factors that have a direct impact on the business. As the speed of technology evolution continues to increase and technology plays an increasingly critical role in new product innovation, the group of "non-technical" people who have to concern themselves with the ramifications of technological decisions will keep on growing.

But it's not only "business types" who face this challenge. Even architects and developers cannot possibly keep up with all aspects of complex solutions, forcing them to rely on easy-to-understand, but technically accurate descriptions of architectural decisions and their implications.

High-performance Computing Architectures for Executives

A team of architects was recently asked to define a new hardware and software stack for high-performance computing, ranging from workload management to storage, for review and approval by a management steering committee. Such a recommendation has to consider complete stacks like Hadoop, which includes a file system as well as a workload distribution mechanism, as well as stand-alone workload management solutions like LSF that run on top of a high performance file system. When looking through the slides, I noticed "POSIX compliance" as criterion for the selection. While this may be completely appropriate, how do you explain to someone who knows little about file systems what this means, why it is important, and what the ramifications are?

Build a ramp, not a cliff

We like to talk about learning curves as "steep", meaning it is tough for newcomers to become familiar, or "ramp up", with a system or tool. I tend to assume my executive audience is quite intelligent (you don't get that high up simply by brown-nosing and playing politics), so they can in fact climb up a petty steep learning ramp. What they cannot do is climb up a vertical cliff.

Build a learning ramp, not a cliff

Building a logical sequence and drawing conclusions in an unfamiliar domain is "steep", but doable. Being bombarded with out-of-context acronyms or technical jargon constitutes a "cliff". "Posix compliance" is a cliff for most people. Explaining that POSIX is an API standard widely adhered to by most Unix distributions, and thus avoids lock-in, builds a ramp. More importantly, executives could quickly reason that because they standardized on a specific Linux distribution, POSIX compliance may not actually be quite as relevant as long as the file system is compatible with that distribution. Now you involved someone who is not deeply technical in the decision making without using much more than a few words. That is a steep, but passable ramp. The ramp may not take the audience into the depths of POSIX versions and Linux flavors, but it is sufficient within the scope of the discussion at hand. A steep ramp quickly becomes too tiresome if you are trying to have your audience climb up to the peak of Mt. Everest, so think about how high (or deep) you need your audience to go. Details about POSIX history and LSB are not material to the decision at hand, so you should omit them.

First, create a language

When preparing such conversations I tend to use a two-step approach: first I set out to establish a basic mental model combined with some vocabulary. Once equipped with this, the audience is able to reason in the problem space and to discern the relevance of parameters onto the decision. The mental model does not have to be anything formal, it merely has to give the audience a way to make a connection between the different elements that are being described.

In the file system example above I would first describe how file access is composed of a stack ranging from hardware (i.e. disk), basic block storage (like a SAN) to file systems and ultimately the operating system and the applications on top. This does not even have to occupy half a slide. Then I can use this vocabulary to explain that Hadoop is integrated from the application layer down to the local file system and disks without any SAN, NAS or the like. This has specific advantages, such as low cost, data locality management etc, but requires you to build applications on top of this complete stack. In contrast, stand-alone file systems for high-performance computing, for example GPFS or pNFS, either build on top of standard file systems or provide "adapters" that make the proprietary file system available through standard API's. Now this is where the argument of POSIX compliance adds some value, as the audience can now understand why it is important and that Hadoop HDFS does not provide this feature.

Consistent level of detail

When creating such a line of reasoning determining the appropriate level of detail is difficult. For example, we pretended "POSIX" is a single thing when in reality there are many different version and components, the Linux Standard Base etc. The ability to draw the line at roughly the right level of detail is an important skill of an architect. Many developers or IT specialists will consider all this detail terribly obvious and have a difficult time refraining from inundating their audience with irrelevant jargon.

As with any document or presentation, drawing the line at the right level of detail requires you to know your audience. If your audience is mixed, building a good ramp is ever more important as it allows you to catch up folks less familiar with the details without boring the ones who are. The highest form of creating the ramp is such that audience members already familiar with the subject matter appreciate your way of explaining it despite not having learned new facts. This is tough to achieve, but a noble goal to aim for.

Getting the level of detail "just right" is usually a crapshoot, even if you do know the audience. At least as important, though, is to have a consistent level of detail. If you describe high-level file systems on slide one and then dive into bit encoding on magnetic disks in slide two, you are almost guaranteed to either bore or lose your audience. Therefore, strive to find a line that provides some amount of cohesion for the reasoning required to discern the architectural decision at hand.

To want I would have liked, but to be allowed I didn't dare

This is my poor translation of Karl Valentin's famous quote "Mögen hatt ich schon wollen, aber dürfen habe ich mich nicht getraut", which remind me of the biggest challenge in explaining technical matter: too many architects believe their audience will never "get" their explanations anyway or will consider them a gearhead unfit for management for trying to do so. Others go a step further and actually prefer to confuse management with disconnected jargon so that their "decisions" (in fact, often simply preferences or vendor recommendations) are not unnecessarily put into question.

I have a very critical view of such behavior. Your role as an architect is to get a broad audience to understand the ramifications of decisions and assumptions that were made. After all, this is where most of the biggest problems pop up. For example, if a few years later an IT system can no longer serve the business needs, it is often due to a constraint or an invalid assumption that was made but never clearly communicated. Therefore, communicating decisions and trade-offs clearly protects both you and the business.


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is an Enterprise Strategist with Amazon Web Services (AWS). He is a frequent speaker on asynchronous messaging, IT strategy, and cloud. He (co-)authored several books on architecture and architects.