Arguing with Drucker

@sheldrake via @cybersal challenges Peter Drucker on the purpose of business.

"Peter Drucker asserted that the purpose of business is to create and keep a customer. He was right at the time in offering previously inward-looking firms a more appropriate beacon. His dictum is, however, wrong for our time."

Philip Sheldrake's challenge is based on two points.

1. A concern with the health and resilience of living systems such as organizations, society and the environment.

2. The need to recognize and understand complexity.


I completely agree with these points, but I do not think they contradict Drucker's original statement of purpose. As the webpage cited by Philip indicates, Drucker always called for a healthy balance - between short-term needs and long-term sustainability - and I think he would argue that a concern for resilience and the need to understand complexity were entailed by a customer-centric purpose.

Philip proposes an alternative purpose: Business exists to establish and drive mutual value creation. My problem with this alternative formulation is that it fails to answer Lenin's fundamental question: Who, Whom? There are businesses and business networks today whose purpose appears to be to mutually enrich a small number of mutually back-scratching executives at the expense of everyone else, including customers and retail shareholders. Drucker would not approve.

A statement of purpose is essentially an ethical statement (what is the value of the business) not an instrumental statement (what is needed to deliver this value). So let me propose an alternative ethic, a compromise between Drucker and Sheldrake, based on the wise saying of Hillel the Elder.


1. If a business is only for itself, what is it?
 (Expresses a concern for customers and society)

2. If a business is not for itself, who is for it?  
(Which may entail a concern for resilience and complexity)

3. If not now, when?  
(Expresses a concern for a balance between the present and the future)

---

Philip Sheldrake, What, exactly, is the purpose of business? An answer post-Drucker (April 2015)

Peter Drucker's Life and Legacy (Drucker Institute, retrieved 18 April 2015)

Wikipedia: Hillel the Elder, POSIWID, Who, Whom?


Related post: Organizational Intelligence After Drucker (August 2010) 

Design for Regulation

One source of complexity in organizational design is the requirement for various forms of regulation and governance. This requirement results in significant levels of bureaucracy and management overhead, as seen across much of the public sector as well as in many large commercial organizations.

It is tempting to think that much of this regulation and governance is redundant, and that such organizations would be far more efficient and effective if these layers of bureaucracy were eliminated. Of course that will sometimes be true, but it would be architecturally wrong to eliminate any specific regulatory mechanism without understanding the purpose and systemic effects of this mechanism. (The fallacy of eliminating things just because you don't understand why they're there is known as Chesterton's Fence. See my post on Low-Hanging Fruit.)

In general system terms, some form of regulation may be required to maintain integrity of structure and behaviour. The architect needs to understand the abstract need for regulation, without prejudging any specific mechanism or institutional solution. This understanding calls for the Cybernetic Viewpoint.

The Cybernetic Viewpoint allows us to consider the existence, purpose and style of regulation, while deferring the question of responsibility for regulation and its technical mechanisms.

There is a considerable debate about the proper style of regulation. There are many voices speaking for principles-based or performance-based or risk-based regulation, typically contrasted with rules-based or process-based regulation.  The need for precise specification and enforcement in a given situation may depend on the degree of trust.

The existence of some form of regulation may be inferred from some form of regularity in the structure and behaviour of a system, even if we don't always know the precise mechanism that produces this regularity. This inference may follow Stafford Beer's POSIWID principle - the Purpose Of a System Is What It Does.

Aside from the style of regulation, there is even greater debate as to the responsibility for regulation. There are emergent forms of regulation (such as market forces or consumer choice), collaborative forms (such as industry self-regulation), and institutional forms (such as independent regulatory bodies). We can identify four main categories as follows. (The labels for these categories are copied from the System-of-Systems world.)

• Directed regulation - central regulation by a single regulatory authority

• Acknowledged regulation - where there are multiple aspects of regulation handled by specialist regulatory bodies. 

• Collaborative regulation - where regulation is distributed around the ecosystem, such as self-regulation

• Virtual regulation - where a regulatory effect is produced by crowd behaviour, such as market forces

People often have strong preferences between these categories, partly based on political affiliation, and partly based on the degree of trust in the players.

To sum up, architects need to think about regulation both in abstract terms (where market forces, self-regulation and statutory procedures may be regarded as alternative and potentially interchangeable solutions to a common regulatory requirement) and in specific terms (where the implementation of a given regulatory instrument may have a significant impact on system and organization design).

---

John Kay, Regulation by Rules or Regulation by Values (Feb 2000)

Arnold Kling, Why We Need Principles-Based Regulation (American Enterprise Institute, May 2012) via EconLog

James Surowiecki, Parsing Paulson (New Yorker, April 2008)

Robert Teitelman, The paradoxes of rules-based regulation (Deal Economy, Sept 2011)

Perspective in Depth

As the systems thinking pioneer Gregory Bateson pointed out, there is an important difference between seeing with one eye and seeing with two. With monocular vision even the much prized Big Picture can be merely a flat and featureless panorama. Binocular vision affords a sense of depth and contour, and enhances the view.

When I wrote recently about the "What the Business Wants" viewpoint, Nick Gall challenged me to state whether I was referring to nominal purpose or defacto purpose (POSIWID). My answer was that the "What the Business Wants" viewpoint gave us a vantage point from which we could view both nominal purposes and defacto purposes at the same time, and appreciate the rich dependencies and contradictions between them.

So what happens when I apply the same thinking to the other five viewpoints? Each viewpoint has a monocular version (simple, linear) and a binocular version (rich, multi-dimensional). Here are a few key differences.

		Flat	Rounded	Links
Strategic View	What the Business Wants	Nominal purpose Nominal strategy	Defacto purpose Emergent strategy	Enterprise POSIWID
Capability View	How the Business Does	Operational capability Hard dependencies Top-down leadership	Sociotechnical capability and competency Soft dependencies Edge leadership
Activity View	What the Business Does	Linear synchronous process (value chain)	Asynchronous collaboration (value network)	Changing Conceptions of Business Process
Knowledge View	What the Business Knows	Formal information systems	Informal information systems Sensemaking Appreciative systems
Management View	How the Business Thinks	Goal-directed behaviour Management by objectives Single loop learning First order cybernetics (VSM)	Second-order cybernetics (Bateson/Maturana) Double-loop and deutero learning	Organizations as Brains
Organization View	What the Business Is	Enterprise	Business-as-a-Platform Ecosystem

But how should I label the two columns? Should I succumb to the temptation to label the first column "traditional"? Any suggestions?

Enterprise POSIWID

#bizarch #entarch #POSIWID As anyone knows who has attempted serious business and organizational transformation, an enterprise can be as stubborn as a teenager. Complex systems have strong feedback loops that maintain and restore the status quo against the most forceful and ingenious interventions.

One way of thinking about this challenge is to identify two distinct sets of purposes. On the one hand, there are the official intentions and plans of the leadership, which define what the purpose of the enterprise is supposed to be. We may call this the nominal purpose of the enterprise. Many enterprise architecture frameworks regard the nominal purposes as paramout, and are dedicated to realizing them. But on the other hand, the observed behaviour of the enterprise can best be explained in terms of an entirely different set of purposes, which repeatedly frustrate the official intentions and plans of the leadership. (See for example my post [Why New Systems Don't Work].) These are sometimes called defacto purpose; alternatively we can call it POSIWID, which stands for Stafford Beer's maxim that the Purpose Of a System Is What It Does. Large organizations and ecosystems are subject to inertia, and expensive initiatives often fall disappointingly short of expectations - this is the POSIWID effect at work. And of course there may be multiple conflicting defacto purposes [POSIWID should be plural].

POSIWID may also mean that there are covert purposes at work. Sometimes a corporate bureaucracy appears to be designed to make life difficult for employees and customers, as Tom Graves observes in relation to United's complaint resolution system [February 2010]; even if such a design is not consciously planned, it may be sustained by the short-term benefits it confers (such as cost-saving or corporate convenience).

Within enterprise architecture itself, we can perhaps distinguish between nominal purpose and defacto. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA [July 2008].
 
When TOGAF 9 introduced (but failed to explain) the term "Holistic Enterprise Change", I suggested it might 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 [February 2009].

By the way, Patrick Hoverstadt may well touch on some of these issues in his talk to the BCS Enterprise Architecture group in London next Thursday.

---

Tom Graves, Economics as enterprise architecture (March 2010)

POSIWID blog

EA Joke or Joker 2

I hope I made it clear in my previous post Enterprise Architect - Joke or Joker that I am not attacking all enterprise architects, or the concept of enterprise architecture (EA). I think there are many excellent practitioners of enterprise architecture, as well as some who don't deserve the job title at all.

In his latest post It's 2008: Is Enterprise Architecture Still a Joke?, James McGovern wants to talk about the value of EA, and I agree this is an important question. I think part of the reason why people sometimes see EA as a joke is because of the large gap between the potential value - what EA could theoretically be achieving in an ideal world - and the actual delivered value. In many organizations the actual delivered value of EA is disappointingly low. (James himself thought this was true of US Government in 2005; the title of his latest post hints that things may have gotten better).

There is not a single explanation for the disappointing results of EA in some organizations. Sometimes it is because the enterprise architects themselves aren't very good at the job; sometimes it is because the larger organization is resistant to some of the opportunities. Jeff Schneider's original post Why Enterprise Architecture is a Joke suggested some additional contributory causes.

Stafford Beer introduced the concept of POSIWID - the purpose of a system is what it does. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA.

Are people still playing Framework Bingo? Brenda Michelson suggests a quick poll: What does your enterprise architecture group deliver? (Go direct to poll)

• Standards and policies?
• Reference architecture?
• Proof of concept?
• Reference implementations?
• Business solutions?
• Forums or communities?
• Other?

(These different types of deliverable can be associated with different personality types or astrological symbols. In ancient Chinese symbolism, support networks and infrastructures are associated with Earth, rigorous conceptual frameworks can be associated with Metal, and actually building things is associated with Wood. Motivation is Fire and insight/inspiration is Water. Water feeds Wood, Wood feeds Fire, and so on.)

James argues that the goal of EA is to improve the quality of the IT ecosystem. Following something like the Goal-Question-Metric paradigm, this leads to specific measures via a set of questions. Here are some example questions extracted from James's post.

• Does federated identity enable better security for your business partners?
• What is the quality of source code within the enterprise?
• Is the enterprise architect participating in user group meetings that help propel the ecosystem forward? Are we working for interoperability across the industry?
• How well managed is the enterprise spend? How much money is being spent on compliance? Is this strategic investment being leveraged for other purposes?

But even if we can build a comprehensive measurement framework from such a collection of questions, this still leaves an important question - are we judging the success of enterprise architecture within an organization, or are we judging the success of the whole organization in using and leveraging enterprise architecture?

Of course similar questions apply to the architecture of buildings. Unfortunately, architects are sometimes more highly regarded for producing something that looks good in the architectural magazines, than for producing something that the client actually wants, or something that will evolve well.

The architects of past centuries whose buildings and names survive are not necessarily the ones who had the greatest ability, but those with reasonable ability who were fortunate in having the most supportive clients. Likewise, the most evidently successful enterprise architects will be those who are fortunate enough to be working in the most sympathetic and supportive organizations. But the enterprise architects who perhaps really deserve our praise are those who are working against the odds, achieving small victories in unsympathetic organizations.

Service Design and Culture

At the Tavistock Institute yesterday evening, to discuss some recent research on Service Design, presented by Paula Hyde based on her recent paper.

Paula Hyde & Huw Davies. Service Design, Culture and Performance: Collusion and Co-Production in Healthcare. Human Relations 57 (11). Available online until June 30

The immediate conclusions of the research (carried out in a mental health setting) was that attempts to improve service provision had largely failed, because although there were some surface changes in the organization, the fundamental relationships on which the service provision was based remained unaltered. There were some profound forces (explicable in terms of organizational psychology) that inhibited real change. [See also POSIWID post on Locking In].

During the discussion, several areas of healthcare and social care were mentioned where there appeared to be some conflict between the following service design objectives:

• to accord primacy to the service user in the design of the service
• to reduce the service user's dependency on (or abuse of) a given service
• to minimize various forms of risk (or uncertainty) to the service user, to the service provider, and to others
  
• to establish measurable improvements in service delivery (the dreaded targets)
  

Similar design conflicts can be found in some commercial settings, especially for services that are "unwanted", in the sense that companies would prefer not to have to provide these services, and the consumers would prefer not to need them. Many call centre operations deliver services that are unwanted in this sense, and these operations are often highly dysfunctional. [See my earlier post on Emergent Dysfunction.] Not so very different to the mental health systems described in the paper.