"Oriented"? Architectures

What's with "Oriented" architectures? Though lots of heat has been generated by discussions of SOA, REST, WOA, etc. over the past few years, I'm not sure I've heard anyone address the emergence of architectures that are more style than substance (as I explain below, I'm not using "style" or "substance" in the sense they normally take in this cliche).

And, the term "Oriented" seems to point to the ontological nature of an architecture, implying that our focus should be on analyzing this Knowable terrain (Cynefin taxonomy). If the terrain is more Complex than Knowable, perhaps we should call these architecture styles "Orienting" to emphasize the epistemological activity of probing a Complex space.

My initial reaction to the SOA/WOA/etc. swirling was that it indicated we were in the early stages of defining a new area of knowledge, and therefore were debating taxonomy (which is step #1 in creating formal knowledge...define the foundational distinctions). The latest summary I've seen on this topic asks if WOA is "An Acronym Too Far?"

On further reflection, it seems to me that perhaps traditional architectures are frameworks for creating capabilities in domains that are largely Knowable (Cynefin taxonomy). An frequently cited example is NOAA's NOSA.

"Oriented" architectures, on the other hand, seem to be more about creating capabilities in domains that have a significant Complex aspect (Cynefin taxonomy). Dave's observations about decision making in Complex domains would seem to point us toward tactics like the following:

• Instead of static requirements, deploy capability creation attractors. These would include items that enable users to create their own capabilities (e.g., mash-up tools like JackBe, Yahoo Pipes, Popfly, etc.), and social linking tools (e.g., tagging, graphing, etc.) to catalyze coherent exploratory activities across an enterprise.
  
• Instead of well-defined processes, design clear boundaries for how these tools will be used. This area is less clear since the gating factors today are more related to a scarcity of attractors. However, as that changes, policy & governance capabilities that provide flexible boundaries will be required.
  
• Perhaps most difficult of all, seed a culture that effectively balances the Complex & Known/Knowable aspects of all capability creation needs and contexts. This means that individuals and groups can quickly and instinctively understand where they need to take an "Orienting" approach, where they need to take an analytical approach, and how they move between the two.

Since this is all relatively new, especially for enterprises, significant challenges remain. For example (as Dave has noted), social media tools (at Internet scale) currently need more structure to become relevant to many Complex decision making contexts. And, most enterprises aren't large enough to effectively leverage many of these tools.

Most of all, almost no one within today's enterprises understands that "Oriented" architectures are qualitatively different. We have decades of experience in building traditional architectures, and that experience is built on top of centuries of experience with analytical (rational + empirical) frameworks.

For now, it may be that what's most needed is to (a) run lots of small/fast experiments to better understand how to effectively architect in an "Oriented" fashion, and (b) be very careful about creating "Oriented" capabilities in the image of a traditional architecture.

And, consider calling them "Orienting" architectures.