The Time Dimension in Enterprise Architecture Diagrams

September 4, 2018

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.



Technology Adoption Strategies for Business Systems

August 7, 2018

Regardless of an enterprise’s size and industry, technology touches every aspect of a business’s operations now more than ever. Successful technology implementations have always been important but in today’s economic landscape, technology implementations NEED to be successful as they can make or break a business.

Here are some horrific examples of what happens when technology implementations fail:

The implications are not just lost revenue but lost jobs. Take Target Canada’s example; over 10,000 jobs were lost when their SAP implementation encountered problems. Most of these failures are a result of a myriad of reasons that include poor project planning and insufficient technical knowledge. However, one reason that’s almost overlooked but is a significant contributor, especially during the post go-live phase, is user adoption. Users expect a seamless experience that allows them to accomplish their deliverables with ease and efficiency. Technology implementations that provide this tend to be very successful.

Common Technology Adoption Misconceptions

Before we dive deeper into understanding adoption strategies. Let’s explore some misconceptions when it comes to users’ adoption technology.

Adoption is not all about digital transformation There is a misconception that adoption is about embracing a new technology as a result of some digital transformation effort. Adoption can also be about the new and existing processes or, more simply, it can be about the efficient and full uses of technology already implemented.

Adoption efforts start post go-live In a case where adoption concerns a new technology implementation, the usual tendency is to emphasize adoption in training related activities post go-live. In fact, adoption efforts should start when requirements are being collected and the solution design is being drafted. It starts by making sure there is buy-in from end users from the beginning and throughout the process, especially before blueprinting. If this does not happen, buy-in will be much more difficult later in the project. Even worse, a solution that users do not want or cannot use will be implemented and adoption will be near impossible. This is probably a major reason why some companies’ implementations are scrapped and millions of dollars wasted. ZDnet.com estimated in 2012 that globally, companies lose $3 trillion because of failed IT; which is a combination of IT projects that add zero value to users, failed capital projects, unplanned activities, and rework.

Adoption is all about users While the focus of adoption efforts is on the end user, and rightfully so, executive sponsorship is important as well. Even if senior management does not use the technology in question, their visible and active support of the technology will inspire their subordinates to use it. Sponsors must remain visible throughout the lifecycle of the project. A side note on this is that executive sponsorship is not only helpful for adoption but the visibility of sponsors inspires the tracking of the benefits of a technology implementation to continue throughout the project lifecycle and not just simply during the first months of the new car smell.

Adoption Strategy Considerations

When discussing adoption strategies, there are a few things to consider:

  • Training
  • End-user Buy-in
  • Managing Expectations
  • Managing Complexity
  • Governance
  • Effective Communication
  • Executive Sponsorship

Training

Training is as important as the end users. Often, Change Managers will focus on training end users on using the newly implemented technology with the belief that once users are trained, they will start using the technology automatically. This is not always the case. Most training is quite generic, technical, and at times unrelatable by the users. Instead, Change Managers should make it a point to utilize user-specific workflows with a before and after type of approach, preferably focusing on how the pain points were addressed in the new implementation. In addition, Change Managers should pay close attention to the learning curve of the users. If the technology being implemented is complex, multiple training sessions may be required so enough time should be allocated to account for such a scenario.

End User Buy-In

We discussed this above but there are still a few things left to say. End users know how the business works and probably have built processes to cope with the inefficiencies of the technology they use. If a process has proved to be useful, users will develop a habit to default to it. At times this results in users circumventing the implemented technology which means all the work and money put into implementing the technology goes to waste. If you are in charge of such a project, grab a calculator and start heavily discounting your ROI estimates (assuming you were tracking ROI in the first place). Below are some key points to consider when addressing user buy-in concerns:

  • The longer a technology/process has been in use, the more effort is needed to convince end users of the value of new technology. This is simply because humans are creatures of habit. After getting used to a process, it becomes quite difficult to change. As a result, Project Managers should allocate enough time to get all users on board. I will also reiterate my point above that there should be extra effort to demonstrate benefits during the planning stage. However, be careful to manage expectations.
  • Adoption may be about fully utilizing an existing technology or process. In this case, it is important to highlight to end users the use of best practices and importance of the improvement of efficiency metrics. The idea here is to emphasize value and be able to present it to the users.

Managing Expectations

Sometimes adoption issues within an organization are a matter of unmet expectations or at times “miscommunicated capability” of the technology. At times, businesses are pushed to change a technology because it is no longer keeping up with the business operations and is causing a headache for end users. This is a good scenario during the planning process because the end users will be the easiest stakeholders to convince about a transformation. However, they also could be a difficult bunch post go-live because the technology implemented did not deliver on their expectations. They may have been promised a sports car but instead, a tractor was delivered. The tractor will still get from point A to point B but just not as fast as expected. At this point, Change Managers sort of have a mutiny on their hands. When such situations are not managed well, entire implementations can get scrapped. You can browse the web and find tons of scenarios showing what type of carnage is left when this happens. The key is to keep realistic expectations for end users and to detail out what changes to expect while making sure to keep them informed along the way.

Managing Complexity

Quite often complexity is confused with complicated. As Theodore Kinni notes in his MIT Sloan Management Review article, “Complexity involves too many unknowns and too many interrelated factors to reduce to rules and processes”. On the other, complicated may mean hard to solve but solvable or resolvable with systems and processes. An interesting note made by Kinni is that solutions to complicated problems do not always work on complex systems. If left unchecked, what ends up happening is the implementation of a technology with potentially too many features and requirements that very few users want with the majority left figuring out how the technology fits into their workflow. Dealing with complexity can be difficult. Below are some suggestions on how to address complexity in order to increase user adoption:

  • Identify complexity first, distinguish what is complicated and what is complex. A good rule of thumb is to look at your organization, processes, policy etc. and, if you can distill them into logical rules that can be converted into systems or process you have a complicated scenario. If you seem to have difficulty figuring out if any set of activities is a process and things seem disjointed, you likely have a complex scenario. Refer to Kinni’s article for ideas about managing complex business scenarios
  • Simplify as much as you can. A starting point would be to determine the business objectives. Next, determine all the processes that are critical to meeting those objections.  Then find common interconnections between the processes. You can then try to cluster these processes based on the interconnections and start determining which ones are critical, which ones can be consolidated, or if new ones may need to be created. By doing this you are able to make sure that any part of a business can be reduced to rules and processes that drive business objectives.

Governance

Governance is key to ensuring the users and the business as a whole are adhering to set rules and laws. It not only avoids legal issues but at times is helpful to ensure a good service or product is provided to customers. At times the adoption of technology is affected when rules, policy and laws are not so clear to the user.  For instance, users will bypass a system if it does not provide a direct route to achieving their task. They would rather opt to perform the task outside of the system with less hassle. The system’s utilization will gradually decrease over time and therefore its adoption as well. A good approach to trying to solve this would be to bake in as much of the governance into the technology as possible. At times this may be difficult especially where there are numerous variations to process. In this case, the exceptions should be clear, documented and easily accessed for reference.

Effective Communication

Sometimes adoption is a matter of awareness. Users need to be aware of the progress of a project when a technology that affects them is being implemented. Most importantly, users need to know how this technology will affect them. Users should feel included in the entire process; that way the changes and the technology implemented are relatable, thus lowering the resistance to adoption. Below are a few pointers on ideal communication that can help increase user adoption:

  • Involve power users in all phases of the project (these are your adoption champions and can help sell the benefits  to other users)
  • Send regular bulletins to all affected users.
  • When sending out bulletins, make sure to incorporate relatable terms and figures. For instance, mentioning of major pain points and how the new or improved technology will resolve them can create anticipation which will likely help increase adoption during the first few months post go-live.
  • Engage users through pulse checks post go live. This can be achieved through surveys of the user’s opinions. The responses can be published but should be anonymized.
  • Share the metrics on the project performance, including ROI metrics post go-live. Usually, these metrics are reserved for the steering committee and managers, however, they are helpful for end users to be able to measure the effectiveness of the implementation as well as their contribution to it.

Executive Sponsorship

Users are likely to be receptive to ideas and suggestions put forth by their executive leadership. If the leadership endorses the technology as well as champions its use, then the rest of the rank and file will likely be more receptive and ultimately less resistant to adoption.

Summary

Even though all of these points may seem to be effective separately, they should be considered in unison. Focusing only on one is not enough. Adoption is, in large part, an emotional business and you need as many tools in your arsenal to engage users and drive adoption.



5 Rules for Writing Effective Use Cases

July 10, 2018

In a previous blog entry we introduced you to use case types and use case presentation methods (textual use cases or use case diagrams). In this entry, we will cover the five most important rules for creating use cases.

Rule #1: Follow a straight path to achieve a use case goal

A use case should be as concise as possible; when another possible route becomes evident, consider the following:

  • Is the path achieving the same goal with the same actor?
  • Is another actor now involved?
  • Has the goal changed?
  • Is the path an alternative to the main path?

In part 1 of this blog series, we had the following use case example:

 

Use Case Name Complete Customer Profile
Goal Input personal information into ABC Corp online portal
Use Case ID UC001
Actors Customer
PreCondition Customer has login credentials provided by ABC Corp System Admin
Primary Course 1.       User accesses ABC Corp’s portal

2.       User logs in using credentials provided by System Admin

3.       System verifies customer and displays personal details entry form

4.       User enters personal details into form and clicks save

5.       System presents a confirmation screen informing the user that the  information has been saved

6.       End Use Case

Alternative Course 1a.     System is down

1a1.   User emails personal information to System Admin

1a2.   Proceed with Alternative Course 1b.

1b.     System Admin enters customer information

1b1.   System Admin User accesses “customer information” functionality

1b2.   System Admin User enters personal information emailed by customer

1b3.   End Use Case

3a. System Cannot verify User

3a1.   Customer emails System Admin for credentials reset

3a2.  Resume at step 3

As shown in this use case example, there is more than one way to provide personal information to complete a customer profile. We could have done one of two things to illustrate this:

  1. Create a new use case to indicate the email route
  2. Create an alternative path in this use case

We chose to go with option 2 and created the alternative path. The reason being that the alternative path still concerns the same actor, system, and use case goal (complete customer profile). In addition, there are relatively few steps involved in this alternative course to warrant creating a new use case. If there were too many steps, then a new use case would have been the appropriate action to take. If new actors and goals are introduced, it is ideal to create different use cases even though the steps may seem similar.

Rule #2: Don’t confuse use cases with user stories

Use cases and user stories are two different animals. Use cases represent formal requirements while user stories capture the benefits derived from a system function in one or two sentences  (e.g., “As a customer, I want to enter personal information to complete my customer profile”) in the language of the everyday user.

Rule #3: Focus on process vs. system functionality

When working with use cases, make sure that the language and flow of the courses (primary or alternative) focus on the user’s execution of a process rather than the underlying system functionality. In a use case, we aim to capture the interaction of the user with the system and not necessarily detailed system logic.

Rule #4: Reference other use cases when appropriate

Let’s take the use case example above, which has a primary course that started to become too long. Ideally, a use case’s primary course should have no more than 10 steps. If you run into a scenario like this, determine if there are parts of the primary course that can be made into their own use case.

For instance, if a user had to go through user confirmation were they had to receive an email and confirm their credentials, then a new use case would likely need to be created. We might call this new use case “UC004: Confirm Registration”. In UC001’s primary course, instead of including steps to confirm the account, we can instead replace the steps with something like:

“Step 9. Confirm account registration see Use Case UC004”

This reference just saved us five plus lines of steps in one use case!

Rule #5: Treat “if” statements with caution

Using “if” statements as triggers to indicate different states in the interaction of the user with the system can be a bit tricky. Using the same use case example above, suppose we had not created an alternative course for an email request for login credentials. Instead, we could have stated in the primary use case that “If the system is not available, then email System Administrator” for login credentials. This could work. However, it is not a good practice because  a use case with multiple “IF” triggers quickly becomes difficult to follow and the distinction between the primary and alternative courses becomes obscured. When the “if” statements start to increase, it is best to create separate use cases and, where necessary, reference them as mentioned in Rule #4.

Conclusion

Following these five rules for effective use cases will help you write use cases that capture system requirements and concisely describe the system’s functionality from the user’s (actor’s) perspective.



Intro to Use Case Types

May 31, 2018

Analyzing or designing the various features and functions of a software system can be daunting, especially when there are multiple actors and other interfacing systems involved. Thankfully, analysts can turn to use cases to make this process much easier.

At the very minimum, an effective use case should:

  • define how stakeholders interact with a system
  • define how a system interacts with other systems
  • provide a common understanding of both stakeholder and system requirements

This article introduces the different types of use cases you may encounter and identifies some of the ways use cases are represented. Read more



Documentation Trivializes Everything

June 5, 2017

Several years ago my colleague Dan wrote about how we Should Not Get Distracted by the Document. Dan made the case that architecture documents are tools to figure out architecture, not the ex-post-facto results of architecture design you’ve already done in less disciplined ways (verbal debates, email chains, “brainstorming” and other adhoc, document-less activities).

But I am going to one-up Dan right now by declaring that focusing on documentation absolutely trivializes what we do as architects. Read more



Next Page »