Mappings That Go Beyond Enterprise Architecture

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

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.

Mapping Business Architecture to BPMN Processes
Mapping of Use Casec to the Application Service
Mapping Architectural Requirements to the System Requirements

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.

More from my site

  • My Favorite Perspectives in Enterprise Architecture Modeling On Open Group pages a number of ArchiMate perspectives are presented. Using them all in a given organization is an obvious misunderstanding. I wrote very often about the fact that in each […]
  • Levels of Business Architecture and Business Process Modeling In the previous article of Modeling Business processes in the software development process, I described the meaning of modeling business processes. In my opinion, business processes […]
  • Enterprise Architecture – Modeling Tool When thinking about modeling enterprise architecture, the choice of a modeling tool is very often considered. One of the natural candidates is Enterprise Architect. The […]
  • Managing Relationships Between Requirements Requirements management is an important element of the software development process. One of its elements is building and managing relationships between requirements. The most common is […]
  • Architect in Agile Team In the last post I described what I think about the role of an analyst in agile team. The second role that I would like to mention is the role of the architect. This role is defined in […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top