News
Rory Herriman on remote performance management
By Programmers Report Staff
Performance management is no longer just the system administrators problem. Complex distributed systems require developers to think far ahead when building apps. We thought a brief visit with NEXVU Technologies CTO Rory Herriman could shed some light on the pitfalls of the brave new performance management world. Prior to joining NEXVU, Herriman was an executive in charge of architecture and engineering at Sears, Roebuck and Co. where he defined and executed enterprise wide technology direction in the areas of telecommunications, networking and computing.
Q: What is the biggest challenge in managing remote branch performances?
A: Visibility. All too often, the first indication that a technical problem exists is when a user at a remote site calls the help desk for support. At that point, the impact to the business has already occurred.
IT organizations must employ operational tools that allow them to proactively monitor the remote site and identify potential problems before they become service impacting to the end user. This requires deeper insight than just up/down status of networks and devices. Organizations must assess the performance and responsiveness of the applications.
Q: What should so-called enterprise software architects know about this problem?
A: Applications must be architected and designed for maximum performance and usability and uniquely tuned for the targeted environment. In essence, developers need to look beyond the merely technical and think things through from the user's perspective.
This starts with understanding the technology environment that the application will be deployed in and ensuring that it is designed to operate efficiently within that environment. For example, highly distributed environments with multiple, low-speed WAN links like those often found in banking, retail and insurance organizations, require a different application deployment strategy then consolidated, high-speed environments do.
Application architects should consider areas such as session management, transaction profile and communications thread usage as critical areas in the application design process. These areas can all have significant impact on an application's performance and each should be tuned for the specific environment.
The other aspect is the business environment. Will there be peak periods, or will traffic on the application be steady? For example, bank branches are likely to have peak periods before business hours, at lunchtime and at the end of the business day. They will be measured on their ability to handle the traffic at these times. Application architects need to design their apps to handle all eventualities.
Q: How do you distinguish/measure between availability and usability?
A: Availability is a term that is used by internal IT organizations to define when an application is operational or "available" for use. This is a macro-level view into the overall "health" of an application. It's a very binary way of thinking -- the application is either on or off.
Usability is an end-user-centric measurement that reaches beyond availability to include responsiveness and performance consistency to define when an application is "usable" by the end user. High availability does not equal high usability!
By aligning to and measuring "usability-"oriented metrics, IT organizations can ensure that the services they deliver are and will continue to meet the needs of the business.
Q. What is the most common pitfall/problem/challenge for the development team/admin team when a CEO decides he wants a real-time enterprise?
A. The most common pitfall is not understanding the depth and breadth of impact this strategy will have on the company. In many cases, it will require a reengineering of core business processes as well as the applications and technologies that support them.
Q: Does it tend to be an app problem? Network problem? Server problem? DB link?
A: It varies depending on the organization and the maturity of their environment. But in most environments, it is a little bit of everything. Each component must be tuned for the specific environment and performance needs. There is no "one size fits all" to this problem.
That being said, we often find that organizations have less understanding or information about the applications than any other component.
Please see the related article:
"Brave new performance management world"
by Jack Vaughan