Function, Service, Process

July 23, 2011 at 3:43 pm 5 comments

Part of my day-to-day job consists of providing analysis and modelling support to IT projects. That usually means documenting the status quo and the target architectures in the form of “functional diagrams”. I put this in quotes because there seems to be no single standard for what constitutes a functional diagram.

“Function” in ArchiMate refers to a grouping of internal behaviours, both at the business level and the application level. In theory, ArchiMate functions are not intended to be directly exposed to other layers; functional behaviour should be exposed through an interface.

Gerben Wierda discusses this very topic at length on his ArchiMate Musings blog. He shows how processes can be related by a hierarchy of functions, which probably reflects the reality of many implementations.

To me, however, the ArchiMate notion of “function” contradicts somewhat how function is typically understood and drawn outside of ArchiMate. Most of the functional diagrams I have seen relate actors to some expected application behaviour.

So instead of using business or application functions, I often find myself speaking in terms of a business service that is realized by one or more processes, themselves related to applications that everyone knows. Actors can be added to delineate user roles (see comment below on this).

Here is an example of how I modeled a contact center process for reporting network outages. In this simplified view, a Customer contacts the call center and speaks to a Technical Service Representative (TSR). One of the business services offered by the contact center is Outage Reporting, and the only way to access that service is through a telephone call.

Business service realized by business processes and an application

The realization of the Outage Reporting service involves multiple business processes. These are modeled as fairly fine-grained processes because I wanted to show how only part of the overall service was automated.

Note the use of Actor icons instead of “roles” that the ArchiMate specification encourages. I find the notion of “role” to be a little abstract for some people. That’s why I often skip it and depict actors instead. Everyone understands a stick figure.

In the real life there are significantly more details than are presented here, but this view (which was part of a much larger overview of call center processes), captured enough detail to satisfy the project team.

Obviously, much more could be added to this diagram, but I kept it fairly simple. In fact, another set of diagrams describe the applications and their interaction with data and hardware. That’s for another blog post, though.

Advertisements

Entry filed under: Business Layer.

Introducing Practical ArchiMate

5 Comments Add your own

  • 1. Magnus Billgren  |  July 24, 2011 at 12:20 pm

    How does ArchiMate relate to Bpmn?
    We normally used it for modelling processes and a foundation for systemt together with an information structure.

    Reply
  • 2. Tracy Rosen  |  July 24, 2011 at 12:55 pm

    Your first paragraph might lend support for it to be called a dys”functional diagram”.

    Reply
  • 3. doug beeson  |  July 24, 2011 at 1:29 pm

    Good to hear from you, Magnus. BPMN supports low-level, detailed process modelling through its branches, messages, loops, etc. I have even seen products such as WebRatio (http://www.webratio.com) that build functioning web applications directly from the BPMN.

    ArchiMate does not go so deep. A “business process” is typically depicted as a single model element (fat arrow). ArchiMate then allows that business process to be linked to other business-level elements such as interfaces or be “realized” by componenets in the application layer. That is how we (at Cogeco) indicate partial or full process automation. Manual processes are indicated by a link to business role or actor.

    Reply
  • 4. Adrian Campbell  |  July 27, 2011 at 4:05 pm

    ArchiMate is flexible enough so that one can model with Business Functions, Business Service or Business Processes as appropriate.

    I often model Business Services from the external customers perspective, where the Business Services are realised by internal Business Processes. I use Business Functions for higher level groupings of Business Processes (i.e finance management) that are closely associated with Organisation Units (

    In ArchiMate Actors are used to represent named organisations (i.e. Tesco) , organisation units (i.e. Finance department) and named individual people (i.e. Joe Bloggs), whereas I use Roles for things like ‘Customer’, ‘Regulator’, ‘Supplier’, ‘Tech Support’ etc..

    The Role object in ArchiMate is equivalent to the Actor object in UML (represented by a stick man symbol) which is conceptually used as a Role object. This is why many people misuse Actors instead of Roles in ArchiMate.

    Reply
  • 5. Richard Davis  |  February 12, 2013 at 5:44 pm

    I am a bit late to the party here but I found your post whilst searching for thoughts on Archimate’s relationships between functions, services, components and interfaces. My own thoughts are that functions are a little redundant in Archimate but are included simply to fulfill the basic premise that all three architectural layers can have behavioural concepts as outlined in the Archimate
    specification.

    The reason I think they are redunant is that the specification allows structural concepts like Application Component to both realize a service, and aggregate the interface through which the service may be accessed. If you use functions to realise services and components to aggregate the interface, then assign them appropriately you will almost always end up with a 1 to 1 relationship between functions and components which doesn’t seem right to me.

    As an aside I’m not sure you have the relationship between functional behaviour and interfaces correct. Functional behaviour is actually exposed through services which in turn are accessed through interfaces. Functions and services are behavioural whilst interfaces are structural. I’m also not sure what tool you are using for diagramming but your view does not strictly conform to the archimate specification as far as I am aware. An application component cannot realise a business process rather it can be used by or assigned to a business process. I understand what you are trying to say though.

    Reply

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

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendar

July 2011
M T W T F S S
     
 123
45678910
11121314151617
18192021222324
25262728293031

Most Recent Posts


%d bloggers like this: