The last potential touchpoint that I’m going to consider is how architecture models interact with process re-engineering. Now, it’s not always the case that there’s an architecture modeling effort and a process re-engineering effort happening concurrently within the same organization. However when there is, the challenge I’ve encountered is how to ensure that the two efforts don’t contradict one another while allowing them to avoid dependency.
The first question hinges on repositories. I’ve found that a majority of architecture tools will support process maps (especially, BPMN), so it's a natural step to store the architecture model and any process models from the effort in the same repository. Unfortunately, this requires some care. If the architecture team are working off the exact same model as the process re-engineering team, this implies a tight degree of co-ordination between the two. In other words, any change made by one team to the model could hinder ongoing analysis from the other if both teams are working from the exact same model.
Fortunately, many modeling tools enable a level of partitioning to keep different models separate (generally with the ability to copy elements between models). For example, Orbus Software’s iServer has libraries, while another tool might have packages. So the recommendation is that if the two efforts do work using the same overall repository (and in a moment we'll discuss advantages to that), then they should be kept separate using whatever partitioning mechanism the tool supports.
With this stated, there are two areas where the two disciplines can benefit from co-ordination. First, if the architecture team have been able to map applications (or, even better, data) to processes then this can provide an invaluable input into the efforts of the process re-engineering team. The ability to know what applications or data a process uses open the door to questioning what tasks within that process perform this access, which can highlight potential inefficiencies.
So if such mappings exist, it can be helpful for the architecture and process re-engineering to agree a set of processes and mapping to the data and applications they access. Even if they don't, it can potentially be helpful to engage in this mapping (even if restricted to critical applications and data), which then provides an example of how architecture supports the business.
The second area of synergy comes from services. It's not uncommon for a process re-engineering effort to be based around the concept of service delivery – what are the processes that deliver a specific service, and how can they deliver that service better? Now, service is a word that has quite a few meanings within architecture, but the services that the process re-engineering group would be referring to in this case, would be what architects call business services.
The key point here is that the process re-engineering team, if it exists, will have a mandate from the board to engage with the business and establish a baseline of signed-off business services that the architecture team can then use within their architecture models. Effectively, the process re-engineering team become owners of the business service catalog.