Level: Introductory S. E Slack (sally@sslack.com), Author and business transformation communications consultant, Freelance writer
05 Jun 2007 Use performance management techniques to spot or prevent problems
with your design. Learn how early planning can assist in quick problem diagnosis to
reduce downtime and provide advance warning of imminent problems.
Part 5
of this series discussed the concept of performance monitoring. Now, Part 6
explores how to plan for and implement performance management techniques to keep
your design running smoothly. By most definitions, performance management is the
trending of end-to-end response time and performance parameters from network,
system, and application components to predict short-term future performance
degradation. To handle performance management effectively in your organization,
you want to focus on specific activities you can set in motion to handle problems
when and if they occur. This isn't frivolous work. Increased global competition
means a business can't afford to randomly monitor its application architecture.
Instead, constant reviews must occur to quickly identify problems so that down
time is minimized and imminent problems are caught before they cause big
headaches.
Skills and competencies:
Exhibit flexibility and adaptability
Arguably, the most important skill in performance management is flexibility. The
goal of any application architecture is to achieve results, right? The results
vary widely from organization to organization, but, overall, an architecture that
doesn't produce required results is a failure. It's a bit deflating, then, to find
a problem with your architecture after deployment. That's where flexibility comes
in. Put your ego aside and stay flexible enough to recognize when your
architecture might have flaws. You'll learn invaluable lessons from the
experience, and you'll be open-minded enough to consider a wide variety of
solutions to the problem.
In the same vein, adaptability is critical as you manage performance of your
architecture. When you're adaptable, sudden changes in direction or unexpected
roadblocks don't bother you. You're able to see them for the opportunities they
are and open your mind to the possibilities presented by performance issues. While
being flexible allows you to bend enough to recognize a problem, adaptability
helps you build tolerance and acceptance of change. One without the other is okay,
but having both skills gives you more support from a performance management
aspect.
Skills and competencies:
Commit to communication
It doesn't matter who you are or where you work, if you can't effectively
communicate about performance issues, you can't effectively manage performance
issues. Others don't grasp the gravity of a situation or respond in a timely
manner to your requests for assistance or information, for example. Worse, your
management questions your ability to handle the problem. That makes communication
skills an integral part of performance management.
As part of your architecture, you should either connect with communications teams
or work on your own to create a communications plan during performance-related
crises. It doesn't have to be an elaborate plan, just one that helps you or others
quickly identify who should be notified when performance issues arise and how
often they should be updated on resolution progress. For example, a simple
performance management communications plan can outline the key executives who
should be notified, the information they need to know, and the format you'll use
to communicate with them. Whether or not you are still on the project in a year,
others can follow in your place and know exactly who to contact and when should a
performance issue arise.
Skills and competencies:
Show the ability to analyze
How good are you at analyzing problems? It's a pretty big part of an application
architect's job, that's for sure, so you're probably at least comfortable with
analyzing problems and finding solutions. That's good, because analytical skills
are huge when it comes to performance management. Your skills in this area will
expand as you use it for performance management.
During development stages, you analyze information for predictive modeling and
fact-based decisions. During performance management stages, you use analytic
skills in two keys ways. First, you need to analyze the entire architecture to see
how different segments might be impacting the organization as a whole or where
your predictions might have been off. This sounds straightforward, but it requires
the ability to delve into root causes, which is the second key way you use your
analytical skills during performance management. When you use analytical skills
for performance management, it's important to remember that you're not just
analyzing the problem to reach a solution, you're also analyzing the risks
involved against potential benefits for the organization.
Tools and techniques:
Find the root cause
Root cause analysis is essential to effective performance management in any
application architecture environment. Simply put, this is the technique of solving
methods aimed at identifying the underlying cause of a performance problem. This
gets tricky because you can sometimes identify multiple causes for a problem.
However, ultimately, something specific triggered the avalanche that became the
performance issue.
Some people prefer to tackle performance problems on a one-by-one basis because
system problems are often distributed over time or there isn't awareness that a
problem is recurring throughout an organization. If a problem is truly just a
one-time event, this approach is acceptable. But far too often the problem is an
indicator of a larger problem that will come back to bite you later on.
From a systems perspective, then, it's critical to uncover the true cause of the
problem almost every time you encounter performance issues with your design.
Otherwise, you're continually treating symptoms and the problem never really goes
away. This wastes time and resources that could be better spent on other things.
However, notice that I said "almost every time." Organizations don't have
unlimited resources in most cases, so judicious use of those resources is
necessary. As you work to identify and eliminate the root cause of a performance
issue, ask yourself these questions:
- Which situations are instant candidates for root cause analysis?
- Which situations can be acceptably handled without root cause analysis?
- Will removing the cause ultimately cost less than continuing to manage the
symptom?
- What process should be established or used to determine the root cause?
- Is the information actionable or raw data?
These questions are important because they help you manage the situation as
problems develop. For example, if a system issue is keeping employees from getting
paid, that's probably a pretty big performance issue for any organization.
Obviously, it is critical to determine the root cause of the problem and resolve
it quickly. But what if the problem is one where employees must manually enter
information into the system instead of using automated workflows? The organization
can still run, so perhaps this particular performance issue is one that doesn't
need root cause analysis -- or it's one that can wait indefinitely before root
cause analysis is performed.
Determining the root cause is a process that ranges from simple to extremely
complex procedures. No two problems are alike, which often makes finding the root
cause analysis a game of hide and seek. You might need to coordinate between
multiple departments and possibly multiple vendors before you even determine who
is playing the game with you. Continually ask "why" to get to the bottom of the
problem. When the pattern is complete and you can no longer ask "why," you've
typically found the root cause.
Tools and techniques:
Determine resolution options
Just because you understand the problem doesn't mean you can resolve the problem
the way you want to. Your options for a resolution might or might not be limited
depending upon the actual root cause of the performance problem. Budget concerns
can derail the best-laid plans for a resolution, for example, or perhaps resources
simply aren't available to you. If you're dealing with a service-level agreement,
you might find that you're at the mercy of the service provider in getting the
issue resolved. Additionally, a root cause is sometimes just not actionable. Maybe
it's an inherent problem in a piece of software, for example. So, when you do
identify the root cause, you need to determine an array of resolution options that
can be applied to manage the problem.
Any time you identify a problem, your management wants to know all the options
available. As you provide the information to them, don't make the mistake of just
listing the options. Instead, spell out the pros and cons for each resolution
option. Here's an example of what I mean:
Problem: Sales representatives can no longer automatically retrieve instant
customer details when a customer calls to order a part.
Resolution A: Sales representatives can manually retrieve customer details in two
minutes using a different process.
Resolution B: A fix can be implemented to restore automatic retrieval at a cost
of USD$50,000.
On the surface, Resolution A seems like a reasonable solution, doesn't it? It
takes two minutes, and then sales are back to normal. In a budget-conscious
environment, this might compare favorably to Resolution B. However, if you have
300 sales representatives who handle an average of four customers an hour, that
extra two minutes means 9,600 hours of productivity and sales time is being lost
monthly. 9,600 hours! Multiply that by an average hourly wage of say, just $8 per
hour, and you suddenly see that asking the sales representatives to continue
manual retrieval is going to cost your organization more than USD$75,000 per
month.
Suddenly, Resolution B is starting to look pretty cost-effective, isn't it? Your
management, however, might not realize this point right away. If you simply list
the previously mentioned options, they might never realize how much money could be
wasted going with the option that at first glance seems most reasonable. It's up
to you to help them understand the full impact of every resolution option you
present.
Tools and techniques:
Balance requirements
As you work on performance management issues, it's a good idea to use
requirements management techniques to help you determine the impact of the problem
on the business. Balancing the requirements of all areas impacted by the problem
is not easy, but it should be done to ensure that your resolutions are effective
for everyone. For example, finding a resolution that meets business requirements
but circumvents user requirements is not necessarily a great resolution.
For the record, you should consider the following requirements areas every time
you manage a performance issue:
- User requirements
- Business requirements
- Functional requirements
- Nonfunctional requirements
- Process requirements
Don't attempt to avoid any of these during the resolution of a problem. If you
do, you discover that one class of requirements is suddenly overriding another,
which leads to additional trouble in the future. As you balance all of these
requirements, your communication skills come back into play in a big way. You need
to help the business understand why user requirements can't be ignored, for
instance, or you might need to help management understand why process requirements
can't be bypassed in favor of functional requirements.
At the component level, problem management requires more delicate balancing. You
might want to use software such as IBM® WebSphere® to help you monitor
component-level performance for a complete picture of how the applications in your
design are functioning. Software like this also lets you drill down to granular
levels to help isolate problems.
From the perspective of the business, any performance management issues must be
aligned to business management practices. This means that you must align your
information technology (IT) objectives with the objectives of the organization if
you want to achieve full performance for your design. If there is a chain of
command that must be followed, follow it -- but keep track of who has been
notified and when, as well as what the responses are. Develop all resolutions with
an eye toward business alignment, and don't be timid about showing upper
management why your solution works for the business as a whole.
Tools and techniques:
Manage the problem
If, during the course of your root cause analysis, you determine that an
application needs to be sunset or that changes need to be made to it, consider
whether central management or distributed management techniques work with the
resolution. Both are effective choices, but if you discover a root cause could be
better handled by a switch to central management, for instance, don't hesitate to
share that discovery with your executives. Organizations tend to believe that one
method is better than the other, but in many cases the two methods can exist side
by side.
By the way, when you handle performance management issues, solution development
issues can suddenly appear as well. That's because the overall solution may be
impacted by a performance resolution at a component level. Use the opportunity to
take a fresh look at your design. When the design was implemented, it was probably
as close to perfect as you could make it. Now, however, you have an opportunity to
review it again and determine whether improvements can or should be made in
conjunction with the performance resolution. Remember the example earlier in this
article where Resolution B was actually the smarter choice from a budget
perspective? Well, what if you're able to also implement another small improvement
in the design at a cost of USD$20,000? Added to the original USD$50,000, you still
save the company money, but you're able to add some improvements too. Come up with
a Resolution C that reflects this concept and polish those communication skills.
You might just be able to turn a performance issue into a triumph for your
organization.
Milestones
Now that you've considered the various aspects of performance management that
must be addressed, it's time to look at the milestones involved in performance
management. While these may vary between organizations, the ones discussed here
are a good place to start.
Use key performance
indicators
Key performance indicators (KPIs) are designed to help organizations define and
measure progress toward business goals. Do you know what the key performance
indicators are for your organization? For the department that may be experiencing
the performance problems? Obtaining these should be a key milestone any time you
manage a performance issue.
Each time you're faced with a performance issue to handle, your first milestone
should be obtaining and understanding those indicators. Without them, you can't
clearly grasp the enormity -- or lack of enormity -- of the situation. Certainly,
the crash of your organization's commerce Web site is a big deal. But by using key
performance indicators to tell you how big a deal it is for which areas of the
organization, you can quickly identify where the crashed site is causing the most
problems. This approach allows you to tackle a solution that addresses those
highly impacted areas first and lesser impacted areas second.
Create the report
Earlier in this article I recommended that you create a communications plan
before a performance problem arises. As a milestone during a crisis, you need to
quickly report on the issue to management and others who are impacted. This is
nearly as critical as resolving the issue itself. If no one else in the
organization knows what's going on, fear, panic, and anger are going to quickly
ensue. Make it your practice to issue a standard report as soon as the problem
occurs so that others can see that the problem has been noted and is being
handled.
In the report, be sure to list the following items at a minimum:
- Problem description
- Potential resolutions
- Business impact
- Root cause
- Preventative actions
Don't let the term report faze you. This can be a simple presentation
slide with the preceding items as primary bullets if you like. But whatever format
you use, get the information out to interested parties. You'll find you have more
time to work on the resolution if you aren't constantly answering questions about
what's going on and when it will be fixed.
Summary
In this article, you learn how to plan for and implement performance management
techniques to keep your design running smoothly. In many ways, an application
architect's work is never done, so think of performance management issues as
opportunities in disguise. They might be annoying or frustrating at times, but in
the long run, the lessons learned from them can help you become better at what you
do.
Resources Learn
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
Discuss
About the author  | 
| | S. E. Slack is a Studio B writer and author with more than 16 years of experience in business writing. She has also been an executive and business transformation communications consultant to IBM, Lenovo International, and State Farm Insurance
Company. She is currently writing CNET Do-It-Yourself Digital Home Office Projects:
24 Cool Things You Didn't Know You Could Do (McGraw-Hill) and is the author of five other books. |
Rate this page
| 
