BMC Software offers a software solution that optimizes software development organizations. It does this by providing significant optimization and automation to the two key workflows that an application development organization does:
- Build and release software
- Maintain/support software
Software defects, reported issues, bugs... they're all "application problems"
Each of these workflows has one major business process in common: problem resolution. Problem resolution is simply the process of resolving software defects, bugs, reported issues, unexpected application behavior, etc.
During the development, or pre-release workflow, the development organization spends approximately 60 percent of its time and effort resolving problems. Any type of testing, be it unit, integration, load, functional, user acceptance, etc. is done to uncover problems or defects, which then must be resolved, hence problem resolution.
Once an application is in production, development organizations typically spend time addressing issue that come in from production or customers — this support, or application maintenance work, is nothing more than solving problems, and it consumes anywhere from 5 percent to 25 percent of the development organization's time and efforts, stealing cycles from new development work.
This process of resolving problems is all about getting to the root cause. Once the root cause is identified, the problem can usually be resolved easily. It is estimated that 80 percent of the time and cost of solving problems is spent getting to the root cause.
Symptoms do not necessarily reflect the root cause of problems
Why is root cause analysis so challenging? First, the symptoms of application problems do not necessarily reflect their root cause. For example, an application may be running slow, and there are hundreds of potential reasons why. The fact that the application is running slow, (the symptom) doesn't help anyone resolve the problem. With only the symptoms to go on, engineers face a manual, trial and error process that includes of a significant amount of guess work.
The intensive, manual, trial and error process of root cause analysis
The time-consuming, manual root cause analysis process is composed of three steps:
- Categorization of the root cause of the problem
- Gathering of information related to the "guessed" root cause category
- Recreation of the problem and its environment
Categorization: A best guess, that's often wrong
Once a symptom is reported by an end user or detected by a QA analyst, the person or organization tasked with resolving this issue makes a best guess as to the root cause — they narrow the list of potential root causes by assigning the problem to category which has exhibited similar symptoms. This isn't necessarily a formal process; they make a guess based on experience.
Information gathering: Down the wrong rabbit hole
Once the problem is categorized, the person or organization tasked with resolving it will begin the time-consuming, disruptive, manual process of gathering information to start the resolution process. This may include communicating with end users and operations teams, collecting screenshots, log file dumps, etc.
This entire step is flawed because people gather information based on the initial problem categorization, or best guess. Therefore, the info gathered often is not relevant to helping resolve this issue. Many times, the correct info is either not available or is not collected. And when it turns out the wrong category was guessed, the process repeats, much to the dismay of everyone involved.
Recreating the problem: Different than reproducing symptoms
Once information is gathered about the problem, it is used to attempt to recreate the issue.
However, what most organizations do when they think they are recreating a problem is actually reproducing the symptom, which is simply making that behavior (slow performance, a crash, etc) occur again in another environment.
Trouble is, there are literally hundreds of reasons why a particular symptom can occur. If an organization is really going to recreate the problem as it happened when originally reported, the symptom has to manifest itself for the same reason — for the same root cause. Therefore, to truly recreate a problem, the person recreating it has to know the root cause — or get very lucky with a good guess.
Like a black box flight recorder for software applications
BMC Application Problem Resolution provides significant efficiencies to the application development organization by automating and accelerating the manual, iterative processes typically required to find the root cause of problems, thus cutting overall problem resolution times by 50-60 percent.
The technology behind BMC Application Problem Resolution is analogous to a black box flight recorder on an aircraft, which records all the under the cover aircraft functions and flight details so that if there is an issue, all the events leading up to it can be replayed and the root cause can be identified. Similarly, BMC Black Box software technology records all the details under the covers of an application, as well as how that application interacts with its environment. So if a problem occurs, details leading up to and during the problem are automatically captured. This info is then is available to the people and organizations assigned to analyze and fix the issue.
Trusted by premier global companies
BMC Application Problem Resolution is helping over 1,000 top enterprises, ISVs, and IT Solution Providers to speed application delivery, increase software quality, performance, and availability, improve customer service by reducing application maintenance cycles, and maintain segregation of duties requirements for IT.
|
| e-Library | Webcasts & Podcasts |
