This post is part two on how to sort out a business problem using the tools of an investigative reporter. My first post examined the Who and the What. Today's post examines the When, Where and Why.
When did the problem start?
It is helpful to gain an appreciation of the depth of a business problem by probing and exploring its past. By researching a problem to find its origin, you can learn a lot about the organization and business practices that surround a problem. I will have to say that I am biased in this approach. I tend to be a history buff. So, I lean towards investing some time and effort to gather whatever background information is available.
To gather some history about the problem you can start with a conversation about what the problem looks like today, then explore what the problem looked like at different points in time (6 months ago, 2 years ago, maybe even a decade ago). Try to see if the problem has evolved over time. Why is this important? A problem that is systemic and pervasive usually has not been solved for a reason. You need to flush out that reason. Perhaps the approach taken or technology selected was immature, not well aligned, or maybe the wrong platform was chosen. In my experience, re-introducing a solution approach that was tried and failed in the past will not be readily or eagerly accepted. Therefore, for no other reason, try to gather information about a problem's history in order to avoid repeating mistakes from the past.
So, what if you determine that a problem has only recently erupted? This type of situation takes you down a couple of possible paths. Perhaps the business just wants to get back to where things were before the problem occurred (an original business state). Your focus then is on removing the process or technology that is the cause of the problem and replace it with a solution that brings the business back to their original state. Sometimes that may not be possible especially if the original technology is no longer supported or the original process is no longer a fit for the organization.
Generally, I tend to view a problem situation as an opportunity to generate a vision for a new and improved business state. Sometimes, a small change or improvement to the current technology or processes in place, can alleviate the problem and move the business to a new and steady state. To be honest, it is not always easy to do. Sometimes architects prefer to "rip and replace" and move the business to a platform and process that they themselves are more comfortable with or knowledgeable about. That can be expensive, so unless the current platform or process is fundamentally flawed, I try to work with what is there and see if I can make it better.
So, where does the problem exist?
As I pondered how to introduce this section, I envisioned a large double edged sword. An important question that should be asked is; Where else has this problem occurred and does this problem currently exist in other parts of the business? Now for the sword. Asking this question is opening a can of worms for solution architects. You have inadvertently opened the door and entered the room for Enterprise Architects. Why is this a problem? Attempting to solve enterprise wide problems on a fixed and limited project budget is a recipe for frustration and disappointment.
The reason you should ask the Where question is not to solve the enterprise problem. Rather your goal is to find a solution for your business area that is flexible enough or can be built upon so that one day it may be used by another solution architect for another part of the business. Enterprise problems are hard to solve, and typically require more resources than are available for a single project.
The Why question
We have discussed the when and where, now to tackle the why. When looking at a problem you should consider the following question - "Why is this particular problem important to solve today?" This is a tough question to ask. Rooted in the question is a basic assumption that at any point in time, there are multiple problems to be solved within the business, so this becomes a discussion around business priorities. It is typical that different parts of the business will have different priorities. If the business outcome you hope to achieve affects multiple parts of the business, then you should be ready to deal with competing priorities. So, what is your task? Capture the priorities that may be competing (either for time or for resources) with the problem you are being asked to tackle. Bring it to the attention of decision makers around you. Your job is providing the information that they need to decide on which priority gets worked on first. Respect their decision and do your best to deliver on what has been deemed as the highest priority problem.
To summarize, you should be prepared to explore the past when researching a business problem. You may find out that a problem exists in multiple business areas. Do not attempt to solve an enterprise problem on a limited project budget. However, you should try to come up with a solution plan that is flexible enough to be used by other architects for other parts of the business. Finally, determine where the problem you've been assigned is ranked in the larger scope of business priorities.
I hope you enjoyed this article. Future posts will delve into how to take the information you've gathered and use it to initiate a comprehensive solution design.