Determinants - externalities that determine what a business does, how it operates etc. These are external factors that include: cultural and social, market and competitive, legal and regulatory, etc.
Enterprise strategy - business: vision, mission, goals, strategies and plans (product, market, organisation), cases, governance and compliance, measures etc
Enterprise operations - business: services, processes, rules, information (objects, documents, data etc.), organisation, facilities etc. and change iniatives
Systems and facilities - including applications and services, technologies and system services, facilities and internal utilities. The systems area can be further divided into business services and systems and technology services and systems.
Suppliers - externalities that determine the products, services, standards a business can use e.g. technology products, services and standards; product channels; real estate and facilities. This section includes details of all provisioning and agreements.
Effectively the external constraints are the determinants and the suppliers; the goals come from the strategy and the operations, systems and facilities - represent a solution set (i.e. designed to the meet the goals based on the constraints).
Notes on the above
- I have tried to avoid using two loaded terms in the above "architecture" and "framework". I use Enterprise to encompasses things that may not be "businesses" per se.
- In each of the middle three areas there may be change initiatives (for transformation or optimisation driven from that level).
- Business requirements derive largely from the Enterprise Strategy and Enterprise Operations.
- User acceptance is the confirmation that the Systems and Facilities meet the Requirements i.e. represents a boundary condition and/or illustrates compliance with a set of constraints (e.g. requirements).
- The division into into business services and systems and technology services and systems may be increasingly hard to work with in a way that is useful for decision making for most enterprises e.g. splitting a GPS function used by a business into its: application, infrastructure (device) and service (e.g. satellite) components may in practice be difficult. This will increasingly be the case as consumer and external services and components are integrated to support Enterprise operations. Similiarly in the past some technology reference models have identified somewhat layers of technology that are increasingly irrelevant in practice with many devices e.g. operating systems, graphics presentation, file and database, etc. are not that useful if the device is an appliance. These division are probably useful distinctions for technologies operated internally by an enterprise. But a decision is 1st required that operating these technologies internal is to be desired or required.
Posts
A really useful summary - many thanks.
ReplyDeleteIn terms of cross-mapping, your 'Determinants' layer is much the same as I've been describing as 'Zachman 0' - it's the (mostly) invariant core-themes for the enterprise that are (mostly) 'above' the organisation.
As a very rough approximation, your 'Strategy', 'Operations' and 'Systems/Facilities' would align with Zachman 1-2, 3-4 and 5-6 respectively.
What's new is the 'Supplier' dimension - it's horizontal rather than vertical, which is really important. I haven't seen that before in an EA description. Following that logic, though, I would suggest extending it in the other direction to customer, so that it becomes the full horizontal 'Supply-Chain' rather than just the supply-side of it.
Hope this helps, anyway.
I think it aligns fairly closely with Z. I think Zachman refers to supplier dimensions at a Out-of-Context (layer 7 if you like). The reason I don't mention the Z framework is that:
ReplyDelete- I think the "framework" ambiguous and I don't see the Z FW as a metamodel but rather as a taxonomy (actually the absence of a definitive metamodel is a problem I see in Z FW).
- I think people treat Z FW as cannon - and I think it a powerful idea but not canonical. In fact I think it needs adjustment to suit the changes that have occurred in the 20 years since it was conceived.
Customer is part of "market".
I agree (strongly) about the limitations of Zachman, but I tend to cross-refer to it simply because it's what most people know. For all its flaws, it is still a good starting-point: his handling of the columns (what? how? where? etc) is a mess, frankly, but his layering of the rows is still essentially valid.
ReplyDeleteOn customer, agreed, customer is part of market at the Determinant layer, but it is also part of Strategy (how you aim to relate with customer), part of Operations (how you plan to interact with the customer) and, especially, in Facilities (how you will link your systems - physical, IT, whatever - with those of the customer in real-time service-delivery in a supply-chain/value-web). I'd argue it's best understood as part of a 'supply-chain' or 'value-web' dimension, orthogonal to the main framework - not a single subset within one high-level segment of the frame.