This one is a follow-up to a couple of comments by Pat Ferdinandi to my earlier post on “Annoyed at ‘Enterprise 2.0′”. I had explained in one of the comments that there’s a danger of a high-risk ‘term-hijack’ if conflating the terms ‘organisation’ and ‘enterprise’, because they’re not the same: ‘organisation’ is a legal entity – more accurately, an entity defined by an enforceable governance boundary – whilst ‘enterprise’ is a social entity, a collaboration towards shared aims and objectives that does not in itself imply or demand any explicit form of governance. In effect, an enterprise can be any subset or superset of the organisation:
From a business perspective, there are at least three layers of enterprise that are supersets of the organisation:
- customer-base (and, in an E2.0 context, reviewers/critics);
- and broader community (e.g. reputation-management / CSR).
This latter point about supersets becomes extremely important in enterprise architecture and business architecture, because they’re outside the scope of direct governance of the organisation. If we make the mistake of assuming that the organisation is the enterprise, is a literally self-centric, self-referential ‘business architecture’ that has no connection with the real world – i.e. the ecosystem in which the organisation operates – which, in the mid- to longer term, usually leads to failure of the organisation. In other words, not a good idea… So we need to model that wider scope in our architecture.
Pat then remarked:
I will admit that I’m very business focused (ok biased).
Because B2B or any collaborative interaction between multiple companies (banks needing to share information/transactions or hospitals needing to share and transfer patient data) the EA needs to include both companies and may need to model the industry (including government mandated laws or reimbursement qualifications or negotiated rules).
These examples would be larger than the subset of the organization. Would this be your whole-of-enterprise? It fits the IEEE1471/FEAF definition.
My answer would be that whilst this is important, it’s still far too small a scope for a business-architecture or whole-of-enterprise architecture: in effect, just the first of those three layers above (partner/supply-chain context, including direct-impact legislation, regulation and standards). To identify the full depth of drivers that impact on the organisation from the broader enterprise, we need to model the other layers as well.
To model the customer-base context, it’s imperative to explore the shared vision held by all participants in the enterprise – in other words, the motivation that underpins the entire enterprise. Standards such as the Business Motivation Model can help here, though the BMM itself has some limitations that can be resolved via explicit extension – see my presentation on Vision / Role / Mission / Goal or the ‘Architecture on purpose’ chapter in Real Enterprise Architecture for more details on that. Perhaps the most useful hint here comes from ITIL Version 3: “customers do not want products or services – what they want is the satisfaction of a perceived need”. Focus on identifying the shared needs that unify all participants in the enterprise – your own organisation, your partners and suppliers, your customer-base and their social ‘quality-management’ context (anything from reviewers to critics and complaints), and the legal, regulatory and standards framework that applies to the servicing of those needs within that context. This describes the principles and drivers that you can use ininnovation-support, in customer-relationship management, and much else besides.
To model the social milieu context, explore the social expectations for any organisation or business operating in this context: issues such as transparency, fairness, environment, corporate social responsibility and so on. Do not forget to include these as drivers and themes within your architecture models, via techniques such as Vision / Role / Mission / Goal: failure to do so can cost you very heavily indeed, especially in the longer term. Also, be aware of cross-cultural differences: different cultures have different expectations and different demands, which can cause significant impacts, especially for organisations with a multi-national reach.
One useful approach is to view architecture as part of risk-management and opportunity-management. From that perspective, it should be obvious that a risk-analysis and matching opportunity-analysis would be incomplete if it fails to include the ‘bigger picture’; the same should hence also be true for architecture analysis, especially at the business-architecture orwhole-of-enterprise architecture scale.
Hope this helps, anyway.