Now that your enterprise architecture design has been implemented, you might be feeling the urge to kick back your heels and rest up for the next challenge. It's tempting, I know, to leave a design behind when implementation is complete. After all, you've been working with that design for ages, and it's probably got to be boring you to some degree at this point. However, this could wind up being the most critical phase in the process for you.
Why? Because your design is only as good as its performance. All the pieces might be in place after implementation, but if users are frustrated or aspects of it don't work as you intended, you need to know so that you can bandage up any problem areas. The only way to do that is to monitor the performance of the enterprise architecture. So, don't get too comfortable—you still have some work to do. You must measure the performance of the business to identify problems and opportunities, and then take corrective actions.
Your overall design has ideally combined business vision and strategy with information technology (IT) tools, so the emphasis in the monitoring phases of an enterprise architecture design should be on performance. For example, how is the information —not the technology—driving and serving the business processes? Are users achieving what they need to? Have there been improvements upon processes? In this section, I look at which skills and competencies help you as you wade through performance issues.
I talk a lot about flexibility and adapting to change, because to me, these are two of the most critical skills an architect can use. Nothing in life works perfectly, although everyone else at your company might think things should. That includes your enterprise design. While it might be tempting to tell others, "this is the design—love it or don't," a flexible architect knows that changes can always be made to improve any design.
One way to think about honing your flexibility skills is to take a lesson from the world of investments. When investment planners talk to clients about keeping investments flexible, they talk in terms of liquidity, credit, and opportunity cost. If you apply those same concepts to enterprise architecture, it can help you to think and react in a more flexible manner when performance issues arise.
Take the concept of liquidity, for example. In investment terms, liquidity refers to how easy it is to turn investments or assets into cash without a loss of value. In your architecture, as performance issues pop up, what can you do to turn them into "cash" without losing too much value? Can you reroute a piece of the system to eliminate the performance issue? Maybe you can move a process into another application without losing valuable data-entry time while a problem is being fixed.
As far as credit and opportunity costs go, credit refers to the ease with which a reasonable-cost loan can be obtained on short notice; opportunity costs are the loss-of-return you might have if you don't commit your "cash" to the best-performing investment available. Think about it: Can you improve a performance problem by using a different method on short notice? What's the impact on the organization for changing things so quickly? And what kind of loss will occur with whatever method you choose? You might even discover a way to manage the issue that never occurred to you before. Keep that flexible mindset so that you don't miss out on a great investment opportunity that perhaps had been hiding in the wings.
Keep the lines of communication open
When you're monitoring the performance of your design, don't go back to your desk or office and work on the problem alone. Sure—maybe you're embarrassed that a performance issue is occurring that would never have happened if you had caught it before implementation. And maybe you should be embarrassed! But working alone rarely solves performance issues—you must get input from a variety of people to help you consider all the potential ramifications of the issue and to determine the most appropriate path toward resolution.
Have a meeting; invite key members of the business to it, and include other architects—even those you might not like that well. A collective thought process can inspire solutions that individuals working alone rarely consider. If the problem concerns the organization's users, why not bring a few of them into the meeting, as well? After all, who knows better than users what will make their lives easier during actual use of the design?
A tip: As you're working on a resolution, keep management informed. They'll be fielding lots of complaints, and knowing where things stand as the problem is worked out can help them immensely. You can send them a quick daily update to accomplish this if you like—create a simple template so that you only have to fill in the blanks to inform them of activities that have occurred since the last communication. You'll score a lot of points with management if you keep them in the loop, so don't overlook this vital step.
As you monitor performance, it's important to stay analytical. Don't let your personal feelings get in the way of determining whether pieces of the design are working as well as they could. Others might get worked up about an issue that ultimately isn't worth the concern. By putting your analytical hat on, you can determine whether a performance issue is truly a concern. To maintain that analytical mindset, methodically work back through the expected high-level outcomes through the outputs, inputs, and processes to determine where deviations are acceptable.
The trick, of course, is to determine which items in the design are the most critical. If you discover that a small area of the design isn't working well—say, a section of the user interface (UI) is a bit confusing—think about what that means to users' overall productivity. Is the confusion causing delays in customer service? If so, how long are the delays? One second? 30 seconds? Minutes? Then, multiply the delays by the numbers of customers and service representatives involved: How does the problem look now?
If analysis shows that the delay is going to create a significant problem over time, you've got a real performance issue on your hands. If it doesn't—maybe the delay only affects a customer once per week—the problem isn't that big a deal. The point is, stay detached and analytical as you monitor performance.
In a previous article in a related series, "Application architecture essentials, part 6: Understanding performance management," I addressed a variety of performance-management tools and techniques that can be used in application architectures. That article is a good reference for anyone grappling with enterprise architecture performance-management concerns. But as you work with performance management from an enterprise perspective, the following tools and techniques might also help.
First and foremost, even when a performance issue occurs, your business must keep running effectively. You can't shut down a customer service center, for instance, to fix a problem: You've got to figure out a way to keep the customer service center running smoothly while the problem is fixed in the background. But sometimes, it's difficult to find the actual performance problem. Maybe all you know is that the system is running too slowly to effectively serve customers.
Tools that can help find bottlenecks in performance include IBM® Rational® Performance Tester and IBM Tivoli® Composite Application Manager for WebSphere® (see Resources). You can use these tools together or separately to help build performance tests, create scenarios, and identify bottleneck sources. By using tools such as these, you can manage business risks and assets effectively while locating the source of the problem.
To avoid getting caught up in a single performance issue, monitor the entire business process in real time so that you can maintain the continuous performance you need. One tool that can help you do this is IBM WebSphere Business Monitor (see Resources). It provides a visual display of business process status with alerts and notifications to key users that facilitates continuous improvement of your business processes.
The nice thing about this tool is that it also integrates with IBM WebSphere Business Modeler Advanced to provide business modeling, simulations, and insightful analysis. The two tools combined can help you identify and consider all pertinent information to the problem at hand so that you can fix the issue and move on to other items.
Effective business process management (BPM) is key to monitoring performance in your design. If you maintain a holistic view of the entire enterprise, you'll have a better chance of finding glitches before they become major performance issues. To help you stay organized and understand, define, execute, and optimize the core business processes that generate value for your company, take a look at BPM enabled by Service-Oriented Architecture (SOA—see Resources for more information).
Use this approach to see your entire organization at once—before performance problems occur. It can save you a lot of time in the long run and reduce implementation headaches, too. While this admittedly might not help you if you are already in the midst of a performance-management problem, it's worth reviewing the topic to see whether it can help you the next time around.
When you're dealing with performance issues in your enterprise design, there are typically a few milestones to keep in mind.
Understand Sarbanes-Oxley reporting
In the United States, a federal law outlining corporate financial reporting requirements might affect what you do—or don't do—with performance issues in your design. Called the Sarbanes-Oxley (SOX) Act, this law governs various aspects of business that affect financial reporting, including automated processes. As a result, you must be aware of SOX requirements if you work with or for U.S. companies. In some cases, specific reports may be required concerning performance issues.
To learn more about SOX and how it might affect you or create milestones you must be aware of, see the Resources section. IBM Rational Method Composer and IBM Rational Portfolio Manager can help you comply with regulations.
Let's face it: Most projects rarely do as well as we want them—and plan them—to. Still, when you're trying to manage a performance issue, you'll be asked to provide information about the Return on Investment (ROI) you're asked to make. When you're talking with management about the ROI of a proposed fix, keep the following points in mind.
Walker Royce, VP of Rational Services at IBM, once said that ROI estimates are not science; they are due diligence exercises to build a guiding coalition. Additionally, they are designed to gain buy-in on certain aspects of organizational change.
As you work through performance issues, be careful of using "unjustified precision" to calculate your ROI as you propose changes to resolve the problem. Unjustified precision, as Royce explained, is the concept of averaging things a little too loosely. His example is that averaging 10 survey responses to provide a 1-5 rating is not a precise description of customer satisfaction. Even though nearly all ROI data is subjective, it's important to maintain an objective representation of subjective or speculative estimates whenever possible.
Know your end-to-end response times
Earlier in this article, I referred to the concept of determining whether a problem is a big one or a small one. One of the milestones, then, that will arise is that of end-to-end (E2E) response time. E2E is the elapsed time between the moment a user presses a key and the moment the response is received. At some point during your performance evaluations, you must measure this time.
Your true milestone, then, is to know ahead of time what the E2E timing should be so that you can quickly determine whether it has been compromised. If you don't have an expectation of that time prior to implementation, you're going to be scrambling for answers when things go wrong. It's one of the first things executives and management will ask for as they try to understand the problem at hand. So, do yourself a favor and commit the E2E response time to memory so that you can quickly see any performance issues that might affect it. Depending on your specific environment, a variety of IBM tools can help you pinpoint response problems quickly.
As I mentioned at the start of this article, you need to measure the performance of the business to identify problems and opportunities, and then take corrective actions. Your enterprise design is only as good as its performance, and the truly great enterprise architects know that the hard work isn't finished until the implementation runs smoothly and effectively.
Learn
-
Read other articles in the
Enterprise
architecture essentials series.
-
In the Architecture area on
developerWorks, get the resources you need to advance your skills in the
architecture arena.
-
Get the
IBM
Enterprise Architect Kit for SOA (developerWorks, Oct 2006) to help you align
IT processes with business requirements more effectively.
-
Read "Improve
performance with self-configuring distributed systems" (Jonathan Wildstrom, et al.,
developerWorks, Dec 2005) to understand adaptive hardware configuration techniques.
-
Read
The
Business Impact of BPM with SOA: Building a Business Case for BPM with SOA ROI,
to learn more about building a compelling business case for investing in BPM.
-
Be sure to read Compliance
to learn about SOX and other U.S. regulatory compliance issues.
-
Browse the technology
bookstore for books on these and other technical topics.
Get products and technologies
-
Use Rational
Performance Tester to create and analyze tests that validate your design.
-
Put Tivoli
Composite Application Manager for WebSphere to work in your enterprise.
-
WebSphere Business
Monitor generates an up-to-date view of your business performance.
-
Rational Method Composer
can help you comply with SOX requirements.
-
Rational Portfolio
Manager helps organizations align IT and investments with business priorities.
-
Download IBM
product evaluation versions and get your hands on application development tools
and middleware products from DB2®, Lotus®, Rational, Tivoli, and
WebSphere.
Discuss
-
Check out developerWorks blogs
and get involved in the developerWorks
community.
S. E. Slack is a freelance writer and author with more than 17 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 Companies. She is the author of Windows Vista: Home Entertainment with Windows Media Center and Xbox 360, as well as numerous other books. Contact S.E. Slack at sally@sslack.com
