Enterprise architecture and strategy

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Strategy and architecture are different in some quite fundamental ways. Strategy sets the direction: that’s the whole point of any strategy-capability. Architecture identifies the available choices and constraints for the most effective structures, or configuration of structures, that could implement that strategy; it also usually makes some concrete suggestions towards design, but that’s where EAs should really be starting to hand over to the solution-designers, and so on down the implementation chain.

Strategy has a clear decision-making role; whereas it’s arguable that architecture should only have a decision-support role at the strategic level. The architect may well be landed with making key strategic decisions, perhaps for practical reasons, or because no-one else will accept the responsibility; but blurring the two roles together can be problematic, not least because of the risk of ‘cart before the horse’ strategies such as where an arbitrarily-chosen technology ends up driving the strategy, rather than the strategy driving the choice of technology.

For enterprise-architecture, this is another example of why it’s useful to distinguish between ‘organisation’ and ‘enterprise’. An organisation is tightly bounded by the respective rules; an enterprise is a much more fluid affair, bounded by shared-commitment to shared principles, vision and values. (In effect, as described in the previous post, the enterprise is a story.) Another way to understand the difference:

  • the organisation is about ‘truth‘, about demonstrable compliance to extrinsic constraints
  • the enterprise is more about ‘value‘, about mutual agreement and alignment with intrinsic constraints

An organisation and its rules can exist at any level, from a work-team to a huge conglomerate or an entire nation: hence a business is an organisation, with explicit legal boundaries of responsibility and control. Organisations can be nested, with the rules becoming more and more and specific as we move downward into the detail-layers of the organisation-hierarchy. So in this sense the IT-department is usually also a distinct organisation in its own right, an organisation-within-an-organisation, with its own rules and reporting-relationships. Similarly for each enterprise: these too can be nested, or intersecting – and usually are. There’s a special-case where the boundaries of an enterprise coincide with those of the organisation, which sometimes gives rises to the illusion that the organisation is the enterprise – but it’s important to understand that this is only a special-case, and one that is rarely useful for strategy or architecture.

If we follow the logic of this, some important themes start to become clear:

A strategy is a set of rules and guidelines for future action. It therefore applies primarily to an organisation (rules) rather than an enterprise (values).

A strategy is bounded by the context of an enterprise. To put it another way round, a strategy is only usable in relation to an enterprise. An enterprise-architecture, which identifies the structure and purpose of the selected enterprise-of-interest to the organisation, must always precede strategy – otherwise it will not be able to provide the necessary decision-support about the nature of the enterprise, on which the strategic decisions will depend. Without that architectural understanding, the assumptions about the enterprise on which the strategy is based may well be invalid – hence, for example, the prevalence of cart-before-horse ‘solutions’ in so many organisations’ IT-strategies.

A strategy applies to an organisation, not to an enterprise. This is a direct corollary of the two themes above.  Without awareness of this distinction, the rules of the strategy (extrinsic motivation) tend to feel ‘imposed’, and hence shut down commitment within the enterprise (intrinsic motivation).

A strategy for any given organisation must always be defined in relation to an enterprise with broader scope than that of the organisation. The enterprise defines the context for the strategy, and hence must be larger than the applicable scope for the strategy itself. Note also that if the enterprise boundary is the same as the organisation-boundary (‘the organisation is the enterprise’), there is literally no space for anyone outside to connect with the organisation, and hence no reason to do so – a classic source of failure in marketing and most other forms of ‘outward-facing’ strategy.

A strategy will almost certainly fail if any attempt is made to apply or impose it onto an enterprise that is larger in scope than the respective organisation. This again is a direct corollary of the previous two themes. In effect, what happens in such cases is that the encompassing enterprise is treated as if it is an ‘organisation’ that is under the control of the subordinate organisation. For example, attempts at monopolistic business-strategies will almost invariably cause resistance and rejection in the respective market (ie. enterprise), often by creating large numbers of anti-clients. For the same reasons, an IT-strategy that attempts to tell the overall organisation how to run its business is guaranteed to cause friction – further exacerbating the infamous ‘IT/business divide’ – and, again, will almost certainly fail as a result of that resistance.

A useful rule-of-thumb is that the enterprise in scope should be at least two to three steps larger than the organisation in scope, both horizontally and vertically. This guideline applies regardless of whether the organisation in scope is self-contained or is a subset of a larger organisation. For example:

  • business-strategy: defined in relation to partners and supply-chain (horizontal), and customers, prospects and broader community (vertical)
  • IT-applications: defined in relation to people-based and/or machine-based components of processes (horizontal), and business and its customers (vertical)
  • IT-infrastructure: defined in relation to buildings, power-supplies, cabling and other physical infrastructure (physical-horizontal), IT service-management (people-based horizontal), and IT-applications and business usage (vertical)

Hence business-architecture and applications-architecture are part of the ‘enterprise-architecture’ for IT-infrastructure strategy – but to say that enterprise-architecture is solely about those specific IT-related themes is to miss the point. An enterprise-architecture is always about a scope larger than that of the respective strategy – whether the strategy relates to IT or anything else.

Most existing IT-centric ‘enterprise-architecture’ frameworks completely fail to understand this crucial point. TOGAF 8, for example, described the ‘enterprise-architecture’ sufficient to guide IT-infrastructure strategy: it was not suitable (because not sufficiently-broad scope) for IT-applications strategy or, especially, business-strategy. TOGAF 9 has probably expanded the scope sufficiently to cover IT-applications-strategy, but is still far from sufficient for business-related strategy – even though many IT-folks try to do this, and then wonder why there’s then an increase in resistance from the rest of the business. TOGAF’s horizontal scope is also notoriously inadequate, describing all non-IT infrastructure-level items as ‘business’ (confusing horizontal with vertical); FEAF’s reference to ‘Human Capital’ and ‘Other Fixed Assets’ indicates a somewhat better grasp of horizontal scope, but still attempts to define strategy for higher-level organisation, from IT (‘department’ level) to ‘business’ (whole-of-organisation level). A whole-of-organisation or ‘business’ strategy’ will necessarily depend on a whole-of-enterprise architecture that describes the context two or three layers outward from the formal boundaries of the business-organisation itself.

So in effect every architecture-discipline can also do strategy – but only for the ‘organisation’ implied by their own discipline, and should only do so with the decision-support of an architecture that has a broader scope than that of the respective discipline. In practice, this means that IT-architects can of course do IT-strategy, but should only do so if they have a solid understanding of the enterprise (ie. ‘the business’) within which that IT will operate. The same applies for process-architects and manual-process strategy. And business-architects may also do business-strategy, but only if they have a solid grasp of the broader context described by a whole-of-enterprise architecture that can summarise the context of partners and suppliers, clients, prospects, non-clients, anti-clients and the entire business milieu.

To do strategy, you must be facing outward, towards the enterprise. To do design, or to convert strategy to tactics, you need to be facing inwards, towards the fine detail. The aim of strategy is to define rules; much of architecture is more about identifying and expressing shared values. Expecting just one person to do all of these things is a big ask – especially in a large, complex organisation. Hence, although architects can also do strategy on the one side, and design on the other, it’s probably wisest wherever practicable to keep those roles apart.

2 Comments on “Enterprise architecture and strategy

  1. Tom,
    Thank you for the informative post. I agree that architecture should have a decision-support role at a strategic level. The architecture will be utilized by the design team to materialize / implement the strategy.

  2. A great piece Tom … as usual.

    My personal favorite is: A strategy applies to an organisation, not to an enterprise.

    Sorry I’ve been missing some great discussions. Contact me if you think I have something to add or question.

Leave a Reply

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