Simplified modeling of roles related to IT

A while back I wrote the first post in this blog. It was about handling the secondary and tertiary architectures in your organization. Stuff like the application owner and the process owner and IT support etc. There, examples were given on how you are supposed to model these roles and their relations to your primary architecture (business functions and processes and the IT they use). Now, I admit that going into this breadth might not always be practical and I confess that we have not started modeling secondary or tertiary architecture fully yet. But we do handle all those roles in a simplified approach.

Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF)  for more information.

I divide Enterprise Architecture into Current State Architecture, Future State Architecture and Change Architecture, an example of the latter is a Project Start Architecture (PSA). Our Current State Architecture is a model of all we have in our enterprise. At the time of writing, there are almost 8000 objects and over 17000 relations in that model.

Now, I think it is unavoidable that there will be multiple models of that one reality that your organization in the end is. For instance, our help desk application has its own IT-support, which includes a CMDB (Configuration Management Database). This database mainly used to have all the hardware with their software. But these days, the IT service management organization wants to know more. If an incident with an application is recorded, they want to know which processes are involved, so they can (in extreme circumstances) call the executive of that process to inform him or her. They want to know who the application manager is, in case his help is required. In other words:  they need a kind of CMDB+ and support systems these days offer that. So, what do they do to fill their CMDB+: they get their hands on the process descriptions and link the applications to the processes in their tool. And thus appears a second model of the business architecture, now as part of the help desk tool. It generally is not updated when the process descriptions themselves are updated, and often even those are not always immediately updated when the process changes. It might be even worse: service management asks around and creates its own incompatible description of the processes involved.

And half a year later, someone starts a business continuity initiative. This too needs documentation of the processes and how these are supported by IT. If you have bad luck, a third incompatible model appears. And concurrently, the risk management department wants to fill their tool with risks and applications and of course (again) the processes involved. Guess what? A fourth incompatible model appears. In the end, almost every function in your organization that needs this kind of information has its own model, in documents, spreadsheets, graphical representations, presentations, and as data in a whole series of tools. The models are incompatible and often even internally incoherent as well as generally seriously out of date.

Still, the need for the models is real. The help desk does need to know how applications relate to the business if they want to be able to inform the right people about problems with the IT support for their processes. And the risk managers do need to manage counter measures and report on their efforts. And while we might have a very complete model in our Enterprise Architecture modeling tool, that tool will neither support help desk operations (e.g. log incidents) or risk management operations (e.g. have a work flow for audits and their aftermath). There is not one big tool for everything, and that is why we will always have multiple data objects all realizing that same business object (the Current State Enterprise Architecture).

So, our approach has been to set up the following design principles for modeling the current state:

1. If possible, a model will be the slave of another model;
2. If master-slave is not possible, the meta-models must be compatible so that reconciliation between both models on a regular basis is possible;
3. Our Current State Enterprise Architecture model must have enough detail to be the foundation of this approach.

The first method we have implemented for our service management organization. The CMDB+ is fed from our Enterprise Architecture model. It goes too far to go into specifics here, but we have mechanism and processes to keep this working. However, being a source for the CMDB+ (not necessarily the source, but for the items we deliver we are the source) also means that we have to be able to tell for every application who is the owner, who is responsible for change, who is the application manager, etc., all the stuff the help desk needs to know for its operations (“Who you’re gonna call?…“).

Now, if we want to model that properly, we have to do the entire set up of our secondary and tertiary architectures. And that is not only generally too much work, it is also for another reason unpractical: all these secondary architectures have different structures, so there is not a simple analysis that will give you the ‘owner’ of an application, especially if there also is ambiguity (a system used in multiple departments: who is the owner?).

So, we needed to set up a simpler, more direct scheme. We based the scheme on the secondary/tertiary setup, but instead of modeling it all, we devised shortcuts, several of which we implement by creating direct Association relations from Role to some other object. Here are the roles we identified surrounding applications (some of which may be assigned to the same actor of course):

1. User: does the work and uses the application;
2. Process Executive: manager of the user and thus accountable for the process execution;
3. Process Owner: decides how the process should be executed;
4. Application Owner: decides what the application should do for to the process;
5. Data Owner: decides data policies;
6. Contract Owner: responsible for contracts with application and data providers;
7. Change Manager: delivers (and changes) the application itself;
8. Application Manager: configures the application and thus changes its behaviour;
9. Run Manager: makes sure the application runs, is responsible for the infrastructure.

In an overview, it looks like this:As you can see, each role has a relation with a specific object in the landscape. Only the user’s role of being assigned to a process is standard. For instance, the Application Manager role changes the functionality of the Application, normally by changing configuration (e.g. adding users, setting up defaults, etc.). The Change Manager is the one who delivers the Application Component. The Information Manager is responsible for deciding how the application must support the business and is therefore owner. The Run Manager is responsible for the TI-Services required for the application to run. If you look at that previous post, you can see how for instance the role of the Run Manager (it is called ‘IT Exploitation’ in that view) relates to the Infrastructure Service (actually, an officially derived relation is not possible in that view). The Association relation we draw here acts as shorthand for that whole structure.

There are many organizational choices in this example view that could be made differently of course. For instance, in this example the manager of the department is both Process Executive and Process Owner and he supervises the Information Manager (and the User of course). But you could also have the Information Manager or someone else fulfill the role of Process Owner, even if the department head remains Process Executive. Many different organizational patterns are of course possible (though modeling them might show you clearly why some things won’t work, e.g. where you get schizophrenic accountabilities on application ownership or as we say in The Netherlands more than one captain on board). Having it set up like this, it is pretty simple to change this when business policies change.

Note not everything is drawn here. If you look at the way the Data Owner’s responsibility is modeled (defines the Data Policies Business Object which is seen as an aggregated independent part of the Process Description), a likewise solution could be used for the Enterprise Architect, whose guidelines may be part of the application requirements and who was drawn in that earlier post. Or think of the Security Officer, whose requirements are an (independent, aggregated) part of Process Descriptions and Application Requirements.

With these roles (and their actors) in our Enterprise Architecture Current State we can be the master of the CMDB+ as well be the source from which we report on the way we are in control over our landscape.

Principles and guidelines sometimes need to be broken. We generally model without the Association relation as a stand-in for something else. The sign on our wall reads: “association relations are for wimps”. We generally feel that you need to know what you are doing and the Association relation is the easiest way not to think about what you are actually modeling. We constantly force ourselves to be clear. But, with the foundational analysis of secondary and tertiary architectures in mind, we now accept the Association relations as shorthands for more complex relations between roles and our business and IT landscape. Modeling it for real might come later, but we need the shortcuts because not having them makes the analysis and use problematic (or better: practically impossible).

Here is a small bonus view integrating part of the story above and part of the previous post about modeling risk:Missing are the risks and countermeasures related to the IT-part. Here, also, only the relation between a process description and countermeasure process requirements has been drawn. But you can imagine that the Data Policies are (also) part of a countermeasure structure. And you can possibly imagine that if you can link risks to policies or functions to those who are responsible, you end up with a pretty powerful Current State Enterprise Architecture model to support managing and reporting on that complexity.

That is a lot of work. But on the other hand, if you succeed (and a small warning: that depends mainly on your modeling standards and discipline) you are going to weed out a lot of implicit incoherent, contradictory and out-of-date modeling work in your organization, freeing those resources to do something more exciting and valuable.