6 Values Developers and Operations Share in APM Solutions
Test and Monitor | Posted August 14, 2014

In a recent post, we looked at the external APM ecology: what factors help promote the use of APM in the organization. While the on-site Dev and Ops cliques have their own desires and needs, they both have common interests. Those common interests should show up in an APM solution that they can both use successfully.

1. Common Data

Nothing starts a food fight in the company cafeteria faster than data that is not shared across the organization. Alice gets her results from her data, while Bob has his results from working on different data. To ensure both Alice and Bob will work on the same data in their analysis is not just an option. It’s a necessity.  It also removes a potential source of error that cannot be effectively corrected by other means.

The waters of APM can get muddied easily in any case. To handicap your effort with different people using different data will muddy those waters even further and unnecessarily. This is something that Dev and Ops will easily see as a common objective of them both.

2. SaaS

Instead of performing onsite development in order to get any APM functionality, it’s become evident to almost everyone these days that SaaS is both capital-friendly and frees up onsite personnel for customer-facing efforts. The SaaS vendor takes the responsibility for the software as well as the virtual hardware necessary to perform the task at hand. The vendor also takes on the chore of updating the software used in the solution.

One thing SaaS can help with is the the common data aspect mentioned previously. SaaS solutions will usually present data in a consistent manner, so that all of the team sees it similarly. SaaS can be part of the commonality effort without any additional effort needed.

3.Tool Integration 

Ops people will generally want an APM solution that they don't need to tweak much. They are busy keeping the wheels rolling for everyone. But they want needed alerts to show up while they are greasing those axles of the business. That means whatever will generate the alerts better be right when it pulls the whistle and stops the line from rolling. It also implies that there will be an accessibility to that common data from anywhere across the web. Once you have that, real time monitoring is  a snap, for example.

To be right more than it is wrong, the alert tool we use as an example has to be able to see what are the results of other tools are. Sure, there are rules about what constitutes an alert; but those rules will depend on the output of other tools. If they can't talk to each other, the alert generator will be blinded in its functioning. Just as other parts making up the APM solution will be as well if overall integration tools is not present.

Developers want alert tools to be working without problems as well. That’s because Developers hate to fix things. They only want to be taken away from their designing when it is doggone necessary. And when they are bothered, they want all the data that comes along with the alert they need a deeper granularity of the available data than Ops will, Ops will care more that the problem exists rather than how to fix it.  With unification of the tools present in an APM solution, both groups know that they will only get rousted for a situation that has a real need of their insights.

4. Continuous Delivery 

Apps have a lifecycle, like any other product. How that lifecycle is managed is something that both Dev and Ops will watch carefully. Both want the process to flow smoothly as the app moves from development to production.

Ops has to take over from Dev at some point in the cycle. The handoff between the two can be smoothed by APM tools that are integrated into the lifecycle at the right point, which usually occurs way before testing of the app is even done. If you are testing something, radical changes are usually hard to implement. But if you incorporate tool results into the design phase in a preemptive manner, you can change the design parameters to reflect what the tool tells you is happening.

The integration of applications in the solution is also a factor in the lifecycle. If not integrated, the lifecycle can develop internal blockades when the output of the previous part of the cycle is lost to another part of it that follows. These kinds of blockades are not good for any efficiency, or the ability to use a deployment/develop/deploy again effort. The entire lifecycle process is speeding up and iterating. Not having all the tools that go into the lifecycle able to work together is a significant handicap for both Devs and Ops, and a roadblock to continuous delivery.

5. Visibility 

Dev and Ops are united in their desire to know the reasons behind application problems. In order to gain this visibility any system used to measure and diagnose the application needs to provide a rich set of detail across application components both software and infrastructure. . For example, there may be third party APIs and services in use by the apps. APM solutions have to be able to show where this kind of boundary line is located, and what is required by tithe those external parts.

This is more than a deep dive into the data. Visibility means that you can see where data lives, whether the app massaging the data is yours or if it is someone else’s that then hands it back to you.

6. Usable Granularity 

Dev and Ops (as well as the business person on the team) have differing requirements on the granularity of data that they will routinely use.  This arises from the things each must focus on routinely. The business guys generally want a high level kind of view: how good are things going right now. They know that the user experience translates into money. Ops will usually want the alerts, as I mentioned before. Dev treasure code level views as they spelunk about the situation.

All of them will use differing granularity at different times. A solution can’t just provide only one kind of view, no matter how correct that view is. The ability to change the granularity of the view is needed by all members of the team, no matter their usual pigeonhole. The flexibility of variable granularity is always appreciated.

You Might Also Be Interested In:

Next Generation APM: Unified End-User Monitoring [Interactive eBook]

NEW AlertSite UXM Unified Platform – FREE 30-Day Trial

Digital Guide to Unified User Experience Management [Interactive eBook]

An APM Solution Divided Cannot Stand [Blog post]


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox