Same and different

Just how much is enterprise-architecture about the balance between same and different? Quite a lot, it seems to me…

(In part this is a follow-on to ‘The theory of enterprise-architecture‘, about exploring the theoretical base that underpins a whole-enterprise approach to EA; and also the problems with Taylorism and the linear-paradigm, as highlighted in that multipart series onno jobs for generalists‘.)

Within the architecture of an enterprise, sometimes there are huge pressures to try to force everything to be the same, and to ignore or deny anything that’s different. At other times, or in other contexts, there are huge pressures to focus on difference, leading to a tendency to ignore useful ‘samenesses’.

Worse, there’s often a tendency in business and elsewhere to flit from one side to the other, without noticing or understanding the differences in approach that each would need. This leads in turn to attempts to use tactics and techniques that are inappropriate to the actual requirements or actual tasks at hand. Which, unsurprisingly, can lead to a clunky, chaotic, expensive mess – sometimes of truly epic proportions.

It’s therefore essential in enterprise-architecture to develop a solid understanding about:

  • what is ‘same’, and what is ‘different’, in any given context
  • what needs to be ‘same’ or ‘different’ – which is often not the same as what is
  • techniques to distinguish between ‘same’ and ‘different’, and to identify the respective advantages and disadvantages of each within each context
  • techniques to identify what kind of balance is needed between ‘same’ and ‘different’ in each context
  • techniques to work with the respective ‘same’ and ‘different’ in each context

Some examples to play with:

  • Structured versus unstructured data

‘Structured’ data is data that has been placed into a structure of ‘sameness’ in order to provide a standardised frame for and of information; ‘unstructured’ data is raw proto-information without any pre-interpretation via imposed structure.

The advantages of structure include that it allows like-for-like comparison and aggregation.

The disadvantage is that it leads to a tendency to try to force-fit all data into the structure, distorting or ignoring any data that won’t fit the structure.

There’s also a significant risk that the structure itself will somehow attain higher priority than the data carried within the structure, leading to demand for conformance to the structure – enforced ‘sameness’ – that causes a disconnect with real-world complexity.

In reality, structure is always a somewhat-arbitrary overlay on data, and ultimately all data is ‘unstructured’: if we ever forget those facts, we’re likely to create serious problems for the enterprise.

  • Repeatability in processes

Sigurd Rinde draws a useful distinction between ERP (Easily Repeatable Processes – high ‘sameness’) versus BRP (Barely Repeatable Processes – high ‘difference’). Repeatable processes are amenable to simple forms of automation; barely-repeatable processes can be automated only incompletely, and only via means that respect and work with the inherent (and usually human) complexity of the context.

In applying popular Taylorist-type techniques such as Six Sigma and automation-oriented Business Process Reeingineering, it’s often forgotten that they require almost perfect identicality of process – literally in the millions, for Six Sigma. There’s therefore a real risk of a tendency to try to force-fit everything to fit the standard process, whether or not it’s appropriate to do so – or worse, to simply ignore anything that doesn’t fit. As with data, whenever the structure takes priority over the actual need, this leads to serious problems for the enterprise.

  • Proprietary versus standards

Standards represent ‘sameness’; proprietary is ‘different’. This is an age-old trade-off in every industry, often complicated by carelessness or by commercial desire for differentiation.

The advantage of standards is that they enable interoperability and substitutability. To give a military example, munitions for early naval cannons were different not just for every type but for every unit: stone cannon-balls on the Mary Rose were shaped by hand to fit the respective cannon before firing; standardisation of firearms is also said to have played a major part in the eventual success of the North in the American Civil War.

The disadvantage of standardisation is that it can lead to sub-optimisation for a given context, and, again, the same problems of ‘force-fit’ and inadvertent exclusion as described for structured-data above. There can also be strong apparent commercial advantages from intentionally rejecting or even sabotaging standardisation or existing industry-standards, so as to create or reinforce ‘vendor lock-in’.

In enterprise-architecture there’s a common desire to define and enforce standards across the whole scope, to enhance interoperability and suchlike. It’s essential to understand that these attempts risk significant ‘pushback’, and even failure of the architecture, if there is not enough awareness and respect of the business-reasons and other drivers that inherently push towards ‘the different’.

  • Commodity versus ‘unique selling proposition’

Differentiation is also crucial in many – most? – business-models. A business-model that cannot offer a value-proposition that is in some way ‘different’, or unique, will risk being placed as an ‘also-ran’ commodity-provider – for which often the only competitive option that remains is entrapment in a self-defeating ‘race to the bottom’.

However, if the differentiation is too extreme, the business-model is at risk from lack of market-adoption, as there is no reference-point on which comparisons can be made. The issues of interoperability as above also apply here: a product or service that is totally ‘non-standard’ may in practice be seen as almost unusable because of its lack of interoperability or substitutability. Excessive differentiation across an industry may also trigger enforcement of standardisation via regulation: one example is the European Union’s insistence that handset-manufacturers should conform to USB standards for handset chargers, to reduce the chaos and resource-wastage from every handset-type requiring its own unique charger.

For architects, standardisation would probably be the natural default, so there’s also a strong need here to be aware of why differentiation might be sought in each case, and to respect and support it wherever necessary.

  • Waterfall versus Agile

In change-governance, Waterfall emphasises ‘sameness’ in the sense that there’s an assumption that things will remain the same throughout the project-timeline; Agile is based on assumption of ‘different’, that detailed-requirements will emerge from the development-process itself.

Both types of approach are valid, for the appropriate contexts: the architectural challenge is to identify which approach is appropriate for each given context, and to support ‘meta-governance’ that can guide switching between approaches according to the actual (and often dynamic) requirements of the context.

  • Backbone versus edge

‘Single source of truth’ and other standardisation (‘sameness’) versus ‘shadow-IT’ (local ‘difference’) is another related theme to ‘Waterfall versus Agile’. It’s also a common driver for the dreaded ‘business/IT divide’ – where ‘the business’ tends to push for context-specific differentiation, whilst IT pushes for standards and shared-services.

I’ve explored aspect of this theme several times on this weblog: see, for example, the posts ‘Architecting the enterprise backbone‘ and ‘Backbone and business-rules‘.

  • Best-practice versus worst-practice

‘Best-practice’ and ‘worst-practice’ represent different approaches to the use of patterns in enterprise design. The re-use of ‘best-practice’ patterns starts from a perspective of ‘sameness’, and largely depends on an assumption that things stay much the same between different organisations and their contexts; ‘worst-practice’ focusses more on the avoidance of anti-patterns that are likely to lead to failure even where there is significant difference between contexts.

In a way, both approaches assume some ‘sameness’, otherwise neither pattern nor anti-pattern would make sense in another context. They also both assume some degree of ‘difference’, and need to adapt to that difference – hence ‘pattern’ or ‘anti-pattern’, rather than either prepackaged ‘process’ or ‘rule’ (extreme ‘sameness’), or unpredictable uniqueness (extreme ‘difference’). The architectural challenge here is to identify which patterns or anti-patterns might be appropriate for each context, and how to adapt, apply and evaluate them in designs for the respective context.

  • Cooperation versus competition

Cooperation assumes a shared ‘sameness’ of aim and intent; competition assumes that the aims of the respective parties are inherently ‘different’. In reality, the distinction is rarely that simple or clear-cut – hence concepts such as ‘coopetition‘, where cooperation and competition sit side-by-side in a perhaps somewhat-uneasy alliance; much the same goes for many business-partnerships and consortia.

There’s also a crucial and often-missed complication in terms of whether the overall aim of the nominal competition or cooperation is ultimately ‘with’ or ‘against’ others. Something that on the surface may appear to be competition is often actually a form of mutual-challenge cooperation, whilst apparent cooperation may actually mask destructive competition against another party: see the post ‘Competition-against or competition-with?‘ and the ‘manifesto’ on power and responsibility in the workplace for more detail on this.

Architecturally, this is one of the more complex types of balance between ‘sameness’ and ‘difference’ – and definitely made much more difficult by the many ‘political’ themes that thread their way throughout it. Be warned, perhaps? 😐

  • Individual versus collective

By definition, individuals are all about ‘difference’; any kind of collective implies some form of ‘sameness’. This point, and the concomitant need for balance between these two, applies almost everywhere in business: every sale, for example, ultimately represents an individual choice, a ‘market of one’, even for the most common of commodities.

Another important domain where this balance can often be crucial is in performance-monitoring. We need to develop the skills and experience that are inherent in the individual, yet we also need to acknowledge that in most cases those skills, experiences and overall performance arise only in the context of some broader collective. If we focus too much on the former, we may lose track of the very real contribution of the latter. For example, the intent of the US-style concept of ‘Employee Of The Month’ – which explicitly emphasises only the individual – is to underpin individual motivation and excellence; but in more collective-oriented cultures common in Latin America and elsewhere, it can actually be experienced and interpreted as a form of punishment, because it will challenge (and sometimes even break) the personal relationship with the work-team or other collective in the context.

Once again, getting the balance between these two poles can often be difficult in architecture and design – and especially so in multi-cultural contexts where different cultures each impose their own distinct bias on the balance.

One of the most important challenges here, for architects, is the all-pervasive influence of the linear-paradigm in business and within culture in general. The linear-paradigm – Taylorism and its ilk – will always push for ‘sameness’, because its ultimate basis is an assertion that there is a single ‘The Truth’ to everything. Yet in many areas of business the differences can be even more important: market-differentiation, for example, or the human difference of individual skills and experience. In architecture, getting the right balance between ‘sameness’ and ‘difference’ across the whole enterprise can call for some extremely difficult trade-offs: it’s very rare that it’s either simple or straightforward.

Any other suggestions or examples on this? Over to you, anyway.

4 Comments on “Same and different

  1. An ancient example:
    There is a Taoist story of an old farmer who had worked his crops for many years. One day his horse ran away. Upon hearing the news, his neighbors came to visit. “Such bad luck,” they said sympathetically. “May be,” the farmer replied. The next morning the horse returned, bringing with it three other wild horses. “How wonderful,” the neighbors exclaimed. “May be,” replied the old man. The following day, his son tried to ride one of the untamed horses, was thrown, and broke his leg. The neighbors again came to offer their sympathy on his misfortune. “May be,” answered the farmer. The day after, military officials came to the village to draft young men into the army. Seeing that the son’s leg was broken, they passed him by. The neighbors congratulated the farmer on how well things had turned out. “May be,” said the farmer.

    The absolutist attitude strikes me as a reverse-Tron: instead of an analog being stuck in a digital world, you have a binary attitude attempting to mold an analog world into its view.

    • Gene – yeah, a great classic tale: “Maybe yes, maybe no” is the version that I’ve known, but it’s essentially the same story.

      “instead of an analog being stuck in a digital world, you have a binary attitude attempting to mold an analog world into its view”

      Yes, exactly. And often trying too hard to hold on to some sense of certainty, too: hence the importance of the explicit acknowledgement of uncertainty in the architect’s oft-used phrase ‘It depends…’ (a later post than this one, I know, but definitely relevant here! 🙂 )

  2. Thank you for sharing Tom and great comment from Gene. It instant came to my mind: Yin and Yang. And I believe one of challenges is that they are often classified as opposing forces, instead of being seen as complementary forces.

    In your examples the structured data is needed to find the structure and connect the unstructured data, while the unstructured data is looked at to find the structure in it.

    Proprietary solutions become de-facto or real standards (at least those who win the innovation battle) and standards enforce new proprietary solutions to solve the gaps due to lack of fit-to-purpose.

    Commodity is to be used where no market differentiation is needed and allows to focus the energy on specialities somewhere else (80/20), which are then picked up by the competition and turned into commodity.

    Waterfall approaches (trying to know things before they are done) in a very strict and rigid way leads to people trying to get of boundaries which leads (sometimes) to agile (or more often chaos). Agile leads to structures where people higher in the reporting line feel uneasy, because they know less which creates new boundaries. Not many companies stay truly agile for a long time. 🙁

    Backbone solutions force people to work in a structure which is no fit for purpose which leads to shadow solutions which leads to costs which are eliminated by moving more into the backbone solutions.

    best-practice and worst-practice are the (known) end-points between applied-practices moves from one side to the other. 🙂

    In most cases cooperation works as long as both share the benefits till one has the chance to really exploit the system towards his side (some are long term planning to exploit, others short-term) and therefore leads to competition which usually starts the “war” of efficency. If breakouts via innovation (effectiveness) are not possible then some day a stage will be reached where cooperation is worhtwhile again (e.g. cartel, acquisition, merger).

    Indiviuals like to be part of the whole (being really truly different is in most cases not desired, because that is lonesom) but really being the same leads to pointing out the differences (even only in small signals).

    So it is to my knowledge and experience always an up and down a forth a back a both forces help each other to stay in stability.

Leave a Reply

Your email address will not be published. Required fields are marked *