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)

At least three views of business architecture (TOGAF)

In a previous post, I looked at the five viewpoints of business architecture according to the OMG. In this post, I shall look at the architectural modelling viewpoints indicated in TOGAF 9.1. (Section 8.2). In TOGAF, these viewpoints are presented more as suggestions rather than as a recommended set.

1	Hierarchical Activity Models (also called Business Process Models)	Functions, data/information exchanges, activities, inputs, controls, outputs, mechanisms/resources, business rules	General
2	Use Case Models	Business processes, system functions, use case, actor,	General
3	Business Class Models	Information (entities and implementation classes, attributes and relationships), information behaviours	General
4	Node Connectivity Diagram	Nodes (role, org unit, location, facility), information transfer/flow	Defence sector
5	Information Exchange Matrix	Information Exchange	Defence sector
6	Resource-Event-Agent Model	Resources (goods, services or money), Event (transactions and agreements), Agent (people and organizations)	Accounting domain

According to TOGAF, "a variety of modeling tools and techniques may be employed, if deemed appropriate". Items 1-3 are offered as general examples.

Items 4 and 5 are described as follows. "Although originally developed for use in the Defense sector, these models are finding increasing use in other sectors of government, and may also be considered for use in non-government environments."

Item 6 is included in a list of "business models relevant to common high-level business domains". Whereas the other members of the list are specific industry models, the Resource-Event-Agent (REA) Model appears to be a modelling viewpoint - indeed Wikipedia calls it an ontology. TOGAF asserts that the REA model "has proved so useful for better understanding of business processes that it has become one of the major modeling frameworks for both traditional enterprises and e-Commerce systems", but this assertion is contradicted by Wikipedia which suggests that its main influence has been in the classroom and in the development of such standards as ebXML.

Wikipedia: Resources, events, agents (accounting model)


TOGAF's set of viewpoints strongly emphasizes the information processing and information exchange elements of business architecture, while neglecting a number of other elements that are included in the OMG five viewpoints or my own six viewpoints.

TOGAF lists a number of additional outputs from the business architecture work, which go beyond the modelling viewpoints it has specified. These are as follows.

Catalogs

Organization/Actor catalog, Driver/Goal/Objective catalog, Role catalog, Business Service/Function catalog, Location catalog, Process/Event/Control/Product catalog, Contract/Measure catalog

Matrixes

Business Interaction matrix, Actor/Role matrix

Diagrams 

Business Footprint diagram, Business Service/Information diagram, Functional Decomposition diagram, Product Lifecycle diagram, Goal/Objective/Service diagram, Use-case diagram, Organization Decomposition diagram, Process Flow diagram, Event diagram

Finally, TOGAF includes Business Scenarios, but I think this probably counts more as a requirements gathering technique than an architectural viewpoint.

I should welcome comments, especially from people who are familiar with TOGAF in practice.

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

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)

TOGAF 9 - Enterprise Continuum

The concept of Enterprise Continuum was present in TOGAF 8, but it is a little clearer in TOGAF 9.

What is an Enterprise Continuum? In TOGAF 8, it was defined as "a virtual repository", but this wasn't very clear. In TOGAF 9, it is now defined more explicitly as "a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures". In other words, it is not the repository itself, but a way of classifying the content of the repository.

The relationship between the generic and the specific has always been a critical dimension of architecture, as I've argued on this blog many times (see label: generic v specific). Enterprise Continuum provides a framework for architects to reason about the right level of generality or specificity for a given artefact.

Here are some implications of this framework.

• Progressive Refinement - Many methods assume progression from the generic to the specific, sometimes known as "refinement". But this is not the only possible approach, and is not always the most appropriate. (See my posts on Progressive Design Constraints and Analyzing the Rusty Lawnmower.)
  

• Management of Variation - Capabilities can often be decomposed into highly generic elements and asset-specific elements. (See my example of Green Coffee Beans.) Decoupling these capabilities helps to drive higher levels of cross-process and cross-organizational sharing. With SOA, this can be supported by separate architectural layers. (See my posts on Homogeneous Business Vocabulary and Merging Capability Modelling with Process Modelling.)

• Adaptation and Adaptability - To achieve agility or flexibility, an enterprise or system or solution may need to be under-determined. This is sometimes confused with abstraction. (See my posts on Adaptation and Adaptability.)
  

• Strategic Differentiation - Enterprise architects need to understand the ways in which a given company is similar to any other company in the same industy sector, and what particular things differentiate this company from other companies. (See my posts The General and The Particular and Service Planning.)

But although this is a critical question for architects, it is poorly supported by the prevailing tools and methods, which often reduce the question to simplistic abstraction hierarchies. Let us hope that TOGAF 9 stimulates further development in this area.

TOGAF 9 - Holistic Enterprise Change

One of the advertised features of TOGAF 9 is something called "Holistic Enterprise Change". A quick Internet search for this phrase revealed very few hits, mostly to the TOGAF materials themselves. Here's what the Open Group says (What's New In TOGAF 9).

"TOGAF has a solid history in IT architecture, considering the ways in which IT can support enterprise change. However, as TOGAF has grown in depth and maturity it has become a framework for managing the entire spectrum of change required to transform an enterprise towards a target operating model. TOGAF 9 continues this evolution and incorporates a broader perspective of change that allows enterprise architecture to be used to specify transformation across the business, data, application, and technology domains."

Is that it? What exactly is there in TOGAF 9 that justifies this claim? I don't believe TOGAF 8 was ever fully explicit in excluding these elements, and TOGAF 9 doesn't provide much new detail on these elements.

I've got an idea what it ought to mean, but I am aware that "holistic" is one of those words that people often abuse - perhaps thinking it's just a fancy way of saying "complete" or "comprehensive" or even "alternative".

My understanding of holistic is that it entails some kind of emergence - the whole is greater than the sum of the parts. See Wikipedia on Holism.

In the context of enterprise architecture, this could mean something like this: When you make changes to the business as well as changes to the systems, you may get more than you bargained for. Conversely, when you make changes to the technical systems without making changes to the human systems, you may get less than you bargained for.

Is this perhaps what TOGAF 9 is getting at? If so, does TOGAF 9 have any answers to these fundamental questions?

---

I posted a question about the meaning of holism to two Linked-In groups. There was an excellent discussion on the Enterprise*As*Systems group. On the Enterprise Architecture Network, however, the comments all appeared to assume that "holistic" meant the same as "whole". Having looked at the TOGAF presentations by Walter Stahlecker and others, I have regretfully come to the conclusion that the use of the word "holistic" in TOGAF also reflects this misunderstanding.

I know Wikipedia isn't perfect, but it did contain a reasonable definition of holism, which I had pointed to, so there's no excuse for ignorance.

TOGAF 9 - Business-Led SOA

Shall we see SOA as a software engineering challenge or a business opportunity? TOGAF 9 makes a clear and unequivocal statement in favour of the latter, and identifies the following characteristic features of Business-Led SOA.

• Rich domain knowledge of both horizontal, cross-cutting concerns, such as human resources (HR), finance, and procurement alongside vertical, industry-specific concerns

• A structured, quantitative understanding of business value, costs, differentiators, and quality measures

• Broad understanding of current capability, showing both business capability and how it is supported by IT

• Broad understanding of the feasibility and viability of particular SOA technology-driven solutions

Source: TOGAF 9 22.3

This is contrasted with "a technology-centric, developer-led SOA community that maintains a core focus on the similarities across industries, organizations, and products to achieve benefit". 

(In other words, an emphasis on standardization, and the one-size-fits-all economics of scale characteristic of the technology-centric approach, are complemented with an emphasis on business capability within a specific business context.) 

Enterprise architecture is then positioned as "a set of tools and techniques to link top-down business-led SOA to bottom-up developer-led SOA". Enterprise architecture becomes "a foundation for service-orienting an organization". 

(In other words, enterprise architecture is what puts the A into SOA.)

Technology-centric SOA already makes a clear distinction between the specification of a software service (sometimes known as the service contract), and the implementation and deployment of this service. Business-led SOA applies the same principle at the business level: "Defining business services allows an organization to differentiate between business capability, the fulfilment of business capability, and the consumption of business capability".

(In other words, enterprise architecture supports service-orienting the business, not just service-orienting the applications. Service-orienting the business doesn't just involve IT reengineering, and "justifying the cost of IT reengineering against business value", but also business reengineering.)

Is this enough? Is the glass half-full or half-empty? Some commentators are complaining that the business end of TOGAF is still disappointingly thin. But I prefer to see it as a move in the right direction. And I can see some promising openings here for the work we've been doing on alternative business models ...

---

Footnote

Business-led but technology-centric? See my post on Jargon Orienteering.

For further posts on TOGAF, browse the TOGAF label.

TOGAF 9

Released this week in San Diego, the long-awaited new version of TOGAF 9 - the Enterprise Architecture framework from the Open Group.

My first question was the extent to which TOGAF 9 addresses some of the SOA issues that have been overshadowing TOGAF 8 for over five years. I was particularly pleased to see the emphasis on Business-Led SOA (section 22.3).

In addition, there are some new or enhanced areas that look exciting.

• Architectural Partitioning- this abstracts away from the specific rows and columns of the Zachman matrix, while retaining the underlying principle of articulating different architectural views and domains in a systematic manner
  

• Business Capability Management - following the lead taken by the architectural frameworks of the defence world (DoDAF and MODAF), but applying a high-level concept of business capability to the civilian world. For example, the TOGAF guide points to the relevance of concept for governments in planning horizontal interoperability and shared services. Excellent.
  

• Content Framework. A generic reference framework for architectural deliverables.
  

• Enterprise Continuum. This concept was already present in TOGAF 8.1, but is now much clearer, for example in the way it talks about the general and the specific.
  

• Holistic Enterprise Change. This is mentioned as one of the benefits of TOGAF 9, but there is (as yet) little substance behind this. Clearly an area for further work.

This is clearly an enormous leap forward from TOGAF 8.1, but I haven't analyzed all the detail yet. Watch this space.

---

Early Commentary

Industry Analysts

• Beth Gold-Bernstein
  
• Sandy Kemsley
• Brenda Michelson

Vendors

• Wayne Horkan (Sun)
• Nick Malik (Microsoft)
• Ron Tolido (CapGemini)
  
• Mike Walker (Microsoft)