Companies usually deliver the IT changes by projects. And projects have a tendency to do jut enough documentation to pass any governance. Lack of time or competency drive the level of documentation. Technical resources who pretend to be architects draw boxes and arrows-based models in presentations. They add few terms that they understand or things they think business people will understand into those boxes. This may be fine to meet the project deadlines as long as everyone kind of understands what needs to be done to deliver a change.
It is difficult for teams who try to make changes to these systems once the project is over. The boxes and the arrows won't any make sense to others if they are not being explained. Some tend to mitigate this by adding text around these boxes. All these project docs are disconnected and usually no one reads them once the project is delivered.
Archimate was developed as an enterprise language to address these kind of problems. The concepts have been neatly divided into layers and the relations defined between these concepts. The advantage of this approach is to enable different architects to read back the models in the same manner. The ambiguities are considerably reduced as compared to the non-standard methods.
Apart from the ability to enable architects to communicate their ideas, Archimate also lets the organisation preserve these in a repository. This has the advantage of reducing dependency of any person and improving organisational knowledge.
The primary architecture of the enterprise consists of three layers. Each lower layer is a more real representation of the elements.
This consists of operational aspects of the business. The main element in this layer is the role who performs the activities. This is not a replacement for the usual BPMN models. Business Analysts could use this model as a starting point to build a more detailed process models.
This consists of applications used by the IT to meet the business needs. These are logical view of the systems or solutions. Systems are described in functional terms and the structures that can perform those functionalities. These elements need to be implementation specific. In fact the same model could be used for different technical implementations. this is not a replacement for UML models. Application Architects could use this as a starting point to build their sequence diagrams and class diagrams.
This consists of technology that implement the applications. These are physical view of the systems or solutions. It includes the technical elements of the systems. IT teams are usually focused at this layer. This is not a replacement for the more detailed infrastructure models. Technical Architects could use this to build their Visio models.
I've included motivation and strategy layer in this. These layers represent the intent of the organisation and why the architecture is needed.
This layer models the reasons that guide the design. This is possibly the least documented area of the enterprise.
This layer models the strategic direction of the enterprise. Some of the concepts like value streams are more documented and some others like capability/course of action may be more difficult figure out.
Strategy is a good place to start for future state models.
Implementation & Migration
This layer models the programs and projects required to realise the business strategy. This usually will not go to the individual activities of resources. PMs must make a more detailed project plan using their favourite tool (e.g. MS Projects ). This is a good model for roadmap analysis and initial planning.
PS: The model in this article is inspired by Mastering Archimate book.