This article is a republishing and updating to reflect some thinking which emerged in the comments when the original article we published in early 2016 – here is a link to the original article
One of the questions that I posed in the opening posting of the series that I started at that time was:
How would we go about describing the current or intended architecture of our enterprise?
Common models and views
In another posting about conventional practices, I indicated that the development of organisational charts and position descriptions were one of the current practices undertaken in many enterprises. What other models and views do we develop to describe the current or intended architecture of an enterprise?
The next most common model and associated views is the process model. This can be prompted by a range of motivations, including:
- A continuous improvement program which encompasses the progressive development of process models for various subsystems within the enterprise
- A quality management program, potentially in conjunction with adoption of standards within the ISO 9000 series, where the Corporate Management System or the Business Management System provides shared access to the processes developed to ensure a consistent approach to deliver of quality products and services
- An information systems or IT system program which is establishing improved processes and/or IT enabled processes which need to be described to support the design and realisation of the proposed system
In the latter case, it is likely the information models and views will also be developed to reflect the way in which the shared information is to be organised, managed and accessed.
Key dimensions
What other dimensions of an enterprise are part of its architecture description? Various models suggest the following dimensions are encompassed:
- People / roles / organisation units
- Process
- Information
- Assets (offices, plant, equipment)
- Finance
- Information and communication technology (ICT)
These seem to be the primary:
- resources
- integration points
which can be encompassed within an architecture which has a focus on elements and relationships which are fundamental to the enterprise-as-system.
Other elements
There are other elements which are not owned and controlled and hence not designed and architected which feature in architecture descriptions, as there is a need to understand relationships, flows and interactions, both internal and external. Hence, architecture descriptions will reference external entities, including:
- Customers and consumers
- Suppliers
- Partners
- Competitors
- Regulators
This is an important feature of architecture descriptions and enterprises.
An architecture description includes reference to entities and relationships beyond the bounds of the enterprise
This has proven to be a point of considerable debate and confusion surrounding what I perceive to be the failure to appreciate the distinction between the scope of the enterprise and the scope of the architecture description. The latter must convey information about the enterprise-as-system “in its environment” and necessarily includes entities beyond the scope of the enterprise.
Sufficiency
Do we have a sufficient coverage of entities and relationships to encompass the description of the architecture of our current and intended enterprise? Are these sufficient?
The ultimate test, based on ISO 42010, is whether these provide all the necessary elements to address stakeholder concerns arising in considering the current or intended architecture of an enterprise. In my experience, these have been sufficient. I leave the question open as others may find my list incomplete.
With these foundations, we can now explore the models and views which seem to prove most useful across the range of architectural engagements in which I have been involved. This draws me back to elaborating further on a number of the models that I listed in the posting about the elements of architecture descriptions, including:
- business models
- operating models
- capability models
- organisation models
Postlude
A key message in this posting on current practices is exactly what Doug McDavid said in a comment.
Executives and Managers create various elements of the architecture description already.
They are prescribing and describing the architecture, whether they realise it or not and whether they call it architecture or themselves architects, or not. What I have not said explicitly, but is implicit in this series, is in line with his linked article, is that aspects of the architecture become evident in various enterprise documents, and therefore can be discovered and, if necessary, made more explicit.
For example, principles are often implicit in business language and business documents, but few enterprises make the principles underpinning their enterprise explicit. Similarly, language and key concepts, commonly found in enterprise documents, may well reflect important elements of process and information architectures. A couple of colleagues have experimented with tag clouds as a tool for more rapidly identifying elements of the enterprise ontology.
A number of articles will be written over the next few weeks, expanding on key principles underpinning the practices that I have found most effective in supporting Directors, Executives and Managers to better architect their enterprises.
enterprise-modeling 