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 multi–part series on ‘no 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.