Breaking Down the Walls of the Siloed Application
Application Performance Managers often find themselves walking a tightrope between demolishing the fiefdoms that make it impossible to determine the sources of application errors and killing the expertise that keeps the application components running. Here are some tips to keep that from happening.
Application Performance Monitoring (APM) is an important technology that’s been building for many years. Essentially, APM is the means of measuring the end user’s view of an application from one end to the other. As the technology has improved and become more capable, a new kind of manager has also appeared: the Application Performance Manager.
It may seem odd that enterprises need APM or a special person to run the APM solution, but the fact is that applications have become so huge that it’s impossible for any single individual to know enough about the software to figure out what’s going on. As a result, applications run in a siloed environment. Each component is managed by the people who know it best, but the group’s focus is on that component, rather than the application as a whole in the context of the entire organization. The Application Performance Manager ensures that these groups actually communicate in significant ways by providing a safe environment in which that communication can take place. Communication is the key to discovering precisely where performance problems occur in an application and where a potential source of error lies when the application fails. Not to mention inter-departmental bickering.
Defining the Siloed Setting
Before anyone can create a solution, it’s important to define the problem domain. An Application Performance Manager is placed in a role where it’s essential to create an environment of trust. However, creating this environment is hard. The walls between groups in an organization are built on several levels of distrust:
- Protocol: Each group may employ different rules (protocols) to accomplish tasks based on its previous experiences.
- Origin: Organizations are commonly comprised of other companies that were acquired and rely on different software than does the host organization.
- Expertise: Different groups have different levels and kinds of expertise that may make it harder for one group to understand the other.
- Location: The groups may not even reside in the same country. They may not speak the same language either.
Where there’s distrust (and often misinformation), people tend to create walls. Fear is an extremely powerful motivator toward unwanted actions. In this case, fear can take many forms, including loss of job or loss of power within the organization. Individuals, or the entire group, can feel threatened. Reason may dictate that the groups communicate, but fear may rule the day – unless the Application Performance Manager can step in and change the situation.
Creating a Safe Environment
When you think about siloed applications, look at them as castle walls. Each component is strategically located within its own castle and protected by knights who will defend it to the death. The component becomes a fiefdom controlled by a particular manager.
If this visual sounds outrageous, you haven’t viewed applications from the perspective of an Application Performance Manager. Sitting back to think about an application issue, the Application Performance Manager views the knights jousting as a vain effort to point the assertion of guilt anywhere but their own component. When it finally becomes apparent that a particular component is guilty of a performance problem the knights of other castles gleefully assault the walls of the problem component’s castle. Frenzied attacks thwart true problem resolution and needlessly expend energy best used for other purposes, such as solving the difficulty at hand.
The corporate environment isn’t a land long ago in a faraway place, and attacks between members of the same organization are hardly helpful. In order to gain any traction at all, an Application Performance Manager must provide a safe environment that lacks the usual finger pointing and instead promote communication.
It’s actually quite rare for one of these immense applications to fail because of a single component. In many cases, the components are all working within tolerance, but perhaps at the lower end of their tolerance range. Each component contributes a small amount to a problem that manifests itself as slow response times to the end user.
When these huge applications are built, the designers normally assumed the application will run within the middle of its response time. Some components might run faster than anticipated, some slower than anticipated, and most running just as they should. But when many components run at the lower end of their tolerance range, the end user sees a slow application.
An overriding principle that the Application Performance Manager must adopt is that the only issue that matters is getting the application to run properly. Affixing blame isn’t the criterion on which APM is based. The focus is on the application and how it works, rather than chopping off someone’s head. And this attitude must be communicated both by words and actions. Once the people responsible for maintaining the application become aware that no blame is assigned, they can let down their guard a little and begin to work with others to locate those sources of application problems.
With this goal in mind, it’s often helpful to track what’s said at meetings, rather than who said it. Only when it comes time to assign tasks to individuals should names be taken.
Developing a Communication Strategy
The most successful Application Performance Managers understand the principle that it’s not what someone says that’s important, but how they say it. In this respect, the Application Performance Manager becomes a diplomat who sorts out the communications between rival fiefdoms in an organization. Sometimes the simple act of restating an issue in non-confrontational tones is all that’s needed to address a communication issue. Restating an issue can also help clarify it, because hearing the issue in different terms ensures that the stakeholders understand each other.
Communication is also enhanced when all of the groups have something on which to focus their attention. In this case, the focus is on the end user. The stakeholders need to consider issues such as what sort of experience the user is having and how the user employs the application. In fact, the group requires an understanding of who the user is. For example, knowing that the end user has a specific skill set can affect how the application is designed and maintained. Meetings should include end users because end users are one of the stakeholders in the overall solution to a problem that the application addresses.
Management also requires representation in meetings to address application concerns. Without the backing of management, the Application Performance Manager lacks the authority to take actions required to correct the issues that cause application performance degradation or eventually break it. Management also controls company resources required to resolve some application issues, such as hiring someone with a required skill.
The important thing to remember about communication is that it need not result in a complete destruction of the walls of each castle—merely that the occupants of each castle leave the door open to talk with those outside. Each group maintains one or more application components and you need that group to continue that maintenance. Breaking down the groups would necessarily mean a loss of expertise and cohesiveness that the organization can ill afford to lose.
APM is a critical technology for enterprises today. Successful use of APM helps the organization run smoothly and improves overall employee efficiency. In most cases, APM fails to work as anticipated because of a lack of communication between groups, rather than any lack in the APM software. An Application Performance Manager who truly understands the requirements for a successful APM implementation will promote communication between groups at multiple levels to ensure each group understands each other. This communication must take place in a way that embraces the integrity of the individual groups to maintain the expertise required to manage and maintain the various components that comprise the application.
Should the Quality Engineer be Invited to the Code Review?
Safest Career Choices for Developers (If You Don't Want Your Job To Go Away)
I Like My IT Budget Tight and My Developers Stupid
Corralling Heroes and Other Testing-Group Miscreants