What is wrong with this picture?

on by 42 Comments

As I was looking at materials to review, I came across this diagram:

Original Telebanking View from AM2 Specification in GW Style

Before I write more: can you say what is wrong with it? Please add your comment below.

Update Sep 12, 2013: Here is the explanatory text that came with the diagram:

A bank offers the product ‘Telebanking account‘ to its customers. Opening an account as well as application support (i.e., helpdesk and the like), are modeled as business services realized by the ‘Customer relations department‘. As part of the product, the customer can make use of a banking service which offers application services realized by the Telebanking application, such as electronic ‘Money transfer’ and requesting ‘Account status’.

Update May 2015: For convenience, the answer is here.

42 comments

  1. Hi, do you think of the “used by” relationship between application service and business service? I think these are derived relationships, but what else might be wrong?

    Like

    1. The fact that a relationship is derived does not make it wrong. But what happens if you expand them? Of what situation are they a derived relation?

      Like

  2. An actor cannot realize a service like Open Account and if we are talking about derived relationship then it won’t be “realised” ast it is tronger than assigned.

    Like

    1. That is not it.

      The Actor can Realize the Business Service: Business Actor – Assigned to – Role – Assigned to – Business Process – Realizes – Business Service. Realisation is weaker than Assignment, so the result is Realization.

      Assignment is allowed too, via Business Actor – Assigned to – Role – Composes – Business Interface – Assigned to – Business Service. Here, Assignment is the weakest.

      So, Realization and Assignment are both allowed.

      Like

  3. The picture seems to suggest that Customer (Actor) uses Application support (Application service), which is probably not the intention of the Aggregation into Telebanking Account (Business Product).

    Like

    1. That is not it.

      I think it is fine that the telebanking customer uses application support when he uses the telebanking application. Probably, the Business Interface for that helpdesk is Telephone. This customer can
      – Open an Account
      – Use the telebanking System
      – Call the help desk

      Update Sep 13 2013: BTW, Application support is a Business Service in the diagram, not an Application Service.

      Like

      1. I’d say that if the name Application Support implies that the customer can use an application to manage his account, that it is not correct then to say that the Customer-Relations department realizes that service. It must be an application that realizes it.

        Like

      2. I’m afraid that is not it.

        It is perfectly OK that Application Support is a human-performed process. It does not mean ‘application supporting your telebanking’ (that is what the application services on the right hand side are for). This is a typical human-performed operation, e.g. a Help Desk, that supports you when you have problems with the application.

        Like

  4. It seems to me that the Contract is an informational element that is the result of the Product group of services. It should be the result of the Telebanking Account rather than a part of it. Also, the Service Account Status seems for informational than behavioral and should probably be better represented as a data object, with an Access relationship from the Application Component and a Used By relationship to the Banking Service.

    Like

    1. That is not it.

      Contract is an element that is defined in ArchiMate as being a proper part of a Product. Nothing problematic there.

      The “Account Status” Application Service might be better named “Showing Account Status”. But that it is not perfectly named is not wrong. It is an Application Service and that is fine.

      Like

      1. My suspicion was that a Product id must be used by another element. Here I see a Product ‘Telebanking account’ uses an Actor ‘Customer’.

        Like

      2. As it is drawn in the diagram it says: the Telebanking account Product is Used-By the Customer Actor. I’m afraid you have the Used-By interpreted the wrong way around. In fact, that is why it is called a ‘Used-By‘ and not a ‘Uses’.

        Like

  6. Note to/hint for all: I am not looking for a technical problem, this diagram is proper ArchiMate. I am looking for a problem with what this diagram actually says.

    I have added the explanatory text.

    Like

    1. Technically, there is no derived Used-By from any of the Services inside the Product to the ‘Customer’ Actor in the diagram, so you might be right to say that none of the Services modelled are Used-By the ‘Customer’ Actor. However, I would still have my problem if the Used-By’s from each of the Services to the ‘Customer’ Actor would have been added explicitly.

      This use of the Product concept generally is interpreted as ‘the Customer Actor uses all the Services that are part of the Product’.

      Like

  8. Seems to me the “Contract” should apply to the overall product, not to the single business service “Open Account”. In this diagram, the Contract is created (access) by the Open Account business service. It’s almost like the “contract” is thought of more as a business object that will subsequently be realised as a data object in the application layer, than a contract that will govern the overall Telebanking Account product.(Of course, contract is a specialization of a business object.)

    Like

    1. That is not it.

      I think it is proper that Contract is both an Aggregate part of the Product (and via that Aggregate applies to the overall Product) as well as that it is created by the Open Account Business Service. In fact I think it is rather a neat way to model both aspects of a Contract, the aspect that makes it govern the Product and the Business Object aspect (a Contract is a specialisation of a Business Object after all) that it is also created.

      Like

    1. You are hinting for ‘meaning’ rather than ‘correctness,’ so I will give it another shot.

      If one follows the derived relations between Customer and Contract, it is the Customer who creates the Contract (Customer – uses – Telebanking Account – aggregates Open Account – accesses – Contract implies Customer – accesses – Contract, and by arrow direction: Customer – writes – Contract). One would at least expect a check by Customer Relations before Contract is created.

      Like

      1. That is not it.

        It is the Open account Business Service that creates the Contract. The Customer uses that service, but who provides it? The bank does, so it is the bank that creates the Contract. Besides, your derived relation follows two relations in opposite directions: Used-By from Product to Business Actor and Aggregation from Product to Business Service. You are not allowed to draw a derived relation that way.

        Note that if you would be very strict about two sides creating the agreement (Contract) together, you would have to model a Collaboration to create the Contract.

        PS. There are three hints on the page. Hinting for ‘meaning’ is not the only one 🙂

        Like

    1. That is not it.

      There is of course a lot missing in this diagram, but that in itself does not make it problematic. Leaving stuff out is allowed after all.

      In this case, if you would add the Create Account Application Service, Realized by the Telebanking application, it would be used by the Customer relations department. But that would not solve the problem I see.

      Like

  11. It kept me awake this night 🙂 and I give it a last try.
    I find it strange that service ‘application support’ (..helpdesk and the like..) is aggregated part of the product ‘Telebanking account’.

    Like

    1. That is not it.

      I think it is absolutely proper that as part of the Product the Customer also receives help desk support via Application support (which might have been better labeled as Customer support as it is about supporting the customer when he uses the application. Traditionally, in IT, this is often called Application Support.). The Product is more than just access to the application.

      You could argue that Open account should be outside of the product as it creates an instance of the Product, but that is not the problem I see and, besides, it is proper to do it this way. I think that is just a matter of taste.

      Like

  12. My last try… or it’s graphical, the business actor (Customer relations department) and Application Component (Telebanking application) at the same level… Or it’s the business actor (Customer relations department) that should be a role that perform a specific behavior

    Like

    1. That is not it.

      Such issues are not substantial enough to label it as a problem that is serious enough to turn into a blog post. That is true for lay-out and for the use of derived relations in general (e.g. Customer relations department directly Realizing the Open account and Application support Business Services, which are valid derived relations).

      Recap:
      – It is not layout
      – It is not the fact that details are missing
      – It is not a syntactical problem

      Like

  13. I sincerely appreciate that you all are taking time and have the courage to answer. I hope to repay you buy seriously answering all the suggestions and I hope it is both entertaining and educational in the end 🙂

    Like

  14. Interesting discussion! Let me try.

    1. By which actor is the Banking Service realized (or is the responsibility ‘automized away’, or do you consider it a detail)?
    2. Can I also close an account (support of complete lifecycle of a banking account)?
    3. The explanatory text doesn’t say anything about Contract (so an inconsistency?).
    4. The explanatory text writes ‘such as’ so there may be more application services, though looking at the diagram the conclusion is that there are only two.

    I am curious as to what your solution is.

    Like

    1. Do you mean that you think the problem is that the performer of Banking service is missing from the diagram? Because missing elements and relations are not a problem in themselves.

      The problem is not that the diagram can be extended or is incomplete.

      That was not what I have in mind. This missing explanatory text is not a problem, it does not make the diagram problematic. The problem would also be there without the explanatory text.

      See previous item.

      Like

      1. Ad. 1: Quote: “I am looking for a problem with what this diagram actually says.” => It says that for two business services there is an actor ‘assigned’ and for one business service there’s no actor. I would consider that as problematic. You maybe see this as a missing element which is not a problem in itself). Or you consider the actor to be present in the derived ‘used by’ relationship.

        Like

  15. A very, very last try then and I give up.

    Via the derived relations one could conclude that ‘Account Status’ and ‘Money Transfer’ are used by the product ‘Telebanking Account’, what is a contradicting conclusion as they are explicitly modeled as aggregated parts of ‘Telebanking Account’

    Like

    1. I don’t think you can conclude via derived relations that the Account status and Money transfer Application Services are used by the Telebanking account Product. But you are close.

      Like

  16. We are close. Jan in the first reaction was already close. Jacob and Patrick are close too.

    Remember: it is not so much that something is missing. It is something that presents us with a problem (e.g. a wrong conclusion to draw from this diagram).

    If the problem has been stated (or almost), I will publish my solution.

    Like

    1. Who uses the telebanking application: the customer or another actor or a role that is assigned to the ‘Banking Service’ sevice (and is hidden in the ‘used by’ relation)?

      Like

      1. Bingo!

        As it is modeled, the Application Services are Used-By the Bank. If you replace the (derived) Used-By’s from Application Service to Business Service, you get a Business Process (or Function) in between that is Bank behaviour, not Customer behaviour. I’ll publish my longer answer with 3 alternatives.

        Like

      3. You did win a spelling/grammar course… 😉 Sorry, I am in a weird mood.

        Seriously: What about a free license for Mastering ArchiMate. Just send your name/address details and if you want an electronic or print license and I’ll get you one.

        Like

  17. Pingback: What was wrong with that picture? | Mastering ArchiMate

Comments are closed.