8 Ways to Fix Applications Fast, Fix Them Right and Save Money (Part 6)

We’ve looked at the importance of Application Discovery and Understanding tools over the past few weeks and have seen how we can use them to improve the quality and speed of application delivery. We also looked at the benefit tools such as SMART TS XL can offer, beyond Dev, in the test, deploy, release, and Ops phases of the Application lifecycle.

In this last part of the series I want to bring all the threads together and introduce a new concept.

We all know that the complexity of modern applications defies any human’s ability to fully comprehend their scale and scope. The consequences of a bad code change can be business-threatening, wiping out shareholder value, consumer confidence and profit margins. In the worst case, like at Volkswagen, it could even mean jail time.

Thankfully, modern tools deliver, in seconds, greater insight, more detailed analysis, and comprehensive conclusions that drive up quality, drive down timeframes and save huge amounts of money through fewer outages and much lower risk.

Feedback

But our modern development and operations processes still rely upon detect-determine-describe [1] of issues. Efforts, such as “Shift Left” move the burden for quality further to the left in the SDLC, i.e. towards the developers. Tools such as build automation and automated testing put the emphasis on the developers to deliver clean code. As Mukesh Soni says, the later defects are found in the lifecycle, the more costly they are to fix. Those that get through to production can have significant impact on a corporation’s profitability (just think about the cost of an auto-recall).

A critical step in building our DevOps infrastructure is to integrate and automate the technologies that make up your toolchain. The most important task in that automation is to create feedback loops that directly communicate, back up the lifecycle, that an error has occurred. If the automated testing fails, tell the developer. If the deployment fails, tell the release engineer. Google “DevOps feedback loops” and you get over 100,000 results and innumerable pictorial representations like this one.

But the detect-determine-describe approach results in actions that are too late.

Feed-forward

Today we have tools that can inform our decision-making in ways that were previously unavailable. We can use those tools to validate what we are doing, and we can use them to guide us to do the right thing in the first place. Most importantly though, we can automate these activities and continuously inform everyone in the DevOps lifecycle of the constantly changing application landscape - before they change a line of code, modify a production script, or alter a security setting. In short, we can “feed-forward” knowledge, insight and advice.

When we do this, we can ensure that the developer knows how widespread the impact of their code change could be. The release engineer can know that the database schema changed, so a database unload-reload will be needed. The data-center team can prepare new backup and security strategies since the app is running in the cloud. The biggest benefit is that we can do this weeks, even months, ahead of the impact occurring in the traditional SDLC.

So instead of detect-determine-decide, let’s process-predict-prevent [2].

Your DevOps toolchain starts here

Application Discovery and Understanding (ADU) tools provide us with static, moment-in-time appreciation of the current state of our codebase. These tools rely on Dev and Ops team members to utilize. ADU tools need to be AADU-M, Automated Application Discovery, Understanding and Monitoring tools. Tools that constantly process all the application sources (logs, inventory, etc.) and that feedforward knowledge, insights and advice to those responsible for the evolution and execution of our applications.

Because AADU-M tools, like SMART TS XL, have the ability to inform and enrich every step of the SDLC, it needs to be at the heart of your DevOps toolchain.

Recap

Here’s a recap of our past blogs and links:

Part 2

1. The change, the whole change, and nothing but the change – making sure every impacted piece of code is changed
2. Tracing data as it courses through the application – looking at how you can find every place where data is input, read, modified, tested and output

Part 3

3. Understanding dependencies – mapping all dependencies matters, but finding them is hard
4. Complexity can be calculated, and it matters – learning how to use technology to determine which team member would be best to make the change

Part 4

5. Modernizing your application – if you are porting to another platform, where is the code that is going to be most difficult to change
6. Application Understanding is the heart of your DevOps toolchain

Part 5 

7. A picture paints a thousand words – using application visualization to get rapid understanding
8. No application is an island – understanding application ecosystems at runtime

In closing

This blog series will be available shortly in an eBook from IN-COM. We’ll also provide additional content that you can use immediately to learn more about why Application Understanding is essential for modern application developers.

For more information check out these instructional videos, or you can request a demo.

[1] Detect-Determine-Describe is how we handle production outages: we detect the problem, then we determine the cause and we notify the team that can fix it.

[2] Process-Predict-Prevent means to continuously process or inventory of code, logs, documentation, data sources, scripts, and every other digital asset of our application and collate that data into useful insights that we share with the Dev and Ops teams. This enables us to predict when bad things will happen so we can prevent them.

VIEW ALL THE POSTS IN THIS SIX-PART SERIES

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6