 Then there are various general improvements to the language next to the more detailed stuff. I just showed you We have simplified various definitions Some definitions were very long and wordy It could be rephrased could be simplified and we also aligned definitions within the language If you read the standards closely, you would you would see that for example the definition of a service in the three different layers So business service application service and technology service And those definitions were slightly different But we've now made them much more similar which makes it also easier to learn the language and that across the framework So we have done that in various places Then we changed various definitions to increase the alignment with toga This harmony project I introduced at the beginning has taken a critical look at the definitions in both frameworks as Look at the correspondence between these these two different standards And come up with suggestions for improving the definitions and that's what we Implemented in the new version of argument as well As you may know people are working on the next version of the toga standard to This is still a work in progress But hopefully they will also implement some of these changes there so that we increase the line from the other end as well And come up with a more coherent set of standards within This does not mean that you can only use argument with toga for vice versa, but they are better aligned Then there are some changes to improve consistency of argument So one example is that we change the name of some of the concepts You might remember that in the technology layer everything was called infrastructure something Well, that's a bit strange in the business layer was business something Why was it infrastructure something so we renamed that to technology something? That's much more logical than we know what we have So that's just a change of name of several concepts It doesn't make any difference for the meaning or the notation of the concept, but it's just a name change Another change is that we added some concepts to create more more Symmetry between the layers in the standard At the business layer we have business process business interaction this collaboration at the application layer We used to have application function And application components application interaction, but we didn't have a process concept So at the application layer we now added an application process concept that helps and it helps you express things like orchestration processes So that's a new concept there. We already had interaction collaboration But the technology layer we didn't have either of these we didn't have a process We didn't have a collaboration So those were added to that layer as well. So now you have the same set of concepts across these three layers When it concerns behavior when it concerns collaboration Furthermore, we also added an event concept at these layers We had a business event of course, but there are also application and technology events say if a server fails that might constitute a technology event and you want to model those and We even added an event in the implementation and migration set of elements because For example, that's a deliverable is ready is also an event and events Can be attributed with a time stamp to denote when something happens and this also helps you especially in this implementation migration world to Model planning and model road maps etc. So you can't see when certain things are ready or must be ready and model that using events This is the only place where we put in a time notion We didn't want to complicate things further than that We didn't want to put it for example in Processes you could argue that you might want to have time processes, etc But argument doesn't want to have the say the details of a language like BPM And it's not about detail process modeling. So we avoided that but we can model events With time and that provides you at least some structure for mapping this onto the time dimension Well, then there are various other kind of changes all the examples across the document have been Replaced we used to have very small examples with each concept But we replaced them with a smaller number of larger examples that show these concepts in context That's easier to understand. It's more useful and the concepts are more lifelike in that way We also removed the use of the word extension We used to have the motivation extension and the implementation migration extension And it sounded a bit like sort of an optional add-on to the standard But they are an integral part of the language and not just something optional So the word extension was a bit misleading and we'll simply replace that by elements So you have the motivation elements now We also added an appendix describing the relationship with several other standards for creating new tables and relationships So those are also various Minor additions while the table of relationships as a big one But those are the things that are less obvious to the user of our committee Then there are a few changes in notation We abolished the required interface notation. We noticed that hardly anybody uses them It's sort of awkward. So that's been removed. It also didn't have a good position in the meta model Because it was an interface with the strange kind of interface sort of a missing interface So this this didn't really fit the structure of our committee And then we changed the notation representation contract slightly because it looked like deliverable and business objects respectively, so By adding an extra line to the notation you can now easily see the difference so contract has a line at the bottom as well And representation line at the top it just to make the difference a bit clearer Another thing to make the language more readable, especially for example when you print it in black and white or Create complicated diagrams with lots of layers or structure We added an optional notation Where you can denote the layer or aspect of an element by having a letter in the top left-hand corner So for example a B for the business layer if you have that in the top left-hand corner You can use that to show that it's a business layer concept You know that say service is denoted in the same way across the layers and this helps you identify What layer you're modeling in in a multi-layer picture? So just showing an example of that here we see these letters for a layers picture of our Example company our insurance we see that it's business process for handling claims and then the Application supporting that and then the technical infrastructure and you see the B a and C letters in the corner So this is an optional notation another blight to use that but you can and Helpful for for say printing in black and white why you don't have these three colors to show things and color in any In any case has no official meaning in argument. So you have more flexibility this way