Showing posts with label OpenGroup. Show all posts
Showing posts with label OpenGroup. Show all posts

Wednesday, June 29, 2011

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 these articles by Allen Brown, president of the Open Group (Oct 2002, Dec 2003).

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.




Philip Boxer, Leading Organizations without Boundaries (Organizational and Social Dynamics 14/1, 2014)

Loizos Heracleous, Boundaries in the study of organization (Human Relations 57/1, 2004)

Larry Hirschhorn and Thomas Gilmore, The New Boundaries of the “Boundaryless” Company (HBR May–June 1992)

I spoke on Boundaryless Customer Engagement at the Open Group conference in October 2015. See Autumn Events 2015 for summary and link to slides.


references added 15 Feb 2016

Thursday, April 30, 2009

SOA Sourcebook (Open Group)

I have just got my hands on a copy of the SOA Sourcebook, produced by the SOA Work Group of The Open Group and launched at the Open Group Architecture Practitioner Conference. (See my review of the Open Group Boston Grid.) I also spoke with Chris Harding, Forum Director for SOA and Semantic Interoperability. 

Most of the ideas in the SOA Sourcebook have been circulating around the SOA world for some time, and there is (not surprisingly) a lot of overlap (with more or less variation) with material the CBDI Forum has published from 2003 onwards. 

Some of this material has also found its way into TOGAF 9, but the SOA working group is not tightly coupled with the Architecture Forum (responsible for TOGAF). 

The SOA Sourcebook defines SOA as an architectural style, although it also defines it as a construction technique. As an architectural style, service orientation can apply to the business architecture as well as to the software (application) architecture and the technology (infrastructure) architecture, and you can have any of these without the other two if you want; but as the SOA Sourcebook acknowledges "many people believe that the greatest benefits of SOA are obtained when it is applied to the business architecture". 

However, the SOA Sourcebook focuses on the IT component of enterprise architecture - in other words, service orientation as applied to the software (application) architecture - and this is where the view of SOA as a construction technique would also make sense. 

The motto of the Open Group is "Boundaryless Information Flow". The SOA Sourcebook shows how SOA can achieve permeable boundaries, but of course that's not the same thing as lack of boundaries. For a deeper analysis of boundaries, you are going to have to look at Chapter 4 of my book on the Component-Based Business. But there are clearly construction issues as well as strategic requirements when joining loosely coupled lumps of enterprise as well as loosely coupled lumps of software. 

Inclusion in a long term IT strategy, created by Enterprise Architecture, is the only good justification for large-scale SOA. From an SOA perspective, this might be interpreted as saying that the de facto purpose of EA is to justify SOA. Clearly there is a common interest between EA practitioners and SOA practitioners, which The Open Group will doubtless continue to develop.

 

More posts on TOGAF including one on Boundaryless Information Flow (June 2011)