Fractals, naming and enterprise-architecture

What naming do we need, when we’re doing architectures for every part of the enterprise?

Yeah, I know this is another one that I go on and on about, but it’s just too bad: we need to resolve this one – or at least do it a lot better than we do right now.

If we’re working in a single business-domain, it’s actually not that much of a problem: we just use whatever naming-standard currently exists in that space. It could well be different from what we would ourselves prefer to use, but so what? – we just go with it, and carry on. The client’s paying the bills, after all, and they’re the ones who have to live with the immediate results, so accept that it’s their call. Yeah, at the edges it might get a bit tricky, since naming-schemes rarely match up: but we can solve that with a bit of translation and careful conversation. No big deal.

But what happens if it’s something that we might need to use anywhere in the organisation, or the wider enterprise? What if we have to use it in a fractal sense, self-similar patterns repeating across every domain, and at every level? – such as can and does happen throughout a whole-of-enterprise architecture? If the tricky bits come at the edges of domains, well, in a fractal context it’s all edges, pretty much – which makes it very tricky indeed. And that’s why and where we do need consistent naming – especially for a fractal service-oriented architecture.

If necessary, we might have use this kind of naming-standard only between ourselves, as architects – and then do the translations to other domains as required, using their naming-standards. But if we don’t use a naming-standard that’s consistent everywhere, we’d have no chance of creating an architecture that makes sense, across the whole, to us – let alone to anyone else. That’s why this is so darned important…

I won’t claim that that what follows is ‘the proper way to do naming’: it’s just the way I do it, that’s all. But the key differentiator here is that this naming is consistent everywhere: the same term is used for the same type of thing everywhere. Compare that with the usual approaches to naming – especially in ‘the business’ – where different terms are used for the same thing, and the same term used for different things, almost at random. Think fractal, not linear – that’s the key here.

First, two definitions about scope:

— Enterprise: “a bold endeavour”; an emotive or motivational structure, bounded by shared-vision (purpose), shared-values and mutual commitments.

— Organisation: the primary delimiter of scope; a legal structure, bounded by rules, roles and responsibilities.

Two key points to note here are that:

• we develop an architecture for an organisation, but about its respective enterprise
• for most purposes, the enterprise in scope should typically be at least three steps larger than the organisation in scope

For an example, in visual form (where ‘step 1’ outward from the organisation is the supplier/customer shared-enterprise):

For more detail on this, see the post ‘Organisation and enterprise‘.

Next, three definitions about what guides an enterprise:

— Vision (aka ‘Purpose’ or ‘Promise’): a brief statement of what it is that links together everyone within the shared-enterprise (What, How and Why), and that acts as the ultimate qualitative and decisioning-anchor for the shared-enterprise

— Values: prioritised qualities derived from the vision that act as the ultimate anchor for indicators and metrics of success within the shared-enterprise

— Principles: actionable rules, patterns or guidelines derived from the values, providing implementable and/or actionable higher-order decisions for the organisation within the enterprise

For more on how these definitions apply in practice, see, for example, the post ‘Why before who‘.

Note that ‘Vision’ is used here in the same sense as in the ISO9000:2000-family of quality-system standards: a permanent and non-changing anchor for the quality-system and for decision-making.In this sense, the vision does not and cannot change, because it in effect defines the shared-enterprise: or, more to the point, if it does change, we are literally no longer in the same enterprise. Contrast this with the usage in Business Motivation Model and similar standards, where ‘Vision’ is a descriptor for a short- to medium-term goal, a ‘future state’ – in fact merely on type of Driver, subordinate to a Principle. Both are are valid definitions for ‘Vision’, but the two definitions are not compatible with each other: don’t mix them up! If necessary, use ‘Purpose’ or ‘Promise’ as alternate terms for the sense of ‘Vision’ used here – but if possible, do use ‘Vision’, to maintain compatibility with ISO9000.

Moving onward, one of the key concepts that enables a fully fractal view of the enterprise is an admittedly-arbitrary yet very useful assertion that “everything in the shared-enterprise either is or represents or implies a service”. (See the posts ‘From product to service‘ and ‘From service to product‘ for more detail on this.) This leads to the following definitions:

— Service: literally, ‘that which serves’ – something that takes action to serve a need.

— Task: a single iteration or instance of service-execution.

— Process: a perceived sequence of invocations of services, where the perceived sequence may be either structured (repeatable) and/or non-structured (non-repeated). In practice the nominal boundary of a process is an arbitrary choice – see post ‘What is the boundary of a service?’.

— Product: an asset acting as static intermediary between services – again, see ‘From product to service‘ and, especially, ‘From service to product‘ for more detail on this.

Given a service, what makes up the content of the service? The descriptions we need vary somewhat according to the respective level of abstraction, from not much more than just a name, right down to full implementation-detail, but we could summarise the overall content-scope in visual form as follows:

At the more-abstract levels, it’s probably enough just to use a Zachman-style taxonomy of What, How, Where, Who, When and Why. But as we work our way down towards real-world detail – to a Zachman ‘Business’-layer, for example, and certainly for a Zachman ‘Logical’-layer – we need to twist that conventional view somewhat, particularly around Zachman’s ‘How’, ‘Who’ and ‘When’. This rework gives a more explicit taxonomy-set of Asset, Function, Location, Capability, Event and Decision/Reason:

— Asset (‘What’): a resource of some kind, either used within a service or acting as a product between services; the composition of the asset may take on any combination of the asset-dimensions (physical, virtual, relational and/or aspirational).

Note that a product – as a static intermediate stage between services – will consist solely of one or more assets, bundled together in some way.

— Function (external view of ‘How’): external-facing interface for a service (‘black-box’ view), responsible for the respective protocols, service-contracts, service-level agreements etc; accepts and returns assets and other resources, hence may act on any appropriate combination of asset-dimensions.

Note here that the Zachman-style ‘How’ gets split into two distinct parts: the function, which provides the external view of the service (and, from the outside, will seem to be the same as the service); and the capability that actually does the work, and which should not be visible from the outside. By making this split, we enable substitutability, virtualisation, internal-scaling and all manner of other ‘good-to-haves’. We can summarise the relationship between function, capability and service – and their onward relationship with affordances – in visual form as follows:

This distinction is sometimes less visible in software-based systems, or services delivered by physical-machines, where function and capability tend to be bundled together; but it’s very visible, and very important, in any human-delivered services, or services that use mixtures of delivery-mechanisms, especially where those mechanisms may be interchangeable – such as in a customer-support system which escalates from software-based to human-based service-delivery.

— Location (‘Where’): a position within the terms of a specific schema; may take on any combination of the asset-dimensions (physical, virtual, relational, aspirational), and/or the abstract location-schema of time.

See the post ‘Assets and services‘ for examples of how the asset-dimensions apply to locations.

— Capability (‘Who’, and/or internals of ‘How’): the ability to do something (part of ‘white-box’ view of a service), itself typically made up of other services and/or products at deeper levels of recursion. Capabilities use an agent to apply an action upon a specific type of asset, using a specific competency or skill-level:

—- capability: agent: that which enacts the capability – often as the active mode of a product; may take on any combination of the asset-dimensions, such a physical-machine, a virtual software-application, a real person (via a relational-asset link) and/or an abstract aspirational-asset entity such as a brand.

—- capability: action-upon: the asset-type acted upon by the agent; may take on any combination of the asset-dimensions.

—- capability: skill-level: skill-level and/or sensemaking/decision-making competence of the agent applying the action to the respective asset; may take on any combination of the decision/skills-dimensions (trainee, apprentice, journeyman, master).

— Event (‘When’): trigger for the function and underlying capability of a service; may take on any combination of asset-dimensions (physical-event, virtual-event, relational-event, aspirational-event).

See the post ‘Assets and services‘ for examples of how the asset-dimensions apply to events. Note also that whilst events may occur in time they are not necessarily of time – in other words, time as attribute of event, rather than necessarily an event in its own right. That distinction may at first seem somewhat subtle, but is often very important.

— Decision/reason (‘Why’): the applicable level of sensemaking/decision-making for the service, and/or its type of guidance or governance; may take on any of the decision/skills-dimensions (rule-based, algorithm-based, guideline/pattern-based, principle-based).

The asset-dimensions apply to asset, function, location, agent of capability, action-upon of capability, and event of a service, and also to a product as asset:

• physical: physical object, machine, location etc;
  as asset, is tangible, independent (it exists in its own right), exchangeable (I can pass the thing itself to you), alienable (if I give it to you, I no longer have it)
• virtual: information, software-application, IP-address etc;
  as asset, is non-tangible, semi-independent (exists in its own right, but requires association with something physical to give it accessible form), semi-exchangeable (I can pass a clone or imperfect-copy of the thing to you), non-alienable (if I give it to you, I still have it)
• relational: link between people, or people and other tangible ‘things’;
  as asset, is semi-tangible (each end of the link is tangible), dependent (it exists between its nodes, and may be dropped from either end), non-exchangeable (if I have it, I cannot give it to you – though I can create conditions under which you could create your own equivalent copy), inherently non-alienable (there is nothing that can be given to others)
• aspirational (‘meaning’): person-to-virtual link (such as memory of grandparent, or association with/to an enterprise or a brand), or virtual-to-virtual (such as links between brands in a brand-architecture, or relationship between model and metamodel in a schema);
  as asset, is semi-tangible at best (one end of the link may be tangible, but at least one node will be virtual), dependent (it exists between its nodes), non-exchangeable (as for relational-asset), inherently non-alienable (as for relational-asset)
• abstract: a ‘none-of-the-above’ category – probably used only for non-CRUD resources such as time, in relation to location.

See the post ‘Assets and services‘ for illustrations of how the asset-dimensions apply to asset, function, location, capability and event. See also the post ‘CRUD, CRUDE and other action-acronyms‘ for explanation of how various types of assets are created, ‘read’, updated, deleted and more.

Note that, by intent, there is no direct equivalent of ‘Who’ at this level: for many legal, social, ethical and other reasons, real-people should never be described as ‘assets’. Instead, we make it explicit that we have access that person (and the skills, experience and intent of that person) only in indirect form, via a relational and/or aspirational link. By making the link explicit, we are then able to view the link as an asset in its own right, that needs to be created, read, updated, maintained and, eventually deleted or dropped, just as for any other more tangible type of asset. Although people are not ‘assets’, the links with those people most definitely are assets, and need to be managed as such: that distinction is perhaps subtle at first, but extremely important.

Note also that combinations of assets are very common: for example, a printed-book is a physical ‘thing’ (physical-asset) containing information (virtual-asset), is probably associated with a person (relational-asset) and has personal meaning for that person (aspirational-asset). Money is sometimes considered to be an abstract-dimension entity, or even a dimension in its own right, but is better understood as a combination of virtual-asset (number) and aspirational-asset (belief or faith in the value of that type of currency).

The decision/skills dimensions apply to skill-level of capability, and decision/reason for use within a service:

• rule-based (trainee): simple, linear, true/false or limited-quantitative rules, applicable in real-time contexts; typically the only type of decision-making available to a physical machine, a low-level software-element or a trainee-level real-person
• algorithm-based (apprentice): potentially-complicated but linear true/false or quantitive algorithms, potentially including any number of factors, delays, feedback-loops etc, but often not directly applicable in real-time contexts; typically not available to physical machines, but available to a higher-level software-element and an apprentice-level real-person
• pattern/guideline-based (journeyman): methods for complex, ambiguous, non-linear, qualitative, ‘wild-problem‘ contexts, addressing experiment and uncertainty, though often not directly applicable in real-time contexts; typically not available to physical machines or to conventional true/false-type software-based systems, but available to ‘fuzzy-logic’ software-systems or a journeyman-level real-person
• principles-based (master): methods for uniqueness, extreme-uncertainty and/or ‘chaotic’-type contexts, especially at real-time; rarely available to physical-machines or software-based systems, but typically available to master-level real-person

Note that whilst the decision/reason dimensions do act much like true mutually-exclusive dimensions, each somewhat aligned with the respective asset-dimension (rules -> physical, algorithm -> virtual etc), the skills side of these dimensions often seems somewhat more like a stack: master-level incorporates and extends journeyman, which itself extends apprentice, which in turn extends trainee.

In effect, the decision/reason dimensions define a context-space, within which, in skills-development, more and more of the context-space is experienced and populated. The standard skill-development sequence merely represents a long-proven pattern for expanding out into that SCAN-type context-space:

Yet it’s not necessarily linear: for example, trainees will need at least some guiding-principles (i.e. nominally ‘master’-level) in order to respond appropriately to real-time transits over ‘the edge of panic’, where the rules under which they have been working may suddenly no longer make sense, or can apply:

For more details on the skills-learning model used here, see the post ‘The over-certainties of certification‘.

Applications in enterprise-architecture

Just to reiterate from earlier above: this does not claim to be ‘the true definition’ for each of the elements described here.

Instead, it’s a set of definitions that are known to work well together, and are particularly well-suited for use in a whole-of-enterprise context – especially a service-oriented approach to enterprise-architecture for ‘anywhere in whole-of-enterprise’. The key is that they can be used anywhere, in any context, whenever we need consistency across a whole multi-layered and/or multi-domain context – in other words, wherever we need to think fractal, not linear.

By contrast, these definitions may well seem too abstract or ‘technical’ for use in a single-domain architecture, where we typically would, should or must ‘think linear’. For that type of context, the terminology already in use there should be used instead, with ‘translation’ for other domains and/or levels applied as required.

Over to you for comments, anyway?