Boundaryless Information Flow

@theopengroup describes itself as "a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow™ will enable access to integrated information, within and among enterprises, based on open standards and global interoperability". But what exactly is Boundaryless Information Flow?

I had always seen this slogan as representing a continuation of the "open" thinking that inspired the Open Systems movement. The Open Group itself was a merger between the Open Software Foundation and X/Open, and was originally focused on UNIX. [Wikipedia: The Open Group]

This agenda was presented in numerous articles in the early 2000s. See for example this article by Allen Brown, president of the Open Group (Oct 2002).

But nowadays, a lot of the activity of The Open Group is now focused on enterprise architecture and TOGAF. Perhaps as a consequence of this, much the emphasis of recent materials appears to be on information flow and interoperability inside a single organization.

Boundaryless Information Flow, a shorthand representation of “access to integrated information to support business process improvements” represents a desired state of an enterprise’s infrastructure and is specific to the business needs of the organization. [Open Group Vision and Mission, retrieved 20 June 2011]

A Boundaryless Organization needs Boundaryless Information Flow and the systems currently supporting the business processes present obstacles because they contain multiple stovepipe point solutions where information is not currently shared – that is there is a lack of integrated information. [Open Group FAQ, retrieved 20 June 2011]

It seemed to me that the TOGAF folk are largely focused on internal information sharing (what I call endo-interoperability). So I contacted Allen Brown to check whether this implied that the original mission of the Open Group had been watered down, and whether the Open Group had any other initiatives devoted to open exchanges between organizations and across ecosystems (exo-interoperability). Allen assured me that the original mission remained in force, and emphasized that the term "enterprise" should be understood to refer to the extended enterprise and not just the traditional organization.
 
In 1995, Ron Ashkenas and others published a book called The Boundaryless Organization, based on work done with Jack Welch at General Electric. According to some sources, the term was coined by Welch. See review by Barbara Noble (Strategy+Business, April 1996).

But what's wrong with boundaries anyway, and should we take the rhetoric of boundarylessness literally? Undoubtedly, many existing boundaries are dysfunctional and create inefficient, ineffective and error-prone processes, but that doesn't mean that all boundaries are necessarily bad. Apparently, even Jack Welch didn't think that boundarylessness implied a complete absence of boundaries, merely that the boundaries needed to be porous. In other words, managed interfaces.

But just think about it. If all the boundaries are removed or porous, then the (extended) enterprise or ecosystem becomes like a giant sponge, in which all information permeates the whole. Some people may think that's a good idea, but it's not what I'd call loose coupling.

In my 2001 book on the Component-Based Business, I explained the importance of (non-porous) boundaries in loosely coupled enterprises and ecosystems, and outlined some of the design and management principles for managing boundaries between autonomous and robustly bounded chunks of business capability (which I called business components). My work was influenced by organizational theorists such as Larry Hirschhorn and Karl Weick, as well as earlier work by Lawrence and Lorsch.

The relationship between boundaries and loose coupling is an important one. I don't think anyone is saying that a business component is as rigorously encapsulated as a software component, but an autonomous business component needs to have some ability to cut itself off from its environment. Concepts such as information hiding, knowledge hiding, specialization, separation of concerns and division of responsibilities all imply some degree of closure rather than total openness.

How many people understand the implications of this? Perhaps I need to publish a new edition of my book.

The Sage Kings of Antiquity

The ancient Chinese philosopher Mozi (Mo Tzu) identified three criteria for judging a theory

1. Origin - reference to the sage kings of antiquity
2. Validity - reference to the evidence ("the eyes and ears of the people")
3. Applicability - whether it brings benefit to the enterprise and the people

Mozi called this his "three-prong method". [Wikipedia: Mozi]

Enterprise architecture frameworks can and should be judged against the second and third of Mozi's criteria, and I should certainly like to see more effort and rigour in presenting the evidence to support a wide range of so-called principles and methods.


But what about Mozi's first criterion? Much of the current thinking and practice of enterprise architects can be traced back to a bunch of methodology gurus from the 1980s. A complete list would be impossible, but it would include people like Tom de Marco, Clive Finkelstein, Michael Jackson, James Martin and Ed Yourdon, and with John Zachman just gettting in at the end of the decade. (I think Zachman has more in common with these methodology gurus than with the OO/Patterns gurus - Booch, Jacobson, Rumbaugh, Wirfs-Brock et al - who followed them.)

The term "enterprise architecture" wasn't used in the 1980s, and appears to have been coined by Steven Spewak in the early 1990s. In those days, people generally talked about Business Systems Planning (BSP) and Information Systems Planning (ISP), and a lot of the early thinking came out of IBM (where both James Martin and John Zachman had worked). Information Systems Planning was the top level of the Information Engineering pyramid, produced by Finkelstein, Martin and others.

Why should 21st century enterprise architects care what the sage kings of methodological antiquity thought about enterprise systems? Firstly because the sage kings have given us a huge legacy of principles and practices, much of which are still in use today. Secondly because some of the assumptions made by the sage kings may now look obsolescent, not just because of technology change but because of emerging ideas of complex systems organization and management, and we need to critically review and refresh our principles and practices to ensure we are not still bound by these assumptions. And thirdly because there may be some principles and practices that have fallen into disuse and deserve to be revived.

Given that the empirical evidence for enterprise architecture is fairly weak, anecdotal and inconclusive, we are still more dependent than we might like on the authority of experts - whether this be semi-anonymous committees (such as TOGAF) or famous consultants (such as Zachman). And are the experts consciously or unconsciously recycling the wisdom of the sage kings?

So how much difference is there between today's enterprise architecture frameworks and the structured enterprise methodologies of the 1980s, such as information engineering? And how confident are we that we have kept the good bits and discarded the bad bits?

---

Declaration: I worked for James Martin Associates from 1986 onwards.

Fast data - speed over precision?

@bmichelson posts a piece on an HP website called Fast Data: Speed over precision for better decision-making (21 June 2011), summarizing a recent interview in MIT Sloan with Ali Riaz and Sid Probstein of software company Attivio.


Riaz and Probstein are not claiming that better decision-making is just about speed: it also requires a continuous refinement loop, including rethinking one's premises. In other words, we need multiple feedback loops at different speeds, to handle different levels of complexity. As I pointed out in my piece on TIBCO's slogan Two Second Advantage, although simple decisions can be taken quickly, complex decisions need what I call "time for understanding".

One of the architectural challenges of organizational intelligence is to coordinate a complex array of sense-making and decision-making processes operating at different characteristic tempi, and to maintain a proper balance between the very fast (reactive) and the comparatively slow (reflective). Probstein identifies Amazon.com as a successful exemplar.

It is common for technologists to make a fetish of speed, but business effectiveness and organizational improvement need "time for understanding" as well. Riaz and Probstein appear to understand this, and I look forward to seeing how this understanding is supported by their software.