Summary
UML is a visual modelling language usually associated with software engineering. It allows us to create diagrams to conceptualize a solution blueprint and communicate the software architecture idea in a clear way.
This article is an analysis of UML from a functional architecture standpoint. We will not review the diagrams, and we will maintain a standard approach concerning their drawing. The aim is to explore the application of UML on the functional design process during the ERP implementation.
Leveraging the UML is exactly like writing a map of the implantation solution. The precondition is that it requires learning the standard rules to write and read properly the diagrams. However, it is not complicated, and maps of the implementation solutions accelerate clarity, and improve the project’s collaboration between functional, business users and tech builder. The consequence is a reduction of the risk and project cost of the business and application architecture due the miscommunication.
As said, UML is solution mapping. The side effects of this methodology are even to be given to the implementor to pre-write the boundary of the solution offering proposed by the product. Hence, we can use these pre-maps to quickly understand the point of focus to collect properly the business requirement and trace the boundary between what is possible or not at OOB. Furthermore, concerning customs, UML gives acceleration because it was originally designed to draw blueprints about customized software solutions. The are several diagrams from higher to the deepest dive analysis level. Hence good maps can be leveraged on the offering but even on the design and implementation level.
As functional, we will focus on the business requirements collections and design of the functional solution. For certain diagrams, we will take the lead since we work directly with users, identify their needs, and map the solution components. About other diagrams, we will support writers because we will give a hand to collaborate with the technical on the design, but the real boundary will be traced by them.
This section introduces the diagrams included in the UML framework. Additional articles with practical examples are also available for further reference.
UML diagrams overview
This article offers a brief overview of UML diagrams useful from the functional standpoint and our role for each one. It’s intended as a quick reference to help functional architects identify which diagrams to focus on. Here is a list of all UML diagrams before discussing those most relevant to us.
| ID | Diagrams | Analysis level | Utilization | Role | Sample link |
| 1 | Use case diagram | L1-High | Representation and organization of the user and business case expectation, and system boundary | Primary writer | Full Article Link |
| 2 | Activity diagram | L3-Details | Representation of the business process to achieve specific outcome. | Primary writer | Full Article Link |
| 3 | State diagram | L3-Details | Representation of the status change to inquiries about the working in progress during our process. This diagram can be marge on the Activity diagram (we will see how) | Primary writer | Full Article Link |
| 4 | Component diagram | L1-High | Product and module to use to cover the business requirements. The functional should be aware about the OOB function available but in case of custom or integration, we need to collaborate with a dev to evaluate the feasibility | Co-writer with dev | Full Article Link |
| 5 | Interaction overview diagram | L2-Medium | Integration process between the solution parts. Useful especially for the integration design. The functional collaboration with the dev to define if the integration process is compatible with the business requirements | Co-writer with dev | See the communication, sequence and timing diagram. |
| 7 | Communication diagram | L2-Medium | Design which parts communicate with which one. It’s the responsibility of the functional to highlight which parts cover the business requirements | Co-writer with dev | Full Article Link |
| 8 | Sequence diagram | L3-Details | Design the sequentially of the communication. It’s the responsibility of the functionality to highlight if the sequence of communication is compatible with the business expectation | Co-writer with dev | TBD |
| 9 | Timing diagram | L3-Details | Check if the communication timing between the parts is compatible with the business volume actives and warn if is it not | Viewer | TBD |
| 10 | Package diagram | L1-High | Verify which package to install and note its license, cost for the offering. | Viewer | TBD |

Leave a comment