Modelling IT in Your Organization, a Broader Perspective

As Enterprise Architects, we model the use of IT in an organization and ArchiMate is a decent language for  that. ArchiMate, with its business layer, application layer and technical layer helps us to model the different aspects of that use.

And after we have modeled business processes/functions and their use of IT services, and TI Services and their support of Applications we have the complete picture. But do we?

Soon, somebody starts to ask to add the ‘owner’ of an Application. And the easiest way to do it might be to add a property to the object in our tool of choice or to add an Actor with an association relation to  the Application Component. Hmm.

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.

Well, I think we can do better. For one, if we say there is an Actor who has a Business Role ‘owner’, why not model this as a normal ArchiMate Business Role? And that begs the question: if we have an owner business role, what does an owner do? What is the owner’s behaviour? And what does he act on? Well, if you think about it, the owner is in the end responsible for the requirements. He is the one that decides how the application changes. Even in a project, your project executive is the final judge of what shall be produced, even if an architect creates the design.

And there are more roles. Think of your run organization, keeping all those servers and desktops running. Or the application managers. Or the developers. They all have a relation with the application that is so successfully used in your business processes. An overview can be seen in the image below (opens in a separate window)

Here are some notes of interest:

• The same artifact that realizes an Application Component for the user, realizes a Data Object from the development perspective. The developers do not use the application, they use a different application to change the executable which for them is just a Data Object.
• An application may have configuration screens which are typically used by Application Managers. Or it may be configured using .ini files that are changed by Application Managers. Both are modeled in this example.
• The run organization doesn’t use the application, but it uses different systems to make sure the Technical Infrastructure is up and running. Normally, they have Service Level Agreements covering the uptime and such.
• But suppose our organization wants to become more professional and offer SLAs on the Application Service level? Interestingly, they are then offering an SLA that can be influenced by both the developers and the application managers. So, can they offer that at all unless the developers and application managers are part of the same organization? And is it wise to make application management part of that organization or should it be part of the ‘demand-side’?

More explanations in the yellow sticky on the lower left of this view.

What could be the use of modeling more than just the use of an IT system in your business processes? Well, for instance, what if you need to have a model for auditing purposes (e.g. SAS70) to see if you are in control? Would it not help to be able to show how the application’s behaviour can change (change, own-requirements, application management) as well and have auditable procedures there too?

And another use is when writing a Project Start Architecture. Wouldn’t it be nice not just to model the use of the system in the business processes but also what is needed to run or maintain the system? For instance, suppose your app needs to be operational 18/7, explicitly having exploitation requirements in your PSA and designing exploitation as well could be helpful. At least it minimizes the risk that you find out 4 weeks before going live with your 18/7 app that system maintenance and backups take 24 hours…

I tend to think of the green groupings as the ‘primary architecture’. Application Management and your run organization are the ‘secondary architecture’, without these, you still haven’t caught everything that is needed to actually use the system in your business. And Ownership/Development are the ‘tertiary architecture’, I personally think that there will be no need to model this at all, unless you have strict auditing on application behaviour and how that can change.

I have set up a download on mediafire for the BiZZdesign Architect v3 xma file of the above picture: http://www.mediafire.com/?tf320ehkb3kpo14. This is a free service, so prepared to be hit by a pop-under window and flash with ads. If someone knows a better service, tell me.