What is wrong with this picture?

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’.

This entry was posted in Discussing ArchiMate, Using ArchiMate. Bookmark the permalink.

42 Responses to What is wrong with this picture?

  1. Jan says:

    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?

    • gctwnl says:

      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?

  2. AJW says:

    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.

    • gctwnl says:

      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.

  3. Joost says:

    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).

    • gctwnl says:

      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.

      • Carl Seghers says:

        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.

      • gctwnl says:

        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.

  4. Dave Manning says:

    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.

    • gctwnl says:

      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.

  5. Patrick says:

    What about the Telebanking account that uses the customer?

    • gctwnl says:

      Patrick, can you explain what you mean?

      • Patrick says:

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

      • gctwnl says:

        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’.

  6. gctwnl says:

    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.

  7. Bruno says:

    i believe that the client doesnt use the application servises… it should be out off the product..

    • gctwnl says:

      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’.

  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.)

    • gctwnl says:

      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.

  9. gctwnl says:

    Nobody seems to have noted a hint I have provided :-)

    • Joost says:

      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.

      • gctwnl says:

        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 :-)

  10. LBer says:

    There is an Application service missing to Create an account in the Telebanking application.

    • gctwnl says:

      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.

  11. Patrick says:

    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’.

    • gctwnl says:

      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.

  12. Bruno says:

    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

    • gctwnl says:

      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

  13. gctwnl says:

    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 :-)

  14. Jacob Vos says:

    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.

    • gctwnl says:
      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.
      2. The problem is not that the diagram can be extended or is incomplete.
      3. 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.
      4. See previous item.
      • Jacob Vos says:

        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.

      • gctwnl says:

        You are close with your final sentence.

  15. Patrick says:

    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’

    • gctwnl says:

      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.

  16. gctwnl says:

    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.

    • Jacob Vos says:

      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)?

      • gctwnl says:

        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.

      • Jacob Vos says:

        What did I won now? ;-)

      • gctwnl says:

        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.

      • Jacob Vos says:

        Sorry, I thought I learned at school “to win – won – won”…

        Nice offer! I’ll sent you my details. And have a nice weekend.

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

Comments are closed.