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:
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:
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.
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.
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.
All the tools in the must-have set must be enabled for:
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:
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 info@In-Com.com