How do we ensure that the enterprise architecture truly covers the enterprise?
Many architects find that many EA frameworks are very oriented towards managing the IT aspects of the architecture and do not provide enough support for the non-IT things. I suspect that there’s an element of “the squeaky wheel gets the oil” here as managing and delivering IT systems has been and continues to be one of the most tricky activities that organisations do. However, I don’t think it helps to separate IT-focussed enterprise architecture initiatives from the broader EA discipline, rather the former is a part of the latter. We designed the Essential Meta Model to provide the constructs for capturing knowledge about all aspects of the enterprise (including the extended enterprise), where Information Technology is just one class of technologies that are used to support how the organisation functions.
Enterprise Architecture is about understanding and managing how the organisation works. This understanding enables us to make the right decisions both tactically and strategically in whatever issue is at hand. What information about the organisation do we need to capture? At the core of this understanding are people; processes; information that people need to perform the process; applications to support or automate the execution of the processes; and technology to support those applications. Pretty much all other knowledge about the enterprise refers to or operates on these core concepts. The last two things I mentioned (applications and technology) do not have to be Information Technology things. I’ll come back to these in a moment.
Is the knowledge we need just about what we can see in the enterprise? No, we need 3 main views of this knowledge, which I’ll describe in the terms we use in Essential Meta Model:
- Conceptual. This defines ‘The What’, enables us to capture the requirements and very importantly, gives us a semantic grounding for all of the other elements that we will capture at the following views that operate at a lower level of abstraction.
- Logical. This defined the ‘The How’ and is where we design how we see the enterprise working – either now or in the future.
- Physical. This defines ‘The Where’ and ‘The Who’ and is where we capture what’s actually there in the organisation, such as individuals, teams, data stores, deployments of applications and technology instances (e.g. servers).
With these three views, we can then understand things like: how many ways do we do the same thing? Is there a good reason for that or should we be standardising?
OK, so this sounds all very much IT-oriented, and in many ways, the physical is particularly tricky for IT architecture for a number of reasons. First a start, physical applications don’t really exist as such in the physical world. The digital media arena demonstrates this, where physical instances of the product can be produced instantly and for no cost. Many applications – especially mash-ups and composites are run-time configurations of a distributed set of software components and other applications. What are the physical ‘bits’ (pardon the pun) of one of these?
We’ve had a lot of success with capturing and managing the physical technology architecture in the last year or so, taking clustered, virtual and distributed server architectures into account. However, we had to make sure we didn’t take any shortcuts with how these things really exist in the physical world.
So information technology things are well catered for but what about manual processes or processes that are performed by machines or by people using machines? How do we capture these in our meta model? Well, a manual process is performed by people we’ve captured in the physical view of the business layer. It’s likely that information is required to perform the process and we can capture that. (Note, ‘information’, not ‘data’). If it’s a manual process, surely it has no supporting applications defined for it. Or does it? Actually, the lack of information here cannot be used safely to make assumptions like this. Rather, we take exactly the same approach with ‘manual’ processes as we take with any other and capture the supporting applications and the technology used to support/deliver that application.
Processes can still be supported by ‘applications’ that are not delivered by Information Technology. For example, we might have a paper-based form that is used to support the process of capturing customer information. This form is the application and the paper is the supporting technology, which is stored in a filing cabinet instead of a database. Similarly, if we need to capture that a milling machine is involved in the process of manufacturing a widget, that machine is part of the technology architecture of the application (the behaviour of the control system of the machine) that supports that manufacturing process.
If someone described doing a manual process to me, I would ask “and what do you use to do the process?” Even if the answer is pen and paper or “I talk to the customer, using a script”. From the answers to these questions we get an understanding that we can choose to characterise as “manual”.
I don’t think that these examples are stretches of the terms ‘application’ and ‘technology’ if you think conceptually about what these are doing. As I mentioned earlier, the organisation is about people performing processes to meet the organisation’s objectives – to produce products, provide services etc. – and there are applications that support the doing of the processes (or could fully-automate the process) and these applications are supported by technologies. It doesn’t matter if this involves Information Technologies or any other Technologies.
The point is that manual is a function of what supporting things you use to do the process. With the exception of fully-automated processes, most processes -including those supported by applications – are driven manually. Indeed, many so-called “manual” processes are still supported by office productivity tools.
Although this involves more modelling, it’s far more accurate to capture processes in this way than adding a “this is manual” attribute to the process. This gives us the objective knowledge in the model on which to later on base inference and derive knowledge from, long after the process was captured.
There are many other elements of knowledge that architects of all types need to capture about the enterprise in order to support their architectural processes. We are already working on expanding what we call the EA Support layer of the Essential Meta Model. The things in here refer to or operate on the elements in the Core meta model and so far we’ve found that this approach has elegantly handled all our requirements to date. But we’d love to hear about the sorts of things that you need to have in there.