Why SOA is Orienting

On a morning run this week, I listened to a recent Dave Snowden podcast of a presentation given to IT professionals at an Agile Conference in Limerick. Some Dave's points about sensemaking triggered a few thoughts about how SOA is more aligned with sensemaking than traditional IT.

Before I get into those, I think it's worth noting that architecting frameworks/styles have "orienting" or sensemaking needs. Whether it's Zachman or MODAF or TOGAF or etc., a useful framework highlights certain fundamental distinctions and relationships that are used by an architect as a map to organize the the architecting territory for architecting decisions.

Although the SOA "style" is obviously different from frameworks that involve an architecting process, there are similarities in that both styles and processes fundamentally shape how architecting is performed.

The process of applying an architecting framework/style to a real world context involves at least three sensemaking/orienting activities:
(a) the architect orienting to the context (in light of the framework/style),
(b) the architect orienting to the framework/style (in light of the context), and
(c) the architect orienting to the (never completely clear and continually evolving) relationship between the context and the framework/style.

In traditional IT architecting, we tend to complete most of this orienting work by late in the requirements phase or early in the design phase, and the bulk of the work is usually associated with some mixture of (a) and (c).

In SOA, significant chunks of this work are potentially not completed until the user "composes a CONOPS" by discovering and weaving together previously deployed services. Allowing key architectural binding decisions to be delayed until the user interacts with developed capabilities is a significant departure from traditional systems which "give you any color you want as long as it's black."

Since SOA is a relatively immature style, IT architects have just begun to understand its strengths, weaknesses, basic patterns, etc...especially when compared to traditional architecting frameworks/styles.

And, it would also seem that this difference in how sensemaking occurs in SOA's will result in major changes in how IT architects orient to an architecting context and, finally, the interplay between context and framework.

Hence my assertion that SOA is as much about orienting as Oriented.

Back to the thoughts triggered by Dave...

As my tagline ("the intersection of decisions and technology") implies, there are decision making influences on technology and technological influences on decision making. Here's some of the human aspects that Dave highlights, along with my observations about traditional IT and SOA:

• Humans filter out all but 2-3% of the data they're exposed to; IT has very constrained input capabilities that usually do very little filtering.
• Humans orient using (a) fragmented patterns that were (b) recently activated; IT "orients" by exhaustively searching all data (often by using sophisticated, but static, pre-built indices/patterns).
• Human memory morphs every time it is activated, and tends to adapt/evolve to a context; IT data is static.
• Humans detect "weak signals" by noticing anomalies that trigger patterns. Weak signal detection is improved by keeping inputs ambiguous and "priming" memory by activating memories of high-risk/low-probability narrative fragments. IT has nothing like this, and tends to "fight against" human sensemaking by flooding a decision maker with large amounts of data.

Although SOA is still more IT than human in these dimensions, SOA does seem to be significantly more amenable to filtering, fragmented & morphing than traditional IT. To the degree that's true, it implies that architecting, design, development, deployment, and use of SOA will involve much more orienting throughout all phases than traditional IT.

Bottom line: Traditional IT is a typical tool in the sense that we don't interact much with it to solve a problem. As with a hammer/saw/etc., our interactions tend to be in a prescribed (and proscribed) manner with most of the adaption occurring outside the tool. SOA is more like a rope than a hammer in that we can use the tool to explore our understanding of needed capabilities and then use the tool to develop/evolve those capabilities.