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

By Kevin Parker

We have reached the halfway point in this short series on the essential value to be obtained from automated Application Understanding tools. The prior post looked at the powerful abilities of SMART TS XL to analyze applications. We saw how the presentation of those analyses, in an interactive manner, allows for fast interrogation of the data. This brings rapid comprehension of the interdependencies and complexities among programs, scripts, data-sources and unstructured dated (such as documents).

This week we’re looking at:

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

Next in our DevOps journey, we’re going to look at the interesting issue of application modernization. We’ll consider the DevOps toolchain and talk about the key elements you should be bringing together. Application Modernization comes about for a variety of reasons:

  • The application is old and needs replacing because of concerns with things like the application’s speed, volume, user interface, API support, architectural weaknesses, security, cost to maintain, lack of support for the platform and so on. Portfolio Management tools help to track the ongoing investment in an application, but you also need technology that can calculate the complexity and stability of the application over time.
  • More frequently these days is an organization’s shift to a SOA-based architecture. As we push the user interfaces further out and distribute the data, we need to atomize the processing so that it can be reused wherever needed. Many applications written in the '60s and '70s are monolithic, and even the ones from the '80s and '90s are based on large functional units.
  • Some organizations are consolidating platforms (and platform vendors) from n-tier (cloud, mainframe, mid-range, server, PC, device) and moving a much flatter topology. Often, they will look to “lift and shift” the code from one platform to another with minimal changes. They assume that industry compliant code will run on different OS and hardware. "Write once/run anywhere" languages like Java are supposed to do this, but they are often optimized for the platform.
  • Realignment of business functions drives the consolidation or fragmentation of legacy business applications, and these changes are often driven by mergers and acquisitions.

What do we need to consider when we begin to modernize our application? When application modernization occurs, two things are always key objectives. First, preserve the business logic, intact as far as is possible and, second, future proof the result to push the next modernization-initiative as far as possible into the future.

Business Logic

Let’s consider the business logic. Depending on the age and architecture of the application, the business logic may be found  isolated and already reusable in one place. More likely, however, is that these business processes are dispersed throughout the application. They're often duplicated, sometimes duplicated but with different behaviors, and frequently with exceptions to the process localized in the UI or other non-core piece of the application. This means not only pulling all those elements together, reconciling any differences (if any), and generalizing exceptions into the overall business logic. How can you be certain that you  found all the instances where data is transmogrified by a specific business process without a powerful, intelligent, language, platform, architecture, topology-independent technology?

Because SMART TS XL can understand dependencies at both a process- and a data-level it is possible to search the application inventory and find all the code fragments that CRUD (create, read, update, delete) any data structure, data group or data element.


As I have written before, “software engineering is the only engineering discipline that thinks ‘standard’ is a plural.” Of course, things evolve and so do those standards that support them. This is especially true of programming languages. Not only do languages vary from standard to standard but also from vendor to vendor. This means that if you're going to merely “lift and shift” the application from one platform to another, you need to be able to find the non-standard, deprecated and non-compliant code in the application that needs remediation. Once again, the powerful, intelligent search capabilities of SMART TS XL can simplify this task and reduce the time to completion to a fraction of what would be required with conventional search tools.

Furthermore, you can set up SMART TS XL to monitor the inventory on a regular basis to ensure that code is not being added that will cause a problem in the future, and to ensure programmers are following the coding recommendation and guidelines provided by their organization.

DevOps Toolchain

Much has been written on this topic. Some believe that, because DevOps is about culture and process rather than about tools, this should be secondary issue. My view is quite the opposite. Since DevOps is about effecting a cultural change that streamlines processes, engenders mutual accountability and responsibility and results in shared ownership and values, it matters how we get there. Inspirational talks by DevOps leaders help, but what all successful DevOps initiative managers will tell you is that automation of processes, especially handoffs, is the most significant success factor.

We use the terms Continuous Integration, Continuous Testing, Continuous Deployment and Continuous Delivery when we talk about DevOps. Each of these describe the use of automation tools to initiate builds, tests, pushing code through test areas and ultimately delivery to production. But these are all post-development. What about pre-development: before we change a line of code?

As we have seen before, SMART TS XL automates the sizing and calculating of effort and complexity so that your Agile teams can estimate accurately the size and scope of required effort for any sprint. Its formidable search tools that shorten development times and drive up developer accuracy. And for extensive refactoring projects, the graphical and interactive analysis tools help organize and coordinate the development effort.

So here is my list of the minimum set of tools required for a complete toolchain.

Must Haves
  • Issue, defect, task, Kanban, management (NOT: Microsoft Excel or Word)
  • Application Understanding tool
  • Software change and configuration management (NOT: version control, code management)
  • Build automation for Continuous Integration (CI) (NOT: Scripting)
  • Test automation tool
  • Application deployment/delivery automation
  • Application performance monitoring
  • Service desk


Nice to haves
  • Project management 
  • Collaboration tool
  • Portfolio management
  • Requirements management (NOT: Microsoft Word or Excel)
  • Prototyping/Blueprint tool
  • Static code analysis
  • Test coverage tool
  • Test data generation tool
  • Load and performance test tools
  • Environment provisioning tools

 All the tools in the must-have set must be enabled for:

  • Feedback – they must provide immediate feedback to the developer if the check-in fails, the build fails, the test automation fails, the deployment fails etc.
  • Handoff – they must deliver, automatically, the complete set of assets needed in the next phase of development and prevent delivery if the set is not complete
  • Integration – at both a data- and process-level, so that the steps in the SDLC are followed
  • Telemetry – they must spin out an audit trail of activities so that dashboards can be developed, trending data can be analyzed and Lean process improvement undertaken

You may already have tools in place that provide these capabilities and, if they are capable, there is no reason why they should be replaced. Make sure that you have the latest version from your vendor and ask them to update you on the latest innovations they have produced to support DevOps. There’s a good chance you will be able to complete your toolchain from the tools you have already. If you modernize your existing tools and invest in those that you do not have you can significantly reduce the cost, and upheaval, that can occur.

Next time we’ll look at:

  1. A picture paints a thousand words – Using application visualization to get rapid understanding
  2. No application is an island – Understanding application ecosystems at runtime

We’ll introduce you to several case studies and take you through how real clients tackled complex problems with SMART TS XL. We’ll also provide additional content that you can use immediately to learn more about why Application Understanding is essential for modern application developers. We’ll feature the special challenges facing mainframe developers and show how they too can improve their software development lifecycle.

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

You can contact us at +1 (214) 774-2284 or email us at


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

Tags: Application Development, DevOps