With any new network monitoring and management software, the first step is to assess your existing inventory. Do this by allowing the software to discover all your devices. Your new software may alert you to things you didn\u2019t know you had. Network monitoring and management tooling may be smart enough to propose ways to improve your system: it might suggest new configurations or highlight bottlenecks. Your last step is to let the Simple Network Management Protocol (SNMP) traps flow and inform you about day-to-day network usage.\nOne blessing of the OSI model is that it has enabled innovation at the individual layers. These layers are abstracted from one another, which prevents accidentally injecting dependencies into other layers. The curse of the OSI model is that it has socially separated the people who work at the individual layers from one another\u2014someone working at one layer may never think of someone else working at a different layer. It\u2019s a recurring problem in network monitoring and management, in general.\nWhile looking at the network layout and the packet flows are important, doing so without the context of the applications running on top of the network is limiting. It\u2019s like trying to analyze your energy consumption by looking at an electrical wiring diagram at your home, without considering the appliances plugged into it. Without examining the stresses that applications place on a network at Layer 7, you have an incomplete picture of Layers 2 and 3. Application management gives you a better angle, and these services are in high demand. The network monitoring sector is experiencing explosive growth. Here\u2019s a rundown on how the systems work:\nAgent vs. agentless\nThe first question to ask when evaluating an application management and monitoring platform is, \u201cHow is it collecting data?\u201d There are two formats to consider: agentless and agent-based.\nAgentless system: Developers add lines of code at different intervals that explicitly collect data and send it off to another part of the application management platform for storage and analysis.\n\nFun fact: developers hate this approach because it creates dependency on their code and that typically slows them down. For a group of people that are measured by how quickly they can get software out into the hands of customers as part of a feedback loop, slow is bad.\n\nAgent-based system: In this kind of system, a little daemon runs alongside the main application component and collects data, unbeknownst to that component. For application monitoring platforms, the daemon binds to a language runtime. From that language runtime, the system collects data and sends it to other parts of the application management platform for storage and analysis.\n\nDevelopers prefer this approach because there\u2019s no dependency creation. Remember, slow is bad.\n\nAgent-based systems divert resources away from the main components of an application, so some IT folks may find them a little evil. But is that resource-suck such a big deal? If agents syphoned off 10 percent of resources (usually it\u2019s less than 2 percent), you would be running 11 containers or VMs of functionality behind your load balancer instead of 10. In the past, when we thought of compute resources as pets, that number was a big deal. But in the cattle-based microservices world we live in now, it\u2019s trivial.\nGetting the bigger picture\nWhether your platform takes an agent-based or agentless approach, these systems add a transactional identifier to the network headers. This way, different components of the application\u2014like databases, queues and application servers\u2014communicate with each other, allowing the system to form a larger picture of the interactions once it collects all the data.\nThe result of this larger picture is an application architecture diagram that shows the interactions among the different components. Just as a network monitoring and management platform is guilty of ignoring Layer 7, an application monitoring platform is guilty of ignoring Layers 2 and 3. The generated diagrams will therefore not contain routers, switches, and other network components that are invisible at Layer 7. \u00a0Networking diagrams can be tricky to maintain manually, and application diagrams are similarly difficult. This automation not only makes the developer\u2019s life easier, it provides a map within each network and application engineers can have constructive conversations.\nTransactional tracing\nProcesses become streamlined with an application architecture diagram in place based on data collection approaches. Application monitoring and management platforms will be able to use that diagram to show individual and aggregate transactional flow between the components. This is where the combination of application and network tools synergizes.\nHere\u2019s a real-life example:\n\nAs load increases during a busy time of day, an e-commerce application sees an increase in transactions.\nAs the load increases, the application adds more VMs or containers in response. Eventually this latency creates a bottleneck between a web server and a database server.\nWithout an application monitoring and management platform in place, the development team might point the finger at the networking team. IT would then propose physically adding more bandwidth to the system.\nBut wait\u2014an application monitoring and management platform would be able to discover whether or not the business logic components are responsible for using up the existing network bandwidth and causing the bottleneck. The platform could analyze the memory those servers are using during peak load, and it would be able to indicate whether data is being cached effectively at that layer. It could stop an application glitch from unnecessarily putting stress on the network.\n\nWhen used in conjunction with a network monitoring and management tool, application monitoring and management tools can paint a broader picture of usage, spanning more layers of the OSI model. This can help remove the social barriers that the OSI model accidentally creates between people that populate teams.\nClassic network management and monitoring tools remain vital, but using them exclusively places you in a vacuum. Instead, using network and application management and monitoring tools together better utilizes resources, optimizes applications and reduces friction between different sets of employees.