The Time Dimension in Enterprise Architecture Diagrams

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

Let’s look at how to capture time in event sequence diagrams. But first, we need to make sure we know the difference 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.

Show Time with Event Sequence Diagrams

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:

Let’s 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.

It’s Not About the Tool

For practically every profession under the sun there are tools that make the job easier. From bakers to builders, everyone has their choice of implements to ply their trade. Naturally these tools will range from entry level, toy tools to expensive gadgets with more features and sophistication. Enterprise architecture is certainly no exception.

One of our primary tools for designing architecture, of course, is a modeling tool. Modeling tools help us visualize our design into standard, in our case UML, models. There are a variety of these tools in the marketplace, ranging from basic “drawing style” tools to far more advanced suites with “model awareness”, version control, team collaboration capabilities, etc.

Read more

System Architecture Diagrams

Diagramming software systems is still a largely undisciplined activity, despite the many advancements in notation and methodology made over the last 10-15 years.

The typical “Systems Architecture Diagram” profile of a large organization goes something like this: Read more

Investigative Architecture: The Data Perspective

“Investigative Architecture” is a term we at Systems Flow coined a few years ago for a core, overarching discipline of ours. It describes – and prescribes – the sometimes tedious, but always challenging, process that a working architect employs to locate and absorb information about a problem space in order to create usable, professional visual work products that best communicate a solution. Read more

Next Page »