Feedback on ArchiMate 101
Some feedback on various aspects of the ArchiMate 101 document. In general, it is a well-written text and certainly quite useful for novice and prospective ArchiMate users. Some suggested improvements:
- The intro should put more emphasis on the difference between models and pictures and stress the advantage of using a standard in communication.
- I would split off the sections on the importance of viewpoints and tips & tricks for better views from Part I and make that a separate part on visualizing your models, for a number of reasons. First, it is so important that it deserves its own full section. Second, it uses ArchiMate symbology before the language is introduced, so it is difficult to read. And third, the difficulties of visualizing abstract models are better understood if the reader has already seen some of those.
- There is more that could be added to this visualization section. I would also relate it to TOGAF's use of viewpoints and refer to the Guide on using ArchiMate to support TOGAF for readers who want to know how to create TOGAF viewpoints in ArchiMate. And examples of e.g. heatmaps and other visualizations would also be useful. Moreover, let's emphasize that a diagram is only one kind of view; from the same model, you can generate lists (catalogs) and matrices, and various other kinds of output. Too often, people forget about this separation between the model content and its presentation, and critize ArchiMate's default notation for not being business-oriented.
- The subsection on defining your own color palette seems overly specific, and the advice to define one with 20 colors doesn't seem so great. Although it might look pretty, it will be difficult to remember the meaning of all these nuances. My advice would be: stick with the standard colors as implemented in most tools, unless you want to convey a specific meaning with some color, or you need to prettify things for a specific audience (e.g. using corporate colors). And the advice on coloring relationships with the same colors as the elements might not be that great, since element colors are often light (to contrast with with dark text), which makes the relationships difficult to see.
- In the subsection on layout, I would add a reference and explanation of (some of) the Gestalt laws (https://en.wikipedia.org/wiki/Gestalt_psychology#Pr%C3%A4gnanz). See also Enterprise Architecture at Work on that.
- I would start Part II, on the language structure, with an explanation of the subject-verb-object structure of the language, enabling you to 'read' a model as you would read a text. Since this is our innate mental model and is present in all human (natural) languages, it greatly facilitates understanding and is far more important than the system dynamics reference in the intro. This was probably the most important design choice in the entire language. I can write about that. Secondly, the distinction between internal and external is crucial (white-box vs. black-box views of systems). That should also be stressed more.
- I would add pictures with the core and the full framework, filled in with some example concepts. I can provide those if needed.
- In the Coffee Around the Corner example, the term 'module' is used for application functions. In software development, a module is usually considered a separate unit of software implementation (often even in separate files) rather than a functional thing, and hence it would better be modeled as an application component. It would be better use the term 'function' here to avoid confusion.
- I think it is better to base the examples on the ArchiSurance and/or ArchiMetal cases (with additions and improvements as needed), to keep things aligned. The ArchiSurance model is e.g. also used in the novel by the IT4IT team. Moreover, there is already quite some reusable content available for that, from capability maps to IoT examples, all in an integrated model. Augmenting that model then also benefits these other users and use cases.
- In the methodology and/or advanced topics, we should address how you build up your models. Some suggestions:
- When modeling current-state/baseline architectures, import as much as possible from existing sources (e.g. process models from a workflow system, applications and infra from a CMDB etc.) and try to generate views rather than manually creating and maintaining them.
- When modeling the current state, it makes sense to start with the internal and external active structure, because that is the easiest to observe; next, model the internal behavior of these structure elements, then the external behavior (services) they provide via the interfaces (external active structure).
- Conversely, when modeling a future state, start with motivation, then external behavior (required services) and external active structure (interfaces), then internal behavior (processes and functions needed to provide these services), and then how that is implemented in internal active structure (roles, actors, components, nodes, etc.)
- Moreover, to avoid YAGNI and BDUF, in future-state models of the somewhat more distant future, you might only want to model the 'medium-level' motivation (with e.g. planned outcomes and requirements) and required services, and for the very distant future you might limit yourself to stakeholders, drivers, goals and some expected outcomes.
- The advanced topics should definitely address the use of profiles and specialization, also in line with the new AMEFF work, but let's keep it simple. Defining a proper profile or specialization is work for ArchiMate experts, not for the novices this 101 document aims at; however, they may wany to know how to use such a profile.