Including the time dimension in Enterprise Architecture models enables the modeler to depict the interaction of the events, tasks, and actors depicted in the model in a way that indicates the order of the interactions. There are many diagrams or modeling options to chose from to illustrate timing of events within a system or process.
A few favorites that are helpful in capturing the dynamic artifact-time relationship are:
- Event Sequence Diagrams
- Collaboration Diagrams
- Activity Diagrams
In this article, we’ll take a look at how to capture time in event sequence diagrams. But first, let’s differentiate between 2-D and 3-D diagrams.
2-D versus 3-D diagrams
Event sequence diagrams, collaboration diagrams, and activity diagrams stand in contrast to static diagrams such as the system context diagram.
In a previous article, we created use case examples for a fictitious company called ABC Corp. ABC Corp provides services to a customer who needs to log into a system and provide personal information to complete their customer profile. For the customer to successfully log in, a system administrator must provide login credentials by logging in and manually provisioning the customer.
To expand on this example, assume that there is also a customer service rep who logs into the system to provide services to customers. To represent this diagrammatically, we have several options depending on the goal. As mentioned above, if we wanted to depict a time perspective, then a system context diagram will not work.
As you can see, a system context diagram is two-dimensional; it shows the system artifacts and relationships of the artifacts to the system but makes no reference to the timing of events.
Using event sequence diagrams to show time
Adding a time dimension to diagrams allows for a three-dimensional view of a model. However this does not mean you are adding hours and minutes, but rather you are adding a sequence to the activities.
Let’s take the ABC Corp example. In this example, we can show how rendering services is represented when a time sequence is added to a diagram. To illustrate, we will use the event sequence diagram. Since event sequence diagrams are typically done from one user perspective at a time, we will start with the system admin. In the sample event sequence diagram below, you can see the sequential execution of each activity as the system admin interacts with the system. Each step in the process flow is accounted for and its occurrence within the sequence is known.
Similarly, for the customer, the event sequence diagram would look something like this:
Lets explore the last perspective of the customer service rep.
In comparison to the system context diagram, the event sequence diagram clearly shows when each step in a process occurs and when and why each user is interacting with the system.
Event sequence diagram considerations
One drawback to consider when representing time in a diagram is that a single diagram will, for the most part, contend with the viewpoint of a single actor/stakeholder. Even though it does not show when activities are supposed to take place, the system context diagram has all actors and all possible activities performed on the system on one diagram, whereas the event sequence diagram has to be done from each individual actor’s perspective in order to be effective.