Some month ago in the post I wrote My Favorite Perspectives in Enterprise Architecture I presented a few diagrams describing enterprise architecture from different perspectives. The perspectives described included business architecture, IT system architecture and technology architecture. In addition, I presented several diagrams showing mappings between the above-mentioned architectures.
In today’s post I will try to present mappings of enterprise architecture artifacts to architectural requirements, business processes model and IT systems models. The presented mappings are that mappings which are the most often used by me. Of course, they do not close the catalog of possible relationships. I am not saying that they are compatible with any standard or notation, because I will combine elements of BPMN, ArchiMate and UML.
Architecture requirements can be defined on each architectural level. These are requirements that complement the description of enterprise architecture artifacts at a fairly high level of abstraction.
In my experience, the majority of requirements apply to application services. Personally, I try to map the requirements of the information systems architecture to application services. I use the realization relationship for this.
Quite often, business requirements are also defined. At the business architecture layer, I also use the relationship of implementation. As I have outlined above, you can define the requirements for the architecture technology.
It should be remembered that business defines the business process and its framework – requirements. IT systems are created to support the business process. The mapping of artefacts to requirements presented above makes more sense when the requirements of IT systems architecture meet the requirements of business architecture.
Mapping Enterprise Architecture Elements To Other Models
Defining the requirements and other artifacts at the architectural level is only half of my way. Personally, I like to have enterprise architecture artifacts mapped to other models maintained in the organization. Typically, these mappings apply to business process models and use cases.
The mappings presented above are based on the trace relationship. I use it because the purpose of this relationship is to indicate the relationship between the elements. You can combine components or other artifacts in a similar way.
It is worth noting that on the above diagrams elements describing enterprise architecture with elements detailing it have been combined. Details such as use cases or business processes expressed in BPMN are at a lower level of abstraction. For this reason, usually one element of architecture corresponds to one of many detailing elements (one application service is implemented by one to many use cases).
Finally, I would like to point out that the diagrams presented in today’s and previous entries (My Favorite Perspectives in Enterprise Architecture) are just a small part of the possibilities offered by CASE tools and notations such as: ArchiMate, BPMN or UML. The enterprise architecture modeled in Archimate is a combination of three views, which can be specified in other notations. What’s more, when describing enterprise architecture, it can present the diagrams of motivation, implementation and migration. You can also build descriptions of value chains. There are many possibilities of description (modeling). Therefore, I recommend that before entering any diagrams you can write down the principles of modeling or build a methodology to create and maintain either enterprise architecture or business processes. Building work standards will not be wasted time.