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)

An overview of roles surrounding the use of IT

An overview of roles surrounding the use of IT

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.

This entry was posted in Using ArchiMate and tagged . Bookmark the permalink.

16 Responses to Modelling IT in Your Organization, a Broader Perspective

  1. Peter says:

    This is a good starting point – any chance of a .xma file?

  2. Pingback: On the use of Colours in ArchiMate | ArchiMate Musings

  3. doug beeson says:

    This is really eye-opening, thank you. I can see a real use in our company for modeling (and explaining) our response to C198, the “Canadian Sarbanes-Oxley”, which has led to significant impacts at all levels. We have had to change business processes, build new applications, install new people as the overseers of said processes and applications…all the stuff you have modeled here.

  4. Pingback: Business Process versus Business Function | ArchiMate Musings

  5. Pingback: Application Deployment Patterns | ArchiMate Musings

  6. The http://www.mediafire.com/?tf320ehkb3kpo14 URL returns an HTTP 404 error.

    Would it be possible to fix the link ?

    Thanks

  7. Pingback: Modeling Risks (and Security and more) | ArchiMate Musings

  8. Pingback: Simplified modeling of roles related to IT | ArchiMate Musings

  9. Pingback: Why is Stakeholder not a Role in #ArchiMate? | Mastering ArchiMate

  10. Pingback: Database Triggers in #ArchiMate — And a Wish | Mastering ArchiMate

  11. Pingback: ArchiMate 3.0: The Good, The Bad, and The Ugly | Mastering ArchiMate

  12. Pingback: Who’s in Charge? (Layers? What Layers! — 2) | Mastering ArchiMate

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s