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

  • System Architecture On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these "squares are doing with 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 […]
  • Registration of Problems Identified During the Analysis I received an interesting question by e-mail: According to your knowledge, is there an object in EA that would be best suited for registering problems identified during business or […]
  • Enterprise Architect Pro Cloud Server – Modeling in the Cloud It is impossible to hide that working on Enterprise Architect is sometimes quite a challenge. Especially the publication of diagrams is a big problem. Not without a reason, I also […]
  • User Stories vs. Use Cases We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of […]

Leave a Comment

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

Scroll to Top