Showing results for 
Search instead for 
Did you mean: 

Application Performance Monitoring: APM In An Agile World

Level 10

Hopefully, you have been following along with this series and finding some useful bits of information. We have covered traditional APM implementations in part one, part two, and part three. In this post, we will begin looking at how implementing APM in an agile environment is much different than a traditional environment. We will also look at how APM is potentially much easier and more precise when implementing in an agile environment.

Differences between Traditional and Agile

From what we have covered up to this point, it should be very clear what we are talking about when we refer to traditional APM implementations and what we have referenced as “after-the-fact implementation.” This is when APM is implemented after the environment has already been built, which includes the application being in production. Again, this scenario is more than likely what most are familiar with.

So, how does an agile environment differentiate itself from an APM perspective? When implementing APM in an agile environment, all the components related to APM are implemented iteratively throughout the agile process and lifecycle. What this means is, as we build out our environment for our application, we are at the same time implementing the APM constructs that are required for accurately monitoring application health. By doing so, we can effectively ensure that we have identified all the dependencies that can affect our applications performance. This means that we can also implement the correct monitoring, alerting, etc., to identify any bottlenecks we may experience. This also includes the application itself, which means that we can also identify any potential issues that may have been introduced from our applications' iterated versions along the way. Another important aspect that we can identify along the way is a true baseline of what we should consider normal application performance.

Application Dependency Mapping

Adding to what we mentioned above regarding effectively identifying all the dependencies which can affect our applications performance, while we are building out our application, we should be mapping out all the dependencies. These dependencies would include things we have mentioned previously, such as load balancers, hypervisors, servers, caching layers, databases, etc. When identifying these components in an agile environment while managing the applications, lifecycle should be much easier to identify. By effectively mapping out these dependencies along the way, we can begin implementing the proper monitoring to begin identifying issues along the way. Equally as much would be that if for some reason during our application's lifecycle, we decide to implement something new or change something, we can easily adapt our monitoring at the same time. Now, you may be thinking to yourself that this could be accomplished in a traditional method as well. While that is absolutely true, the chances of forgetting something are much higher. This is not to say that an agile environment is not equally as suspect to forgetting something, but because we are continually iterating throughout the implementation, those chances are at a minimum.


So, to put these thoughts into perspective, let's look at a quick scenario:

We are working in an agile environment, which means we are hopefully iterating on our application every 2-4 weeks as sprints. After our last sprint release, we decided that it would make sense to implement a message bus for our application to communicate over. We decided this because we identified an application performance issue when making certain calls between our application stacks, and we have the performance data to back that up with. So, we have decided that during this next sprint, we will implement this message bus in hopes of resolving the performance issue that was identified. After doing so, we can begin observing through our APM solution that we have absolutely resolved that issue, but uncovered additional issues based on our application's dependency mappings that is affecting another tier in our application stack. We are now able to continually iterate through our application's dependencies to increase performance throughout the lifecycle of our application.


As you can see, implementing APM in an agile environment can absolutely increase the accuracy of our application performance monitoring. Again, this does not mean that APM, in a traditional sense, is not effective. Rather, in an agile environment, we are easily able to adjust as we go throughout the lifecycle.

Level 21

First off, the topic.  APM is a great tool that should be used by more IT people to accomplish worthy goals.

Being Agile is one way of defining and working towards those good goals.

Traditional methods may not need to be scrapped just to adopt agility.  There are good things from the past, and we don't throw away someone merely because it's old.  We leverage its strengths and meld them with new methods like being Agile.

APM certainly facilitates this process!

Second off, the method.  May I offer a friendly, kind, and gentle set of ideas about how complex this article appears?

My first take away was the topic seems quite . . . nebulous.

  • "hopefully iterating"
  • "it would make sense to"
  • "will implement this message bus in hopes of resolving"
  • "we can begin observing"
  • "continually iterate through"

After reading it one may not feel that there's a real method defined that someone can use.  It's not yet a goal that was won.  A person probably will have to read much of it more than once to get a gestalt.

We're not uneducated, but the buzz word factor of the scenario is high enough that it could be lowered and the work would be better.  Effective communications in business communications, like the example above, can be improved by improving the readability score of a sentence, paragraph, or book.  Replacing longer, less common words with more common words of fewer syllables results in greater understanding by readers.  The scenario paragraph might benefit nicely from that kind of analysis and change.

The result is our Thwacksters have received information they can comprehend the first time through, and they've been given a great example to share with peers!

Understand, this is not criticizing the work.  This is a friendly and gentle observation that it's easy to get caught up in verbosity and jargon that might make it harder for readers to use the data..

Have confidence!  This is great information, and Thwack and other readers need the ability to communicate these ideas.  Leverage fun tools that help writers understand what may be need to improve how readers can get more out of a paragraph.  Like using readability engines.

Readability is represented by a variety of scores that compare total word count to the number of syllables per word.  The short and easy way to think of it is that you can reach more readers by:

  • Using more words with one or two syllables, and less with three or more
  • Feeling OK about writing in simpler terms
  • Looking to get good marks from each level of reader, so they get more out of your content.

In those three lines there was only one three-syllable word, and no words with more than three syllables.  The ability of someone to get my ideas from those lines is made simpler.

There are several online readability engines.  They can rate how many years of formal education a person should have to be able to understand a paragraph.  It's not bad to target eight to ten years, because loads of people forget much of their training as they age.   Yes, there are plenty out there who can understand at a level of sixteen years (twelve years of public school plus four years of university training), or even more! But targeting the doctoral candidates may limit your audience . . .

Here's the output of one after I pasted the Scenario text into Tests Document Readability .


Level 13

Thanks for the article.

Level 10

Glad you enjoyed. HOPEFULLY, YOU got at least something out of it

Level 15

Thanks for the write up!
Level 16

Thanks for sharing

Level 14

Liked the article but really liked the Readability Tool.  Might use this to check my documentation in future.  Of course you need to get someone to RTFM first before they can understand it.

Level 13

Thanks for the article. 

Level 19

We've got lots of SCRUM masters around here... it does help develop some things and get products out quicker but I'm still not convinced this is really something new.

Level 10

You are definitely correct. Nothing new at all. But new to some for sure.

Level 14

This is a nice off topic tool.  Thanks rschroeder!