devopsy.kinsta.cloud

Tag: application discovery

  • Best Practices for Software Change Assessment

    Best Practices for Software Change Assessment

    Business spending on enterprise software has been on a constant rise over the past decade with 64% of businesses spending more on IT operations in 2018. It is estimated that in 2019, the number will reach $462 billion worldwide. This not only includes the procurement or development of new software and digital innovations, but also investments in modifications and upgrades.

    However, implementing software changes is no easy feat. It involves serious financial investments and staffing resources, which is why it is critical to get it right. A well-implemented change assessment is a key component of every software change project. This gives decision-makers an accurate and complete understanding of the impact of the software changes and identifies potential disruptions to specific departments, functions and processes.

    There are many ways to approach and implement software change assessment. These best practices can ensure a glitch-free software change rollout.

    Use a Comprehensive Discovery and Dependency Mapping Technology

     One of the disadvantages of the modern workplace across all industries is the emergence of information silos. They can hamper growth and efficiency and cause other problems, including redundancy of effort, stalled collaboration and other missed opportunities.

    In order to break these silos, efficient application discovery and dependency mapping is a crucial step in every software change project. Unfortunately, most businesses are failing miserably in this department. A Forrester survey revealed 56% of IT managers “do not have a complete view of dependencies between applications or between applications and infrastructure.”

    The same survey revealed 30% of the IT managers think that having a complete inventory of all enterprise hardware and software in use at their organizations is critical for IT efficiency. Ironically, 42% do not collect the necessary software data, while 39% are maintaining their inventory manually.

    The disadvantages of inadequate discovery and inefficient dependency mapping include low productivity, project delays, increased overhead costs and poor team morale, among others. A key step in solving this predicament is investing in the right discovery and dependency mapping technology, which can support a solid foundation for a software change initiative or any IT project for that matter.

    A reliable, agile software solution should provide both macro and micro views. The more granular, the better. Additionally, it should be able to give IT decision-makers a consolidated view of their application stack across multiple message queues, APIs, databases, unifying codes and languages.

    Use the Seven R’s of Change Management

    One thing IT managers should realize when assessing software change is, they’re not pioneering the process. Many organizations have done it and made mistakes along the way. Experts have used these mistakes and learnings to create roadmaps for others.

    One of the most well-established resources for IT change management is the Seven R’s of Change Management conceptualized by Information Technology Infrastructure Library–a set of detailed practices for IT service management. The seven Rs represent the following questions designed to help businesses make educated decisions on how to proceed with change requests.

    1. Who raised the change?
    2. What is the reason for the change?
    3. What return will the change deliver?
    4. What risks are there if we do or do not carry out the change?
    5. What resources will be required to perform this change?
    6. Who is responsible for this change being performed?
    7. What relationships are there between this and other changes?

    While these concepts are not exclusive to software change assessment, they provide a solid framework for businesses to identify noteworthy software change projects. This is especially helpful for organizations creating their software change assessment protocols from scratch.

    Never Skip Impact Analysis

    This is especially important for software vendors who are operating on tight budgets and strict deadlines. Software change impact analysis encompasses five major areas:

    • Identifying the impact of the change request on the software development project or on a business’ IT infrastructure.
    • Determining all software resources that need to be modified to implement the requested change.
    • Calculating the cost and manpower capital needed to perform the change request.
    • Ensuring the requested change complies with internal and external regulations.
    • Eliminating or minimizing any security risks associated with the change.

    To make sure businesses covers all the bases for any software change initiative, it’s best to use a checklist or template sourced either from the technology vendor or one their IT team put together, tailored to their needs.

    Not All Changes Are Created Equal

    Today’s ever-changing business landscape dictates business technology must evolve to keep up with an organization’s shifting needs. Software changes, when implemented strategically, can help businesses achieve new heights in productivity, efficiency and profitability.

    To ensure software changes serve this purpose, IT project managers need to implement an airtight software change assessment system. With the help of technology, checklists and well-established industry best practices, organizations can quickly outline a process that yields beneficial results in the end.

    — Aditya Sharma

  • Application Discovery and the Value Proposition of IBM Z ADDI

    Application Discovery and the Value Proposition of IBM Z ADDI

    Discovering how an application works can be a difficult, expensive undertaking. That’s why architectures based on REST are so popular. The architectural style provides an easy-to-implement interface that allows consumers to use an application productively without having to understand anything at all about its internals. All a developer needs to know to work an application is how to interact with the resource represented by the given endpoint. What’s going on behind that endpoint is another matter.

    That’s the good news.

    The bad news is that when it’s time to make changes to the application’s internals, things can get difficult. Many times a well-defined interface is hiding a pile of spaghetti code. Sometimes a developer might be able to find an analysis tool that will help make sense of things. Or, maybe there’s documentation that explains it all. But, it’s not unusual for developers to have to bite the bullet and go through the source code and deployment scripts line by line to figure out how the application works. Such work incurs significant expense.

    Discovery: Understanding Dependencies in an Application

    Mainframe developers have been solving the problems of application discovery for years. IBM has been at the forefront of addressing application discovery with a comprehensive solution called Application Discovery and Delivery Intelligence (ADDI). ADDI allows a developer to inspect a IBM Z mainframe application and analyze its performance.

    Application discovery is accomplished using Application Discovery Intelligence (ADI), which is part of the ADDI toolset. Developers and system analysts use ADI, which integrates seamlessly into the Eclipse integrated development environment (IDE), to discover the assets used in an application and also to determine the dependencies between them once discovered.

    Figure 1 below shows an example of the ADI graphical interface. The IDE provides a high level overview of the application (1) as well as a listing of its components (2). Developers can drill down to look at details in a central viewing pane (3). The IDE provides a detailed listing of  a component’s connections and associations, such as subscriptions to message queues or SQL calls (4). Also, developers can view details about a particular assets, such as a SQL query (5).

    Figure 1: Application discovery intelligence describes components in an application and describes interactions between them

    Having immediate insight into the structure and operation of an application reduces the expense required to improve it. Developers save a lot of time not having to peruse code on a line-by-line basis. Yet, this is only part of the cost-saving. Understanding the composition of an application is an important first step. Understanding how an application performs is essential for implementing improvements. This is where delivery analysis comes in.

    Delivery: Providing Quality Service 24/7

    Ensuring quality service on a 24/7 requires that availability of up-to-date runtime information. A good performance monitoring tool provides the ability to to drill down to determine the cause of an issue. IBM Z provides such as array of tools. Remember, meeting service agreements to specification is and has been a critical activity in the mainframe computing culture. It’s part of a mature business process.

    IBM Z Application Delivery Intelligence provides mission-critical insights on a drill down basis. As shown below in Figure 2, IBM Z Application Delivery Intelligence Analysis reports a dangerous condition (1). Then, engineers can drill down to view associated metrics (2) and then even deeper, to view a timeline that shows environmental conditions such as response time from the database and CPU time consumption (3).

    Figure 2: IBM Z Application Delivery Intelligence provides drill-down reporting that allows engineers to identify root causes

    One of the drawbacks of architectures that aggregate heterogeneous systems is that relationships between components become opaque. For example, an application that uses a database service to store and retrieve data has no direct insight into the underlying query behavior of the database service. All that can be accurately reported is the request and response time to and from the service. However, when both application logic and data storage reside inside the same location, reporting details becomes easier. But still, drill-down correlation between systems is still difficult when components are in a common location, such as a virtual machine, yet isolated from one another due to strict encapsulation. Mainframe systems, however, do not have the problem because all components reside in a single location in which access to components is transparent. Thus, cross-component drill-down is easier to accomplish.

    Built to Scale in the Modern Cloud

    When it comes to computing at scale, mainframes were always meant to handle multiple users in a high-volume, transactional environment. Mainframe computing does not lend itself to the type of latency bottlenecks that come about when there are racks of commodity PCs operating with with varying degrees of reliability. The hurdle that mainframe computing had to overcome was making it so it could be accessed using standard web-based standards, most notably REST. IBM addresses the problem with z/OS Connect, a technology that allows IBM Z application functionality to be represented by a REST API. Once a REST layer is added onto an IBM Z system, it becomes just like another resource in the cloud computing ecosystem. And, an IBM Z mainframe computer is designed to be fault-tolerant and highly available. There are IBM Z systems in production that have run without interruption or downtime for decades.

    Making Discovery and Delivery Less Expensive

    Discovering how an application works and ensuring that applications in production meet performance expectations are two of the most important activities in today’s modern enterprise. Application Discovery and Delivery Intelligence provides the tools to meet these needs in the IBM Z cloud computing ecosystem. Using ADDI provides the insights necessary to ensure that service level agreements are met cost-effectively to the satisfaction of all. When it to making applications that matter in a world of web-based computing, ADDI provides an essential value that is difficult to match.

    — Bob Reselman