Enterprise Architecture as Viable System

#entarch #ea2010 @uoaeao tweeted

"The most immediate and effective way to reduce costs is to use #entarch to stop or delay projects that are spending money."

My first thought was that using enterprise architecture for this purpose wasn't likely to be the fastest way to stop projects. Surely the most immediate and effective way to reduce costs is to stop projects, period.

In response to this, @uoaeao explained that

"#entarch adds value here identifying *which* projects should/can be stopped or delayed without intolerable business impact".

I wonder what EA process is required to provide a professional answer to this question, and how long it is likely to take. There are at least three possibilities.

• The EA team has already done this analysis, possesses all the necessary models and information, and is just waiting for someone to ask the right question.

• The EA team comprehensively analyses the new situation, runs strategy planning workshops with senior management, produces a revised set of architectures and strategic project plans. 

• The EA team does a quick and dirty exercise to protect its favourite projects. 

The dilemma for EA in this kind of situation is clear - how to appear useful in a crisis without (a) throwing all the EA professional discipline out of the window or (b) demanding at least four months to carry out a proper study.

Meanwhile, I wonder what makes this an enterprise architecture task rather than a programme management or risk management task. What is specifically architectural about checking alternative plans for "intolerable business impact"? If we were to observe the EA team responding to this kind of demand, how much of the activity and expertise could be described as "architectural"?

Discussions about the contribution of enterprise architecture to the enterprise often highlight one or more of the following four elements

• Vision and forward planning
• Intelligence and optimization (e.g. just enough complexity)
• Resource allocation
• Coordination (interoperability, standards)

Stopping or delaying projects is essentially a resource allocation task.

As followers of Stafford Beer may recognize, these elements roughly correspond to Systems 2-5 of the Viable Systems Model. Applying VSM to EA produces the following demands and challenges.

• A complete account of enterprise architecture needs to cover all four elements identified above (Systems 2-5), and also explain how they are connected. 

• Given that various other disciplines (including design thinking, organizational intelligence, programme management, risk management and scenario planning) also claim to address some or all of these elements, explain how enterprise architecture collaborates with (or incorporates) these other disciplines.

---

A number of my friends have one foot in the systems thinking world (including VSM) and one foot in the enterprise architecture world. We are looking to organize something early in 2011, probably in London. Please contact me (e.g. via Linked-In) if you're interested.

What have software executives ever done for us?

@JohnSchlesinger asks What has the enterprise architect ever done for us? (@AtosOriginBlog, November 2010)

John criticizes the IBM strategy in the late 1980s, especially the emphasis on Systems Application Architecture (SAA) and the neglect of CICS and IMS (John himself was a CICS developer at IBM Hursley), and hints that enterprise architecture could have saved them. He believes that IBM executives failed to understand computing properly because their own experience was limited to personal productivity and communication applications.

There were people at that time who were doing things we'd now label as enterprise architecture, within IBM and elsewhere, but these were often the very people who were building SAA. If IBM had had a full enterprise architecture function at that time, surely its role would have been far more than what John characterizes as a typical task of enterprise archiecture: "putting together the enterprise applications so that they completely implement the value chain and maximise its straight through processing rate".

John attributes the failure of the IBM strategy to ignorance among IBM executives of what he calls "enterprise applications" But I think it makes more sense to attribute this failure to ignorance among IBM's customers, and to IBM's failure to communicate the advantages of SAA to its customers. The people in the customers who would have been most likely to understand the potential advantages of SAA would have been enterprise architects, if these had existed in those days; IBM's error was to build a product for which the market didn't yet exist.

John also blames Earl Wheeler (or possibly his staff) for basing SAA on using screen-scraping as a connection mechanism, and for suppressing technical debate about this. Clearly a preference for screen-scraping is an act of technical architecture rather than business architecture. But there may have been all sorts of political reasons for this preference, so we cannot conclude that it was reached out of pure technical ignorance, Indeed, the refusal (by Wheeler's staff) to allow John to speak at a vendor conference reinforces my suspicion that it was a political decision rather than a technical one.

Looking on the Internet to find out more about Earl Wheeler, I found instead a criticism of Lou Gerstner from 1994, which made two interesting statements.

‘He proceeded to deliver a pitch which sounded ominously close to Earl Wheeler’s SAA (Systems Application Architecture). ‘

‘The “techie” tone of the speech also suggested that it was written by someone with an engineering and/or manufacturing mentality, not by a “business architect.” ‘

[A "Play-by-Play" Analysis of Gerstner's Six Strategic Initiatives (Annex Bulletin, March 1994)]

However, today’s enterprise architecture practice has been significantly influenced by a body of work carried out at IBM and elsewhere, including the construction of artefacts like SAA, and the prevailing understanding of the relationship between business architecture and technical architecture is still dominated by the work of ex-IBM people like James Martin and John Zachman.

Clearly my friend John Schlesinger has far better ways of integrating enterprise applications these days, but obviously that's not all there is to enterprise architecture.

Organizational architect as fixer

In his post Hire An Architect, Seth Godin thinks of the organizational architect as a kind of fixer.

"Organizational architects know how to find suppliers, use the cloud (of people, of data, of resources), identify freelancers, tie together disparate resources and weave them into a business that scales. You either need to become one or hire one. The organizations that matter are busy being run by people who figure out what to do next."

You can now buy a lot of the stuff you once had to build.

"It used to be that if you wanted to build an organization, you had to be prepared to do a lot of manufacturing and assembly--of something. My first internet company had 60 or 70 people at its peak... and today, you could run the same organization with six people. The rest? They were busy building an infrastructure that now exists."

Of course this trend exists in IT as well as in other aspects of infrastructure. As more of the IT requirements of the modern enterprise can be satisfied by packages and cloud, the emphasis shifts from overseeing development to overseeing procurement.

Thus the architecting and procurement of IT is becoming increasingly similar to the architecting and procurement of other aspects of the organization's infrastructure.

Who does this job? (See my post Who Architects The Organization?) The implication of Seth Godin's portrayal of the organizational architect is that this is may be an experienced dealer/manager rather than a technical expert. We may note that venture capitalists often bring in experienced managers as CEO or COO to complement a technically brilliant but managerially inexperienced venture. Thus it was venture capitalists who persuaded Larry Page and Sergey Brin, the founders of Google, to recruit a much older and more experienced CEO - Eric Schmidt. According to Google's website, Eric Schmidt focuses on "building the corporate infrastructure needed to maintain Google's rapid growth as a company and on ensuring that quality remains high while product development cycle times are kept to a minimum" (via Wikipedia). That sounds to me a lot like enterprise architecture.

Requisite Collaboration

My blogpost on The Startling Cost of Inefficient Collaboration started from the observation that "too much collaboration can be bad". But how much is too much?

Too Little

Barely Enough

Just Right

More Than Enough

Too Much

We often need to make a judgement about the appropriate quantity and quality of something. Such judgements can be difficult ones, because they need to be sensitive to who, why and where. Even something as basic as the right amount of food will vary between members of the same family and at different times. And there is no simple formula that will tell you whether to spend more time preparing for tomorrow's meeting or to get an early night.


So how much is a good amount of collaboration - just enough but not too much? Obviously this depends on many situational factors including purpose and context. We can talk about requisite collaboration - in other words, the quantity and quality of collaboration that is appropriate for a given situation. And although we should not expect a simple formula, this is nonetheless something we should expect to be able to reason about.


It's also important to remember that the quantity and quality of collaboration is not necessarily under the control of a single stakeholder. People who work in large organizations may be able to initiate some meetings and duck out of others, and may sometimes be able to unplug phones and ignore email (although many people experience guilt or anxiety when they do this), but the actual quantity of collaboration emerges from the interaction with everyone else. The bosses at Lehman Brothers had elaborate routines to prevent ordinary staff talking to them, and some commentators (e.g. @markfidelman What if Peter Drucker Taught Enterprise 2.0?) have suggested this could have contributed to the collapse of the firm, but I'm sure even Lehman bosses couldn't cut themselves off completely from urgent demands from important stakeholders.


So Lehman bosses may sometimes have had more communication with other people than they felt they wanted at the time, but with hindsight even they might admit that they didn't have enough of the right kind of communication. Such a judgement is always relative to a particular stakeholder position - other people such as junior staff or minor customers might complain that Lehman bosses didn't listen to them, but to put this complaint in terms of requisite collaboration would be to imply that Lehman bosses didn't do enough listening to serve their own interests and the interests of the firm as a whole.

In some domains, there is a body of knowledge that may help us to determine the right level of collaboration. For example, John Gattorna uses the concept of requisite collaboration within enterprise supply chains, suggesting that collaboration makes sense only with those who truly want to collaborate. (See John Gattorna, Supply Chain Collaboration, Supply Chain Digest June 2007. See also review of Dynamic Supply Chain Alignment by Jan Husdal.)

In any case, we need some whole-of-context view to determine the requisite level of collaboration, as my friend @tetradian points out. For Lehman Brothers, inadequate collaboration led to inadequate organizational intelligence, which led to organization failure. The organizational intelligence methodology should help us think about the appropriate collaboration levels of different scenarios by working backwards from the consequences.

The Startling Cost of Inefficient Collaboration

@BillIves @tetradian and @gagan_s point to some recently published research suggesting that "collaboration can exact heavy time costs if done inefficiently" [MIT Sloan November 2010]. Yes indeed, that is what the word "inefficiently" usually means. Specious arguments and poor journalism says @flowchainsensei; @tetradian agrees about the poor journalism but thinks there is a valid point about whole-of-context cost of collaboration.

The researchers measured the time cost of collaboration in terms of the amount of time people spend preparing for and engaging in collaboration with others. Undoubtedly there is considerable variation in the amount of time people devote to these activities, and also considerable variation in the benefits gained from these activities. In many situations there will be a trade-off between the amount of preparation and the effectiveness of the collaboration - poorly prepared people may not be able to collaborate effectively - and obviously the greater the number of people involved in a collaboration, the greater the cost of wasting people's time as a result of poor preparation.

If we want to know the efficiency of a particular activity, then we need to have a measure of output as well as input. It may be an interesting observation that some project managers devote more time to collaboration, and consume more collaboration time from their team members, but in order to draw useful conclusions about collaboration efficiency, either we must assume that all project managers ought to need exactly the same quantity of communication, or we must have some way of linking collaboration with the overall performance of the team. After all, there are some working practices requiring high quantities of collaboration, such as pair programming, that are thought to be associated with high levels of overall productivity, so we shouldn't always regard collaboration time as an unnecessary cost. I don't need researchers to tell me too much is too much; what I want to know is how much is too much, in other words some notion of requisite collaboration.

The researchers think "it is important to reduce network connectivity at points where collaboration fails to produce sufficient value". Well yes obviously, but the critical question is how to assess the value of collaboration in the first place. See my post on Collaboration Impact Zones.

Visual Cliché in Architectural Discourse

@JohnCleese has made some great management training films, published by his company Video Arts. In the one I remember most vividly, he mocked the compulsive need for visual aids in corporate presentations by imagining what Hamlet's soliloquy would be like with slides. I just hope there isn't an excessively clever software engineer in the Powerpoint group at Microsoft working out a way to pick out the key words in a portion of text ("slings", "arrows") and paste in appropriate clipart automatically.

Architects are perhaps more fond than other people of the picture-tells-a-thousand-words principle, and some of them link this principle with what they call "right-brain" thinking, whatever that means. So surely we must be entitled to have high expectations of the power and clarity of diagrams in an architect's slide presentation?

Sadly, the visual language of architectural discourse, from enterprise to software, is surprisingly weak. Many diagrams look as if they may have started as meaningful sentences, but they have been transformed into diagrams by discarding most of the words and putting the remaining words into coloured shapes, arranged artistically on the page. This might give the audience something to stare at while the presenter is talking, but it's often difficult to see what such a diagram communicates over and above the words. There are some arrangements that I find particularly puzzling, and therefore distracting, because they hint vaguely at some logical or structural significance, and I am left wondering what exactly this diagram is trying to tell me.

The Venn Diagram

A popular graphic involves three words written in overlapping circles - for example "people", "process", "technology". Most people are familiar with the use of the Venn diagram in elementary set theory - this is nowadays taught in primary school. But in Powerpoint-ese, this graphic seems to mean either "here are three disparate things that might have to be considered together" or "here are three topics I'm going to talk about separately" and it's probably not worth trying to interpret the semantics of the diagram in terms of set theory.

If we compare a faux Venn diagram containing the words "people", "process", "technology" with a slide containing the same three words as bullet points, it is difficult to see how any additional meaning is conveyed by the diagram.

as if People Mattered

In order to show that architecture involves people, diagrams are decorated with little pictures of people that look as if they have been cut out of a magazine. Or even worse, the same set of cartoons we've seen hundreds of times before. The inclusion of these pictures seems to be little more than a token gesture to human-centred architecture, in the same way that corporate brochures often contain pictures of models (male and female) pretending to be office workers.

There is of course nothing wrong with including pictures of people in your presentation, but it becomes a cliché if the pictures are arbitrary or inauthentic, picked at random from a collection of clipart or stock photos. I've even seen presentations that were trying to tell a story involving different roles, where a small number of stock pictures were reused inconsistently from one slide to the next. (In one slide there's a picture of a black woman representing the programmer, in the next slide the same black woman represents the project manager, and by the end of the presentation she's been promoted to CEO. Is this intended to give me a rosy impression of the company's diversity policies, or is it just careless presentation design?)

This is not just an issue for enterprise architects - the people who design buildings suffer from the same tendency. See my post What if architects designed our communities?

---

I have myself become somewhat disillusioned with the picture-tells-a-thousand-words principle. I have sat through many presentations, as well as presenting material developed by other people, and been frequently frustrated by poor visual language. And I have myself produced many presentations containing many diagrams; I freely admit that some of these diagrams have been more successful than others, and I haven't always managed to avoid visual cliché. But at least I'm trying.

---

Update: In the new production of Don Giovanni at the ENO, Leporello uses a slide presentation to narrate his master's conquests [Classical Source]. But who would want to emulate Leporello?

Strategy by Design

Great tweet from @judyrees this morning. "Metaphor can create powerful insights that become distortions, as the way of seeing created through metaphor becomes a way of not seeing."

When people talk about the "alignment" or "gap" between business and technology, is this just a rhetorical metaphor, or is it supposed to have a literal meaning?

I can easily understand the concepts of "alignment" and "gap" when we are talking about similar things in the same space. For example, there is a gap between my house and the house next door, and both are roughly aligned with the houses opposite. I understand what these terms mean geometrically (literally "earth-measurement") and could measure them to a reasonable degree of accuracy.

However, if someone started to talk about the "alignment" between his love life and the works of Shakespeare, I could only really make sense of this as an interesting metaphor. It would be absurd to try and measure this kind of alignment using geometrical instruments.

In order to take the notion of business-IT alignment seriously (i.e. as more than just a metaphor), we have to have some way of understanding "business" and IT" to be similar objects within the same kind of space. One possible way of doing this would be to define a distance relationship between the IT department and other parts of the organization, in terms of the interaction and coordination between separate organization units. As it happens, I did some work in the 1990s on enterprise modelling, where we experimented with the notion of "interaction distance", although I think I'd now call this "collaboration distance".

This is perhaps what is implied in a recent Strategy+Business article, which identified enterprise architecture as a way of "closing the distance between IT departments and business units" [Hugo Trepant and Daniel Newman, Strategy by Design, August 2010, via @andrewtuson].

The notion of collaboration distance can also be used to help understand the degree of alignment or misalignment between separate business organizations in the context of a complex business relationship - for example the relationship between Ford and Firestone. (See my post on Supplier Abuse.)

An alternative interpretation comes from George Ambler (@CIOLeader) who suggests that "it is the mindset gap between biz and IT that's the biggest gap of all". To interpret this literally, one would need a way of measuring the distance between two mindsets, and comparing distances between three, but at least we are talking here about notional alignments and gaps between instances of a common class.

Where I have greatest problems with the notion of business-IT alignment is where "business" and "IT" are spoken of as complex wholes apparently occupying completely different spaces. Of course, one possible tactic for enterprise architects is to produce a simplified representation of "business" and a simplified representation of "IT" within a chosen EA framework or modelling language, and then to define "alignment" in terms of some congruence relationship between the two representations. But we should be both surprised and deeply unimpressed if enterprise architecture were unable to manufacture this kind of simplified alignment, and we should be wary of circular arguments that promote the value and validity of these frameworks in terms of alignment while simultaneously defining alignment in terms of these frameworks.

Finally, I want to draw attention to a significant weakness in current enterprise architecture thinking and practice. Despite the constant rhetoric of alignment, the models and frameworks in common use provide no basis for reasoning about alignment, with all its costs and complexities. Enterprise architects profess to understand structure, but there are some important aspects of structure that are generally not addressed.

Collaboration Impact Zones

In my previous post Collaboration Chasm, I looked at the adoption of collaboration technology in the enterprise, drawing on Collaboration Framework published by the CISCO community earlier this year [Insights from the Collaboration Consortium Year One]. In this post, I'm going to explore the CISCO concept of Impact Zones.

CISCO starts from the idea that the greatest payoff from an investment in collaboration comes where people and content intersect - whether in real time, asynchronously, or both. CISCO looks at three aspects of collaboration: interaction, expertise and information. Interaction includes in-person meetings, phone conversations and project teams; expertise includes tacit or professional knowledge, such as an executive, knowledge worker, or specialist might have; and information includes that found in databases, working documents, and archives. “Collaboration impact zones” are those junctures where interactions and the exchange of expertise and information are frequent, urgent, and complex: these may be focused on either internal or external collaboration. CISCO believes that identifying these zones helps an organization focus on the right areas of collaboration to ensure that the financial return of collaboration is greater that the associated opportunity and collaboration costs.

The CISCO definition of collaboration impact zone uses the present tense, and so appears to refer to the AS-IS model of the enterprise. But if we take this too literally, it might lead an organization to invest in those areas where excessive collaboration is already taking place today, instead of those areas where collaboration is weak.

Here's an example. Many organizations have the most intense and angry exchanges with the customers after something has gone wrong: John Seddon calls this failure demand, and points out the stupidity of focusing on managing customer complaints more efficiently, when it would be far better to focus on preventing the things that the customers are complaining about.

However, the examples cited in the CISCO community document don't fit the literal definition of collaboration impact zones. Instead, the investment is apparently focused not on areas where the collaboration is already frequent, urgent and complex, but where collaboration is both insufficient (not enough interaction and expertise where it is needed) and expensive (even limited interaction and delayed expertise incurring significant travel costs). In these examples, the business benefits come from building a platform to support frequent, urgent, complex and affordable collaboration. "Both companies identified part of a business process in which a high concentration of interaction, expertise, and information is required to deliver the business process outputs ... the collaboration tools are adapted to the requirements of the collaboration impact zones." "An organization can begin the process of identifying its impact zones by developing hypotheses about what parts of the processes need performance improvements, then taking “deeper dives” to validate whether collaboration at those points can drive business value." Thus it is in the TO-BE model where we need to look for the collaboration impact zones, not in the AS-IS model. (Which of course raises the question where the TO-BE model comes from.)

But we should also note another possibility. AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place. This method is also used for detecting inappropriate collusion between systems that are supposed to be completely independent.

This in turn suggests another way of thinking about collaboration impact zones - they may be anywhere where there is something problematic about the collaboration that may or may not be taking place. For example, there may be some interactions that are not particularly frequent or urgent or complex, and are not expensive to transact, but need to be controlled for some reason - perhaps to eliminate risk or fraud, or to guarantee compliance with some critical requirement, or just to make them visible and available because managers like things that way. ("This call may be recorded for training purposes.") There will also be collaborations whose participants wish to avoid control and interference by management, for whatever reason. So the identification of these zones is going to raise a lot of issues.

The Power and the Glory

#entarch A debate on Twitter about the power of enterprise architects (enhancing? enabling? influencing?), and another debate about the relationship between architecture and knowledge (does architecture count as a form of knowledge?) led to a question from @StevenvtVeld "An architecture as influencer? Closer to view, knowledge: how can this be an influencer?"

There are several ways in which knowledge influences what goes on.

• People and organizations perceive, interpret and evaluate the world according to their prior knowledge. The implications of this have been extensively explored by philosophers (Kant onwards), psychologists (Piaget) and systems scientists (Maturana and Varela).

• People and organizations decide and act according to their assessment of the likely outcomes and risks of the options they are aware of, based on their prior knowledge and understanding of causes and effects. (This may include conscious rationalization as well as unconscious or unspoken patterns of thought.)

• People and organizations learn selectively from experience. Theories and beliefs tend to be "sticky", they are not necessarily abandoned as soon as contrary evidence appears. Because present experience only slowly and imperfectly feeds into future knowledge, current behaviour is largely influenced by past knowledge.

• Within organizations, people attempt to control flows of knowledge for political advantage. This is sometimes known as a gatekeeper function.

• Closed systems of knowledge (sometimes called a discourse or discursive practice) may be elevated to a dominant status within an organization culture. For example, the accounting discourse has a dominant status in many commercial organizations, while the target-setting discourse has become dominant in the public sector. Arguments based on the dominant discourse typically bias the organization towards certain ways of solving problems, and make some kinds of innovation impossible. (See my post on Making Conversations Visible.)

Enterprise architects need to work with knowledge at two different logical levels - not only participating in the development and good use of relevant forms of knowledge (on architecture and related subjects) but also understanding and facilitating the structural and cultural aspects of knowledge development and use across the enterprise.

---

By the way, Graham Greene's novel The Power and the Glory was published in the USA as The Labyrinthine Ways. It is said to be one of President Obama's favourite books. Perhaps there is a hidden message in it for enterprise architects: I'd better read it sometime.