 But there's more. First of all, we improve the relationships in Archimedes. And one of them is just a renaming of the used by relationship, serving. Used by was the only relationship that had a sort of a backwards name, a passive name, and that had to do with the direction of the relationship. It's very important that Archimedes' relationships point in a certain direction, and especially for used by, there was sometimes some confusion around that. The idea is that this relationship points towards the user of a certain service, for example. That's different from languages like UML, which use the direction of the relationship, also to indicate who is initiating the communication. But for enterprise architecture, it's much more relevant to the mode who is actually the user of a certain service, regardless whether that service is offered proactively or reactively. And that's the reason that the relationship points in that direction, but the name used by was confusing. So it's now called serving, a service, or an application component or anything else, serves, say, a business process or an actor or what have you. Then we slightly changed the notation of influence. We changed the arrowhead because it's now more consistent with the access and serving relationships, and that also has to do with the structure of the set of relationships. Those three are kind of dependency relationships, and we wanted to reflect that in the notation. So it used to look much like the flow relationship, and that created some confusion, so we changed the arrowhead to make that a little clearer. And then, like you just saw before in one of the pictures, we changed the notation for assignment. Instead of having these two black circles at both ends, we now show that it actually has a direction, and if you know the standard, it has this big table at the back showing all the relationships. So you can see that it has a direction there, but the notation didn't show that. So we added this new notation. The old one will stay, well, we deprecated that in the standard, but it will stay correct in argument for a while, so in argument three, you can still use the old notation. It's not becoming incorrect, but I would advise you to use the new notation because it's much clearer to see what is assigned to what. So you typically assign actor structure to behavior, and actor structure to passive structure, or actors to roles. So there is a direction that was already there, but it's not shown in the notation. And then we have changed some other aspects of the relationships. We have relaxed the constraints between the different layers. You can now have serving relationships, for example, between any layers, so the business layer, say people in the business layer, can provide services to the application layer. It's no longer just a bottom-up layering, it's much more flexible. And another one that might be important is that we allowed some relationships to other relationships. So you can associate objects with flows, for example. You can actually model that something flows from one, say, application component to another. You can actually show that a certain data object is flowing there. And another important example is aggregation, so that you can aggregate relationships within plateaus or within a group, and I'll get to grouping later on as well. And then we improved the derivation of relationships, and that's a rather complicated subject. You know from the standard perhaps that there's this story about how you can derive relationships. I don't want to go into too much detail there. I advise you to read the standard there, but we improved these properties as well. These are the two examples of relationships to relationships I want to show you. So on the left you see that there's this insurance policy now related, just with an association, to this flow relationship between policy creation and policy management. So you can actually model what is flowing there. And on the right you see that you can model which relations are part of a set of plateau. We couldn't do that, and that was quite a problem, because if you want to model that between two plateaus, there is, say, an additional relationship implemented between, in this case, two application components, there's an additional flow. You couldn't model that. So we fixed that now, and you can have certain relationships with other relationships. So please read the standard to find out what the exact specification of that is. You can't do this in all places, of course, that would create a huge mess. You wouldn't want to have, say, a relationship to a relationship between an object and another relationship that would become pretty complicated, but you can do several things with this. Then we have added another kind of junction, the OR junction. We have the regular junction, the black dots. Now we have an OR junction as well to denote a fork in the path of a process. So here we have in this example that you can either accept or reject a request. This provides you with a little more flexibility in modeling business processes. We do not want to duplicate BP&MN in any way, so if you really have a need for more detailed gateways or what have you, then please use BP&MN, but this provides you with a little more detail on process modeling. We also added the option to use junctions on more than just triggering and flow relationships to denote explicitly that in this example on the right, sales and finance together realize invoicing. There was a confusion always about having a relationship and having a realization relationship from two different, say, in this case, functions to a service. What does that mean? Are they alternative realizations or do they jointly realize it? Using junction in this way helps you express that explicitly. In this case, these two jointly implement realize invoicing. Then we have improved the grouping concept. Grouping used to be just a graphical thing, just a border around a few parts of your architecture, but it didn't have any relationship with what's inside of that. So it didn't mean anything. It was just a graphical thing. Now in argument three, it actually aggregates the stuff inside the group. What you see on the right is equivalent to what you see on the left. Next to aggregating stuff inside the group, you can also relate things to a group. So you can draw relationships to and from the group, and there's an actual meaning to that. That's explained in the standard as well. There's an actual meaning to this realization relationship. These things inside the group together realize this service. Then there are some smaller changes. It used to be in the business layer. That was a bit strange. The location was used across the entire structure of our community, across all the three layers. So we've moved it to a different position in the set of concepts. For the user, that doesn't make much of a difference, but for the people implementing the standard, they're looking at the structure that might make some difference. And we've also changed the relationship between location and what's on that location. It used to be a sign that aggregation is a much more natural way of expressing this. So location now aggregates what's on that location. Assignment is still valid in many places for this because it's the right relationship that I won't go into the details there. The regular way of doing that is like this, aggregating stuff at a location.