Like the hard-headed guy I am, I went all lengths imaginable with one of my friends on the need for an architecture description language in our line of work. This guy who I would imagine had a better grasp of architecture than I do and continued insisting on there is no need to use any architecture language across the EA practice. Well, we were explicitly were discussing Archimate, which adamantly I have less knowledge about it, but I was still insisting that it is one of the few languages that wasn’t incubated within academia (ACME, Wright, ByADL, and likes) but instead was first developed by an open standard community.
Now the focus on the argument was the need for glue to capture the semantics of architecture components. UML, for example, is only a representation, a symbolic, a notation language. It captures how components of a system interact with each other, like the use case or a class diagram, but never achieves the semantics that actually links each model with each other. So you have a use case for a financial domain? Well, good luck in trying to tie that birds-eye view to the component diagram or activity diagram. To simplify the problem, then how to link the artifacts from UML, or whatever modeling you want, with the overall context of the enterprise?
Now here where Archimate comes into play; it doesn’t try to engineer your software but wants to make sense of what is going on.
In its core metamodel, it classifies what goes on in your enterprise as either an active structure (doing something), a behavior (what is being done?), and a passive structure (action is done to what?). And from there it starts to expand to cover almost everything from the reason the enterprise exists (strategy and motivation) until the infrastructure components of your enterprise.
I haven’t fully engaged in Archimate but my near future focus will be dedicated to it and hopefully, it helps me in gaining an understanding how an EA could better help the whole enterprise.