Representing the Enterprise

Enterprise IT is a social activity. With IT now a fundamental pillar of many business activities, sustainable business and IT initiatives require input from a diverse group of people. Communication and collaboration are key. Together, business stakeholders, subject matter experts, architects, developers and operational staff seek to create useful, executable representations of the enterprise.

As part of this undertaking, business and IT endeavour to refine a common or ubiquitous language, a set of useful conceptual and executable abstractions that lead to some desired business outcome. But it’s a difficult thing to do. Common languages don’t lie around waiting to be discovered, and they’re not easily invented.

Divided by a Common Language

It’s generally well understood that IT and business speak different languages, and that much IT-business misalignment results from the two sides speaking past one another. Jon Collins et al, authors of The Technology Garden, suggest that to solve this problem, both parties must build bridges between general purpose IT and business languages, and between a general purpose IT language and individual business specialisms.

What is perhaps less well understood is how enterprise IT initiatives can suffer when one side tries in good faith to build these very bridges, only to end up speaking a cobbled together version of the other’s language. Business speaks folk IT; IT suffers from acute business process disorder.

Do You Speak Folk IT?

Collins and co make the important point that because IT is now fundamental to many businesses, it’s imperative that business leaders know something of IT. Unfortunately, the business’ IT terminology all too often muddies our attempts to understand an organisation’s business goals and the things it does to meet those goals. I call this habit of describing business problems in terms of vaguely understood technology artefacts folk IT.

Folk IT highlights the fact that in many places, IT terminology has infiltrated business language to such an extent that it all but constitutes the business’ everyday view of itself. We talk of databases rather than meaningful business entities, workflows and rules engines instead of the activities, interactions, events and information exchanges through which an organisation realises its goals. When a head of department describes order fulfilment activities in terms of entering customer records and line item codes into a database, sending files to a Web service gateway, and copying transaction identifiers from one system to another, is it no wonder that a technical integration solution to this folk IT description of the problem results in yet another brittle wiring up of system artefacts with questionably little long-term value to the business?

Folk IT subtly influences how we describe a problem and a solution. Its representations often seem obvious and natural, yet they’re not always terribly insightful or useful. At their worst, they distract us from creating other, potentially more useful kinds of representation. There can be no doubt that it’s worth understanding and explaining the impact of today’s IT enables on an organisation’s operating model. But no matter the efficacy of the incumbent technology, an IT-centric explanation of the business serves as a poor foundation for describing the future. By describing tomorrow’s outcomes in terms of an elaboration of today’s IT, we end up limiting what can be thought and achieved. Folk IT is like a bad habit: business and technology experience the satisfaction of speaking a common language; thereafter, distracted by seeming agreement, they refrain from talking in some more useful way of the forces, constraints and outcomes that define a business problem.

Business speaks folk IT for a couple of reasons. For one thing, history has taught it to worry over operational issues. At the same time, it has witnessed the increasing virtualisation of the business space.

If IT can’t get the basics right, and keeps telling you that your Web site fails because of database issues, you’re going to worry about databases. Soon, you’re going to be talking about nothing but databases, asking questions about databases, and specifying the database requirements for the relaunch of your site. But in most use cases, databases are a low-level implementation detail, not a determinant of novel business outcomes. All that time spent describing the characteristics of a good database hasn’t left much time for thinking strategically about how IT investment can support a radically new business model.

Even as IT fails to deliver, we find ourselves handing over ever-greater swathes of business materiality to the virtual void. Before the rise of the digital marketplace, much of the stuff of business had a healthy solidity to it. For old-school IT, there were usually concrete things to point at, documents to inspect, paper trails to follow, people to shadow. Business language talked about business-meaningful things that you could see and touch (see Dan North’s resurrection of a 1950’s office). Nowadays large parts of even the most bricks-and-mortar business have been virtualised. To make sense of business, it seems natural to talk about the things that host the now immaterial parts of the business: the systems, files and databases wherein are housed what cannot be seen. The already-virtualised world of business makes folk IT the natural language of the unseen. But when we speak folk IT, we constrain how we represent the future.

All You Process Are Belong To Us

While business unwittingly attempts to bridge the business-IT gulf by adopting folk IT languages, IT clumsily attempts the passage in the other direction by speaking a narrowly focussed business process language. Influenced by process-oriented business methodologies, business analysts, enterprise and solution architects seek to reduce the business space to a set of structured, ordered, measurable steps. Everything is seen through the lens of the “process”. IT suffers from a repetition compulsion, from business process disorder.

When folk IT meets business process disorder, everybody comes off badly. Business stakeholders and end users tell a bewildering story made up of contingent system interactions, which the interpreter then dutifully transcribes into a convoluted and fragile business process workflow. If the parties don’t step back from the brink, refocus on outcomes and benefits and change the conversation, the “to be” state runs the risk of being nothing more than a mechanical elaboration of the “as is” state.

Oddly enough, business people rarely talk of business processes. “Business process” is a term used by theory builders to impose order on an ad hoc welter of business-meaningful stuff. Business process analysis is as much an act of invention as it is of discovery. Some would go so far as to say: “business processes don’t exist. They’re a myth. An ancient ideal at best.”

Fiction or fact? I’m not convinced it’s an either/or choice. To my mind, business process disorder arises in response to a legitimate imperative to control and tune the business space: it’s a manifestation of a structural desire to impose stability and identity on everything that is unplanned, informal or changing about the business landscape. The engine of business will always drive us to bring things under control, promote the efficient, dispose of the inefficient, and tune the remainder. To try and make of something a “business process” is an understandable act or gesture given these high-level imperatives. Whether we call it business process analysis or not, we are motivated to coerce the stuff of business into a coherent narrative using models and automation.

Given these intractable imperatives, how might we better respond to them?

Speaking Differently

If business process disorder is an inelegant response to a legitimate concern, then it’s time to speak differently. The need to control and tune the business environment is subordinate to what it is the business is trying to achieve, and to the benefits associated with the business’ goals. The bridge between business and IT languages must emphasise these goals and benefits.

Business capability analysis is one such attempt at aligning business and IT languages around explicit business outcomes. Capability analysis represents the business in terms of desired outcomes. It then identifies the capabilities a business must possess in order to satisfy those outcomes, and the activities that support each capability.

Business capability conversations are quite different from business process conversations. Cutting through the folk IT obsession with how something is done, they emphasise instead the desired outcomes that motivate an initiative. A business capability bridging language clearly separates the what from the how. What is the business trying to achieve? What capabilities must it possess to achieve its goals? Only after having answered those questions can we more usefully ask: how does the organisation implement and coordinate its capabilities today, and how might it do so in the future?

Capabilities provide a useful abstraction over the hoary old cornerstones of process reengineering – the people, process and technology foundations of an organisation’s operating model. This additional layer of abstraction makes business capabilities far less volatile than the implementations of the activities that support them. The capability to haul production from a well to a refinery is of continuing importance to a midstream oil company, irrespective of changes to that company’s fleet or to the systems that measure and analyse the production at either end. Because of this relative stability, capability-based representations of an organisation provide a robust framework from which to hang appropriate architectural and implementation decisions.

A capability approach stops us from stifling the business with a barrage of rigid business process descriptions. As opposed to processes, capabilities and activities have wildly varying characteristics. Some capabilities are commoditised and non-differentiating; others are proprietary and grant significant competitive advantage. Some activities are stable and predictable; they proceed step-by-step, and resist innovation. Others are dynamic, ad hoc, context-sensitive and serendipitous.

Accounting, for example, is a commoditised, non-differentiating capability. Accounting activities are not prone to innovation: in fact, regulatory forces such as SOX expressly curtail the degree to which organisations can innovate their accounting activities. The capability to inventory products is likewise a relatively well-understood, non-volatile, non-differentiating business capability. However, the capability to monetise products and product combinations in the context of an individual’s interests and prior behaviour is potentially a significant differentiating factor, and one that will likely require constant innovation and reinvention in response to competitor activities.

Capability analysis is a significant advance in the attempt to bridge business and IT languages. Capabilities focus everybody on what it is they’re trying to achieve and what they need to meet those goals. They facilitate ease of communication between stakeholders, and reduce the risk of business-IT misalignment, restoring to the business some of the control and ownership of a solution that might otherwise be denied by focussing upfront on technical or architectural issues.


  • Communication and collaboration are key to successful business-IT initiatives. Communication depends on the modes of representation available to the collaborators. Representation shapes delivery.
  • Technology, architecture and business-orientation biases influence the way in which IT engages with the business and delivers its needs.
  • Some attempts to create a common language between business and IT founder because of well intentioned but clumsy attempts to adopt idioms from the other side’s language: the business adopts IT slang to describe what it does; IT creates a brittle and contingent assembly of business process steps.
  • Languages that emphasise desired outcomes and business capabilities provide a more nuanced way of bridging the business-IT divide and representing the enterprise.