Enterprise as Noun

@tetradian spots a small, subtle yet very welcome sentence in the latest version of TOGAF. 

"An enterprise may include partners, suppliers, and customers as well as internal business units."

Although similar statements can be found in earlier versions of TOGAF, and the Open Group (which produces TOGAF) has been talking about the "extended enterprise" and "boundarylessness" for over twenty years, these ideas have often seemed to take a back seat. So let's hope that the launch of TOGAF 10 will trigger a new emphasis on the "extended enterprise". 

But why is this so difficult? It seems people are much more comfortable thinking about "the enterprise" or "the organization" as a fixed thing with a clearly defined perimeter. An enterprise is assumed to be a legal entity, with a dedicated workforce, one or more bank accounts and perhaps even a stock exchange listing. 

Among other things, this encourages a perimeter-based approach to risk and security, where the primary focus is to control events crossing the perimeter in order to protect and manage what is inside. Companies often seek to export risk and uncertainty onto their customers or suppliers.

Alternatives to the fortress model of security are known as de-perimeterization. The aptly named Jericho Forum was set up by the Open Group in 2004 to promote this idea, now merged into the Open Group's Security Forum.

Instead of enterprise as noun, what about enterprise as verb, thinking of enterprise simply as a way of being enterprising? This would allow us to consider transient collaborations as well as permanent legal entities. Businesses are sometimes described as "going concerns", and this phrase shifts our attention from the identity of the business to questions of activity, viability and intentionality.

• Activity - What is going on?
• Viability - Is it going? Is it going to go on going?
• Intentionality - Where is it supposed to be going? Whose concern is it?
  

With this way of talking about enterprise, does it still make sense to talk about inside and outside, what belongs to the organization and what doesn't? I think it probably does, as long as we are careful not to take these terms too literally. Enterprises are assemblages of knowledge, power, responsibility, etc, and these elements are never going to be distributed uniformly. So even if we don't have a strict line dividing the inside from the outside, we can may be able to detect a gradient from inwards to outwards, and there may be opportunities to alter the gradient and make some strategic improvements, which we might frame in terms of agility or requisite variety. Hence Power to the Edge.

 

---

Related posts: Dividing Risk (April 2005), Jericho (May 2005), Power to the Edge (December 2005), Boundary, Perimeter, Edge (March 2007), Outside-In Architecture (August 2007), Ecosystem SOA (June 2010)

Service Boundaries in SOA

A service has explicit boundaries

This is one of the four tenets of SOA, promulgated by Microsoft and others around 2004. In its (now discontinued) Connected Services Framework (3.0 SP1), it is identified as one of the four principles of service-oriented design.

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy

I found a presentation on the MSDN website by Udi Dahan called SOA in the Real World (ppt), in which this tenet is expanded as follows.

Services run in a separate process from their clients
A boundary must be crossed to get from the client to the service – network, security, …

Also on the MSDN website, I found some design guidance from ramkoth called Service Boundaries, Business Services and Data, in which the same tenet is expanded as follows.

Services explicitly choose to expose certain (business) functions outside the boundary. Another tenet of SOA is that a service - within its boundary - owns, encapsulates and protect its private data.

In SOA, dollar signs and trust boundaries, Rocky Lhotka describes SOA as a mechanism for bridging trust boundaries. He argues that SOA is expensive (in terms of complexity and performance), and can only decrease the overall cost and complexity when used for inter-application communication across trust boundaries. Trust is not just a security issue, but also a future-proofing issue, because we can't always be sure what future applications will do. A trust boundary therefore helps protect us from an uncertain future, and builds some degree of flexibility into the system of systems.

Where did all the boundaries go?

Now here's the funny thing. All of the pieces I've quoted above were published in 2004, as are the vast majority of hits in the first several pages of Internet search. Apart from one Bill Poole, who published a few blogposts in early 2008 on Service Boundaries, the internet seems to have more or less dropped the concept of service boundary. So am I looking in the wrong place, or has the internet been infected by the misleading rhetoric of boundarylessness?

I'm also struck by the apparently rapid disappearance of something that had been promulgated as an SOA principle. If you think that principles are timeless truths, think again.

Update

In his latest post Service Boundaries Aren’t Process Boundaries Udi Dahan replies with a correction of his 2004 presentation. He points out that his later posts (from 2007 onwards) no longer assert that services must run in a separate "system" or "process". (One reason for this is that the concepts of "system" or "process" belong in a different architectural view.) He still appears to believe in explicit service boundaries, but he is now thinks it's more appropriate to base these on business capabilities. Meanwhile in a new post on Service Boundaries, Lawrence Wilkes outlines the CBDI position, explains that the service boundaries are orthogonal to various other boundaries, including resource, technology and organizational boundaries, and shows how services can be used to cross these boundaries.

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

Chinese Walls

In Joined up Daily Mail, @psbook via @chris_yapp points out a contradiction between the front page (attacking @stephenfry) and an advertisement on page 27 (featuring @stephenfry). "Perhaps the Daily Mail should try a little harder not to offend their advertisers?"

The Daily Mail is not my favourite newspaper (as readers of my posts on the POSIWID blog will know), but with this news my respect for the Daily Mail has gone up a notch - at least they aren't allowing their advertisers to influence the front page.

What's this got to do with architecture? We have here an example of a clash between economics (which apparently favours joined-up thinking) and ethics (which in this case apparently favours the opposite), typically resolved by the erection of an intra-organizational boundary known as a Chinese Wall. This is a structure within an enterprise intended to reduce conflicts of interest, asymmetrical information and moral hazard.

For example, financial institutions are supposed to have Chinese Walls, to prevent various patterns of inappropriate behaviour, including Insider Trading and Insider Recommendations. Among other things, the Chinese Wall is supposed to protect investment analysts from commercial pressure from other parts of the same organization. Recently, there has been much criticism of financial analysts (especially in America) who recommend the purchase of stocks simply because their colleagues have a commercial interest in promoting that stock.

Sometimes of course, the Chinese Wall is just a notional boundary, with little real effect - for symbolic or compliance purposes only. Although the actual information flows may be concealed, a strong correlation between activities on both sides of the wall may be sufficient evidence that some collusion has occurred. (Clearly architects need to appreciate the differences between official structure and defacto structure.)

In journalism, there is always supposed to be a Chinese Wall between editorial and advertising, to protect the objectivity of the journalists from commercial bias. This principle is often blatently breached, so it is pleasing to see the Daily Mail following the principle on this occasion. Although I disagree with their attack on Mr Fry, I respect the fact that the Mail has chosen to offend their advertisers rather than abandon its strongly held views.

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)

Modelling Complex Classification

Andrea Westerinen (Microsoft) posts some modelling guidelines, and she was told that some people's heads exploded when reading them.

• What makes for a "good" model/ontology
• Continuing "What makes for a "good" model?"

She identifies three fundamental modelling concepts, which she draws from the work of Guarino and Welty.

• Essence - these are properties that are true for all instances of a class and that "define" the semantics of the class, such as the "property" of "being human"
• Identity - properties that determine the equality of instances
• Unity - properties that define where the boundary of an instance is, or distinguish the parts of a "whole"

In my work on information modelling (for example in my 1992 book) I have long emphasized the importance of understanding semantic identity (how does something count as being "the same again") and semantic unity (which I tend to call membership - how does something count as inside or outside). 

But I have been critical of the assumption that we always define a class in terms of essential properties. This is known as monothetic classification, and can be contrasted with polythetic classification, which defines a class in terms of characteristic properties. As I teach in my information modelling workshops, many important objects of business attention are not amenable to simple monothetic classification (for example how does a commercial firm decide who counts as a COMPETITOR, how does the police decide who counts as a SUSPECT) and require a more complex logic. 

If you are just building transaction-based systems and services, you may be able to fudge these semantic issues. But if you want information services to support business intelligence and decision-support as well as transaction systems, then you have to get the semantics right. 

Of course I can see why Guarino, Welty and Westerinen want to insist on monothetic classification (which they call rigidity). But then how can they model the more fluid and fuzzy (and I think more interesting) business requirements? 

 (Sometimes the practitioners of "ontology" like to think that they are dealing with supremely abstract and generalized stuff, but if they make too many simplifying assumptions of that kind then their ontologies aren't sufficiently generalized after all.)

 

---

Rodney Needham, Polythetic Classification: Convergence and Consequences (Man, 10:3, September 1975), pp. 349-369. 

Richard Veryard, Information Modelling - Practical Guidance (Prentice-Hall 1992) pp 99-100

Stanford Encyclopedia of Philosophy: Wittgenstein on Family Resemblance

Wikipedia: Family Resemblance

Value of Emptiness

One of the perceived benefits of SOA is business agility and system adaptability. In this post, I am going to discuss some aspects of this.

---

There is a lot of vague and woolly talk about business agility - especially from the software world, where a wide variety of software products, platforms and paradigms are optimistically supposed to have some magical effect on flexibility. But try selling flexibility to the CFO of a large company. ("Excuse me sir, would you like to buy some flexibility? It will only cost you ten million dollars." "Exactly how much flexibility do I get for ten million dollars?" "Ooo, loads and loads, honest. Look, here's a graph we've just made up. And a 2x2 matrix.")

---

Among other things, business agility means keeping your options open.

• Options are worth more when conditions are uncertain.
• In financial circles, the value of options is calculated using the Brook-Scholes formula. Stock options increase in value with the volatility of the underlying stock. This encourages risk-taking by executives.
• Real-Option theory applies the same financial logic to management options. See book Real Options by Amram and Kulatilaka.

In the "plug-and-play" service economy, the business may gain option-value in several ways:

1. the ability to replace specific partners
2. the ability to flex the boundary - moving specific services inwards or outwards across the organization boundary
3. the ability to access heterogeneous domains
   
4. the ability to change the configuration (geometry)
   

To go beyond bland optimism, we need to think rigorously about the business value of openness and extensibility, and how this value can be achieved by suitable configurations of organizational and technical systems - including SOA.

---

Technical artefacts (such as computers) often have empty expansion slots. Ben Hyde discusses the option value of empty slots - who benefits from this unused real-estate?

When the vendor creates a slot he’s relinquishing control over some amount of value-creating energy implicit in his offering.

If there is anything consistent about how they get filled in - for example they all start sporting graphics cards - that’s not stable. The industry will absorb any consistent slot usage into the core.

The space of empty slots [... appears to be ...] a long tail [... which ...] actually has negative value. Since the majority of buyers don’t use the slots they are getting no value from them. The hardware makers are including them not because of buyer demand but because the dominant players in the market want them. The dominant players in the market want them because they tap into the value created by the generative process that all that empty real estate creates.

In other words, the expansion slots provide some temporary free space for innovation. But the big players monitor how this free space is used, and will seek to recapture any rich pickings.

Martin Geddes discusses a number of other technologies (past and present) that have added value by providing options. Many of these were initially dismissed as inefficient. Martin's list includes relational databases and XML - we might add web services.

---

Compare this with the adaptability of buildings.

Lots of old houses were built with outside toilets and no bathroom. Most of those that survive today have had inside toilets and bathrooms added. Many people convert loftspace to make extra rooms, or add an extension into the back garden. Old houses are often relatively easy to alter or extend, subject to planning regulations.

Construction companies build new houses on tight estates with shallow roofs - so there is insufficient space for expansion. Bathrooms are attached to so-called master bedrooms, thus constraining alternative ways of using the space. It is as if the construction companies deliberately set out to build houses that are pre-adapted to a specific domestic norm, thus forcing people to move house every time their domestic requirements changed.

See Stewart Brand: How Buildings Learn.

---

The human being is a highly inefficient machine, with few natural advantages over other species and practically no innate skills. It takes many years before it can find its own food, or run half as fast as an animal. It has a large brain, consuming vast amounts of energy and other nutrients. The exceptionally long period of dependence, together with its feeble skills in relation to other animals, represents a considerable biological burden.

How on earth does this gross inefficiency survive? In complex and dynamic environments, there is a compensating evolutionary advantage - the human has lots of expansion slots - can learn new skills, including collective skills. It can develop new languages - both natural languages and problem-specific vocabularies. (DSL anybody?)

---

So what are the expansion slots of a business? Obviously new products, new suppliers, new business partners, new channels. But more importantly, new responses to changing demand. With a stratified model of the demand-side, and with appropriate supply-side platforms, we should be able to (re)design a business to deliver requisite levels of agility. And this will naturally include space for innovation.

---

Update: Stewart Brand has now introduced the term pace layering for the principle that stratification should be based on the differential rate of change. The term shearing layers refers to what happens when this principle is not followed.

See also Andrew K Johnston, Business Flexibility - An Analogy (2005)

BPEL Usage Patterns

I am currently writing a series of articles on BPEL for the CBDI Journal. In the first of these articles, Orchestration Patterns Using BPEL, I discuss the following six ways in which a company can get benefits from BPEL.

Usage Pattern	Description
Process Separation (e.g. EAI/Workflow)	Process flow logic is contained in a separate layer, which is developed and maintained separately. This may correspond to a technical architecture in which the workflow is executed by a separate software engine.
Process Instrumentation (e.g. Business Activity Management)	An interface is provided into the orchestration layer, exposing it for direct monitoring and intervention. Now the process flow can be defined and managed by the process manager, often without IT involvement.
Process Componentization (e.g. grid-like solutions)	BPEL can be used for the orchestration of informal processes, where process components can be assembled rapidly or dynamically as required. This might also support a form of grid-like solution, where process components provide elementary integration scripts.
Process Generalization (e.g. Application Packages)	BPEL is used to increase the flexibility of an application package, thus allowing it to be implemented in a wider range of organizations with greatly reduced customization.
Process Standardization (e.g. External Services and Exchanges)	Service-based interfaces using BPEL processes
Process Flexibility (e.g. Dynamic Outsourcing)	A BPEL-based process allows dynamic changes to orchestration. For example late binding with your service providers, allowing process steps to be easily moved to and fro across the organizational boundary.

 

---

References

• Orchestration Patterns Using BPEL (CBDI Journal, October 2004)
• The BPEL Enabled Process (CBDI Journal, November 2004)

Related posts

• Urgent Process Change (October 2004)