This is the third time I am writing a post titled “What is wrong with this picture?”. Sadly, I only have this picture and not the explanation that comes with it, but I found it funny enough to put it up for comments.Without much ado, here it is (redrawn in Mastering ArchiMate style):
The most entertaining and precise reply wins a free full PDF download for Mastering ArchiMate – Edition II.
[Update 21/July/2014]
Much has already been said below by the people who have commented. I’ll make a summary that includes their points and my own:
- The use of Business Activity. Business Activity was part of ArchiMate before 1.0, before it became an TOG standard. It was meant to represent an ‘indivisible activity’, which means it was like Business Function or Business Process, but without the possibility to Aggregate or Composite anything in it. The official standard still shows this in Chapter 9, page 115, figure 60 in the top-left corner under the heading ‘Specialization of Concepts and Relationships’. Interestingly enough, the actual example from pre-1.0 ArchiMate in figure 60 is an inverse Specialisation and it doesn’t really fit. Rather sloppy. We can replace in the picture the Business Activities with Business Process (Bill Customer) and Business Function (Manage Customer Interaction) and move on.
- The Assignment relations from the Application Components to the (now) Business Process and Business Function. Assignment from an Application Component to business behaviour signifies in ArchiMate performing that behaviour in an automated fashion. My guess is that the modeller wanted to express that these applications are used, so a Used-By should have been used. After all, it is hard to image that the Accounting System performs Manage Customer Interaction automatically. I would not want to be that customer. So, we change the Assignments to Used-By relations.
- Of course, what is strange is that the Web Developer is performs billing the customer instead of (or at least also) the software development.
- The Customer Business Actor uses the Professional Services Product of which the Software Development Business Service is a part. We can assume that this means that the Customer uses the Software Development Business Service, and the use of the Product is a derived relation of that.
- So, what does it mean that the Software Development Business Service is Used-By the Manage Customer Interaction Business Function and the Bill Customer Business Process? My guess is that the modeller wanted to show that in order to Manage Customer Interaction and in order to Bill the Customer, you need to get information from the Software Development process. A question is: what else than what is coming out of the (now) used applications? Reporting about what happens in the Software Development is essential for billing and customer interaction, but it stretches it a bit to say that, for instance, Bill Customer uses Software Development. Customer billing does not require any software development. If the modeller had wanted to show the relation, I suppose a Flow relation would have been more appropriate.
- Finally we can look at what happens between infrastructure layer and application layer. Realisation from Node to Application Component is a derived relation that means that the software resides on that Node. It is not necessary it is also executed there (e.g. the software could reside on a network server and be executed on another server). Technically, we do not know where the applications run, but we can assume that the Realisation relations were meant as ‘runs on’. This is only modelled for two of the four applications. But what is meant by the Used-By relations from Node to Application Component? My guess is that the modeller wanted to show that the applications use each other. I.e., the CRM application runs on the Windows server but uses the RHEL server where the Time Management application runs. We can imagine that some applications directly make use of services of other applications. In that case, Used-By relations from application to application would have been clearer.
We will not know unless the person who modelled this (and published it on the internet so it came to my attention) comes forward and explains 😉
That leaves choosing the winners: There were many good contributions, than you all. The content winner is Patrick M. with his extended analysis and remodelling. As far as entertainment, I think Philippus nailed it with his first comment.
R&A IT Strategy & Architecture 
I don’t know what’s wrong at an EA level, but I will say I feel sorry for the Web Developer.
LikeLike
Despite the fact that Business Activity is not an official ArchiMate concept (but was at the very begining of Marc’s work), if I remember well it was defined as the smallest part of a process that cannot be split… Here we have several Application Components and Roles assigned to it so that’s not excatly what I call an Activity. All this mix could be a Business Collaboration, but even in this case a mix of automated (assigned to Application Component) and manual (assigned to Role) is really strange (unless a web developer is a robot of course).
LikeLike
Worse than that is that Oscar the cat is missing from the diagram, as the director of operations.
LikeLike
…And I forgot to mention that “Software Development (Business Service)” is used by Business Activities which gives no clue on how it is realized…
LikeLike
The Web Developer only Bills the customer? Does s/he do any web development?
LikeLike
At high level, I can think of following:
Business Layer:
1. What is “Business Activity” component, in terms of ArchiMate Specification?
2. Application Component can not be assigned to Business Activity
Application & Technology Layer:
1. Application Component can not directly use the Node, it should use the Service
2. Application Component can not be directly realized by Node
3. Missing Service from application component which will be used by Business Function/Process.
LikeLike
On your Application & Technology Layer points, 1 and 2 are OK as far as the ArchiMate syntax is concerned. They are derived relations (route 1 via Infrastructure Interface, route 2 via Artifact).
LikeLike
Besides the many possible flaws already mentioned, I think another issue is the unclear message; what is the actual concern this view intends to address.
At first sight the focus seems to be on the “Software Development” service, which is offered to customers as (possibly one of many) services in the “Professional Services Package”. Then you would expect this view to describe the needed capabilities (roles/actors, services, processes, applications, etc) to deliver custom build software.
Instead the focus is on the administrative processes (project admin, time writing, accounting) that support this service. (And a flaw in the model is that the two activities are shown as -using- the Software Development service, it would make more sense it these two activities are part of the larger set of processes that -realize- the Software Development service)
This would have been fine if this is a view concerning the administrative services within the enterprise to support project management and time/expense administration, but then there would be no need to be specific about the “Software Development” Service. Any service based on time and materials would require this same set of internal support activities/processes.
If on the other hand the purpose of this view is to show what is involved in specifically delivering the “Software Development” service, then this view should include that information. The required capabilities to deliver software, which would for example include the Software Developer using Software Development tools (IDE and version control applications), and related infrastructure, possibly even going into infrastructure details for development, testing and releasing the software, which would be more important to realize the Software Development service then the generic project management and time&expense administration.
LikeLike
I think there are many things to question in this diagram.
For example, I searched the Archimate specification. But I could not find anything called “Business Activity”. http://pubs.opengroup.org/architecture/archimate2-doc/chap03.html#_Toc371945155 . Is that a typo or did he make it up? Please correct me if I am wrong.
But for me, the second problem is the Service concept is totally undermined and misunderstood in this diagram. I cannot understand which infrastructure services are provided and which application services are provided. Also the Software Development should not be depicted as a Business Service.
A business service is defined as a service that fulfills a business need for a customer (internal or external to the organization).
An application service is defined as a service that exposes automated behavior.
An infrastructure service is defined as an externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment.
LikeLike
Business Activity was in ArchiMate before the 1.0 version of The Open Group. It is still mentioned as a possible specialisation in Section 9.2 on page 115 of the standard (though with a twist). This, however, is in my view a part of ArchiMate that is somewhat messy. I describe the mess more detailed in Section 27.1 of the book.
I think that it is fine to have a Software Development Business Service if software development is the service you offer to your customers.
LikeLike
Agreeing with much of what has already been said, the Uses relationships also seem to be completely the wrong type of relationship between the Business Activities and the Business Service. I would rather have used a Realizes this business service of “Software Development”. Also not sure what the Generalization Relationship is between the Nodes and the Components? (or is that supposed to be a flow relationship?)
LikeLike
The relations between the Nodes and the Application Components are Realisations.
LikeLike
OK thanks – well that’s clearly wrong as well 🙂 Hardware being realized out of Applications/Components mmm interesting. Magic.
LikeLike
Actually, it is not wrong 🙂 The Applications are Realised by the Nodes and there is a valid way to do that in ArchiMate.
LikeLike
Oops – you are right! I somehow thought the arrows were pointing the other way. Sorry.
LikeLike
There is no Contract depicted in the diagram. This is possibly a services company Business Architecture diagram. A professional services package Product without at least one Contract aggregation or composition looks vaguely defined for me.
There are no passive Business objects like Invoice or bill associated with Business Activities.
I also don’t get how the Business Activity are triggered by Events in this diagram. How does the Customer Business Actor enter Feedback? How does Customer get the bill or pay the bill? Which interfaces do they use for business interaction? etc…
LikeLike
The assignment relationship between the Application Component and Business Activity is very interesting!
The assignment relationship links units of behavior with active elements (e.g., roles, components) that perform them, or roles with actors that fulfill them.
LikeLike
Please explain ‘interesting’. Jean-Baptiste also mentioned these Assignments, but is there a problem with them?
LikeLike
I would rather prefer Used By relationship type instead of Assignment. Application Component realizes Application Service, which is Used by Business Function or Business Activity.
LikeLike
An application is assigned to a business behaviour element when that business process is fully automated. According the text that is not the case here. The assignments of application to the Business action shoud be ‘used by’.
LikeLike
There seems to be a lot of infrastructure in place to bill a customer for a service that nothing or nobody is providing.
LikeLike
Gerben, my 2 cents worth
First I modelled the diagram myself (In Abacus as I can set up different types of connection constraints for direct and derived connections). In setting up the model I assumed that Business Activity was a type of process.
I then checked the derived relationships. Between the Nodes and the Application components there were some derived relationships but I could expand these by adding ‘Hidden interfaces’ which were Used by the Application component and in turn were used by the Nodes. I also added ‘Hidden artefact’ and ‘Hidden Infrastructure service’. The Node is used by the Hidden Infrastructure Service which access a Hidden Artefact which in turn realises the application component. So syntactically no problems here.
By replacing the Business Activity with a Business Process I can use direct assignment connections between Application components and roles. The Software Development Service can also be used by the Business Process. Again no problems with the syntax.
Working my way upwards I have a derived ‘Used by’ relationship between the Business Product and the Business Actor. Now a business Product generally aggregates services so there is probably a Hidden Business Service that is aggregated by the Professional Services Package which in turn is Used by the Business Actor Customer. So syntax again could be OK (although I have questions how a stronger ‘Aggregation’ would resolve to a weaker ‘used by’ but it tends to make sense.
So if the syntax is kind of OK the reality is that the Customer is using a Hidden Business Service that is aggregated by the Professional Services Package. The Professional Services Package also aggregates the Software Development Service. The original diagram seems to imply that the Customer is using the Software development service which may be possible but not necessarily correct. To use a service aggregated by a business product does not mean that ALL services aggregated by the Business Product are used. Kinda like going to the clinic for a check up and ending up with a vasectomy.
LikeLike
[Edited July 13, as I made a mistake, you were right to say the Product Used-By the Customer is a derived relation from Product via Software Development service to Customer]
You’ve made quite a complete syntactical analysis and indeed the syntax is not the problem.
It is safe to assume that the idea of the picture is that it is meant to model the situation where the customer is provided with software development services (a project on time and material basis).
LikeLike
If the syntax is correct it’s the semantic.
The Software Development service should be realized by the two business activities instead of used by.
LikeLike
Just making the diagram more readable
• Managing ‘customer interactions’ and ‘billing T&M’ is not really a software development service. I would expose them as a service and bring them in as aggregations of the ‘professional service package’. In that case I can get rid of the ugly used by(s).
• I think, in general, that a ‘Software Development’ service not is used by a ‘manage customer interactions’ process or a ‘Bill T&M’ process. (If I would really want to model that, it should be an realised instead of used by.
• How the ‘software development’ is composed it not shown in the diagram. Although software development and web development is a different thing, I think it is something de ‘Web Developer’ realizes: I omit de ‘Software Development process’ from the diagram and would draw a realisation from de ‘Web Developer’ to the ‘Software Development’ service.
• Assuming the ‘Bill T&M’ is an automated process, (as the process is modelled as an assignment to the T&M application and ‘Expenses mgt Application’, I would leave that so. I would externalize the manual functions for that process and assign the roles to it. I would add (automated) to the text.
• Process ‘Manage customer interactions’ seems me an interactive process and so not too automated. So I would change the relation between the application and the process into a ‘used by’ relationship. I omit the functions and the services the CRM and Accounting systems exposes.
If I would do that all, it would look like as : http://www.cahybel.com/exportedresult.jpg
LikeLike
I think Patrick made very good points, and the updated diagram describes a more realistic scenario then the original view.
A suggestion may be to model the “Enter Expenses” and “Enter Time Spent” as processes, with Triggering or Flow relationships to the “Bill T&M (Automated)” process.
Also for clarity I would suggest to show a process called “Develop Software”. The Web Developer would then be assigned to two processes: “Develop Software” and “Enter Time Spent”, with the “Develop Software” process realising the “Software Development” service. No need to go into details how this “Develop Software” process then possibly uses other services (tools etc) but just to set the accent right, that the Web Developer is assigned to a development process resulting in a product with value that the customer then is willing to pay for on a T&M basis. Otherwise the Project Manager will be very busy indeed with Managing Customer Interactions.
LikeLike
Many good points so far. Some entertaining ones too 🙂
Hint: Nobody has commented yet on the setup of the Nodes and the Application Components. But what did the modeller probably want to show? And if that is the case, what would have been better?
LikeLike
I would consider an Infrastructure artifact realizing the Application component instead of Node or System Software.
LikeLike
I was wondering if the application components want to use the other applications realised by the nodes rather than the nodes themselves. It’s pretty ambiguous the notion of an application using a node.
LikeLike
My guess was the same. I guess everything has been mentioned now, so I’ll look into publishing the analysis.
LikeLike
It is possible that the author deliberately wanted to indicate the dependency with the servers without revealing the reason. Now it is about imagination. The used by should be inflated to reveal their reason of presence.
Suppose I want to provide a print service to the expense management system application to be able to print invoices. I see printing as a part of the technical infrastructure and I want to use the windows print service. I will expose the CRM Systems realisations as well.
For the accounting and the CRM system, I want to explain the ‘used by’ as a need of mail capabilities on the RHEL server. I don’t know if a mailer is part of a RHEL deployment. Let assume yes, so that I can do a similar thing as with the printer server. This time, for the fun only, I don’t want to show the mail service interface, but walk on the functionality path that deployed mailing feature exposes.
LikeLike
Where are the enthousiastics ?
LikeLike
I’ll write up the remarks today or tomorrow.
LikeLike
I observed in your book that in none of the views, a node directly realises a application component. I hadn’t framed a question, but I thought it was peculiar. What is the reasoning that you assign the node to an artifact, and let the artifact realise the application component? Or is it nothing more than a coincidence?
What I find weird in the example is that a windows node realizes a application component and a rhel node is used by the same application component. I think the author could have clarified that better, and that might explain why you associate artifacts to a node.
LikeLike
A Node may Realise an Application Component, but the relation is a derived relation from Node – Assigned-To – Artifact – Realises – Application Component. The meaning of that is that the Artifact is the `physical’ distribution of the application. E.g. the Node is your desktop PC, the Artifact is word.exe (and all its support files, together forming the distribution) and the application is Word. It is not a coincidence, it is the official full route. But you can make a shortcut of that route with only Realisation, so Node – Realises – Application Component. See Section 1.5, Section 3, and View 37 in the book.
(BTW, I don’t Associate Artifacts with the Node, I use Assignment and it is one of the Core elements in ArchiMate to show where an Artifact resides in your infrastructure.).
LikeLike
Indeed assigned was the better word. Patrick M his drawing makes more sense. A RHEL server runs services which provide functionality/capabilities to application components. Or at the minimum the artifact of a alternative (windows) node realises the deployment/hosting of a application component. The partial answer to this puzzle clould be, that the author omitted too much infra building blocks to avoid confusion around the CRM component. I think the original author probably drew this from an infrastructure as a utility perspective, and inadvertently conflated component and system to avoid dealing with the infra layer.
Al credit goes to Patrick M.
LikeLike