Applying Enterprise Architecture to Business Software Development Lifecycles

Intelligent automation efforts at Lincoln Financial Group sought to establish automated processes and streamlined business functions. Our expertise in solution architecture aided in success of that effort.

This work in Robotic Process Automation (RPA) involved evaluation and ranking of 20+ projects against design criteria to determine if an involved process was a good candidate for automation. For projects that did not meet the automation criteria, detailed solution proposals provided alternative measures for improvement of those current processes.

A project example: A virtual mailroom project proposed a digitized means for handling document mailing, emailing, and faxing. Via an architectural decision document, we proposed three automation options with detailed evaluations for each option. After Lincoln’s business line selected an option, we drafted a solution design to describe that solution in detail, in accordance with stated business requirements and to provide a baseline for cost estimation. This solution design informed the development team’s technical design that detailed its technology solution. We then evaluated this technical design to ensure completeness and accuracy before development could commence.

In addition, we created reusable software patterns for developers to use in solving common problems in application design. We developed concise, consistent UML artifacts to a pattern library that supported IT projects in AWS cloud, identity management, and security. These software patterns paved the way in efforts to define reference architectures and reference implementations.

Our expertise in solution architecture and enterprise architecture was key to achievement of Lincoln’s technology objectives and leveraging of IT best practices. Working closely with all functions of an enterprise is our norm — from developers and vendors to vice presidents and senior leaders — with the goal of clear translation and strong alignment with business strategy and priorities.

You, too, can achieve visible value and sustainable results.
Systems Flow can help.
Strategic thinking. Put into action.

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.