Introduction to the series
During a recent conversation with an aspiring developer I was asked how I got into my solutions architect position at Crowe. The developer was looking for some magic answer that would allow them to develop the skills that would allow them to take on this role in their own projects. I couldn’t provide an immediate answer or direction.
In the following weeks I began so seek out information on architectural issues impacting developers and found woefully few articles. I found thousands of articles on specific technologies, hundreds on software development, and scarce few on the issues that I see my architect peers struggling with. This lack of information is the reason for this column.
The goal is to provide a place where developers can go to develop architecture skills and where architects can go to review their craft. I invite you to email me if you have a topic that you believe is important to architecting applications but you can’t find information on it. I also invite you to challenge the views put forth in this column.
Solving the Right Problem
The role of any senior person in an IT group is, by necessity, that of a problem solver. Whether you are a development team leader, a development manager, or a CIO, you are confronted with problems every day. The challenge is to develop solutions that are appropriate for the problems that the organization is experiencing. All too often we alleviate the symptoms without first seeking out and resolving the underlying causes. One of the core skills of an architect is identifying the right problems.
Being bombarded by a constant stream of problems causes an unfortunate side effect: finding a quick and workable solution becomes more important than locating and resolving the root problem.
Root problems are ones that generate a multitude of smaller problems. For instance, if you are doing development and notice problems very near your delivery time, you might assign appropriate resources to solve the problems identified in the application. However, the root cause of the problem – the problem that generated the other, more immediate problem – is a problem with the core development processes. If your team had initially developed more reliable code, or if the issues with the code had been identified earlier, shipping the project on time would not be a concern.
The process of solving the small resulting problems of core issues is often called “firefighting.” It is something that can consume your entire day. In addition, firefighting is often considered a cause of burnout; you are constantly facing the same problems with no clear solutions. By seeking out and eliminating the core problems, you can significantly reduce the need for firefighting .
Finding the Root
Finding the root problem is an iterative process. The root cause of one problem may be a symptom of an even more significant issue. In our example above, identifying problems earlier in the process could have reduced the amount of issues that developed later on.
A lack of formal development processes may be the cause of problems not being identified in a timely manner. This may be causing testing to be delayed or to not be scheduled on a consistent basis. This may also be a symptom of poor overall IT processes, or perhaps the lack of appropriate experience on the development team.
One of the techniques that you can use is to ask what causes or fails to prevent the current problem. The question may have multiple answers. Each of the answers may be considered a root, or contributing, problem and one that should be considered as a potential candidate for a solution.
Seek First to Understand
By improving your understanding of the problem, you are likely to find the root cause. The better you understand the problem and its causes, the more clearly you can see the potential root problems. This can be as simple as challenging your assumptions about the problem itself, whether you are dealing with a set of code that seems to be “buggy,” or a developer that seems to consistently take too long.
In the case of the code, it may be that it needs a code review, or that one of the underlying pieces of the architecture is not working as planned. Or, if you are constantly burning the midnight oil trying to resolve your problem, perhaps your system of logging does not support debugging. As you learn more about the problem you can see a multitude of potential solutions that would never illuminate themselves without the kind of detailed quest to better understand the problem that effective problem solvers share.
Problems That Can and Cannot Be Solved
Before trying to solve the root problems, it is important to realize that not all problems can be solved. There are two reasons why you might not be able to resolve a problem. The first reason is that the problem is beyond your sphere of influence.
It may be beyond your ability to resolve some problems because of your position in the organization or your ability to influence the right people. These problems are not necessarily unsolvable; however, you may not be able to solve them in your current position. You can either save the problem until you have the right influence, or you may try to persuade others with the right influence to join your cause.
The other kind of problem that cannot be solved is one that, when solved, would create a larger problem. There are some problems that must be present in order to provide a proper balance. Solving the problem could cause more significant problems to occur in the long or short term.
When identifying the problem, you need to understand that you may be the only person that perceives it to be a problem. There are others within the organization that may perceive the issue as an asset or a great benefit. When evaluating a problem, you must consider whether it is a problem for everyone.
For instance, you might consider it problematic that clients do not have the ability to clearly articulate their needs. However, if your clients were able to articulate their needs clearly and concisely, your problem-solving and communication skills may not be as valuable. Whereas this may be a liability for you as an IT professional, your organization may perceive this as adding to your value.
Once the problems have been identified, verified, and understood, it is time to identify a potential solution. When considering solutions, it is important to consider the magnitude of the solution being proposed. If, for example, you decide that the root problem is a lack of development procedures, a proportionate solution might include creating a development process. Developing documentation, processes, and procedures is a good first response to the problem.
A disproportionate response might be to immediately purchase every product that Rational produces and schedule weeks of training for your team. The original problem was bugs that were found late in the development cycle. Deciding to move immediately to a structured process is neither realistic nor proportionate to the situation.
The key to problem solving is applying the same process to every problem that occurs. With repetition the process gets easier and easier. Instead of thinking about learning more about the problem you just do it instinctively. Instead of thinking about seeking out the root problem it can become integrated into your problem resolution process.
By following a few simple steps religiously, you can change the way that you approach problems and start seeking the root problems so that you can move out of the firefighting everything is a problem and move into a proactive mode which allows you to avoid burnout and seek out problems before they occur.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.