Search Results

Ineffective development execution, causing errors, rework, and poor performance. New requirements, short timelines, and varying levels of staff experience lead to rising complexity. Combine this with a loss in subject matter expertise as retirements set in and a loss of current documentation, and complexity becomes pervasive. Complexity can take many forms: Technical complexity: The sheer size of applications means that it is impossible for a single person, or even teams of people, to understand an application. This translates into poor understanding of where to start on a project and how to account for potential impacts. This problem is compounded by a loss of experts skilled in some legacy languages and the diversity of languages across the application portfolio. It is made still more difficult by the progressive degradation of workable software architectures over time. Business complexity: This decline in technical understanding is multiplied by a loss of business understanding. Globally distributed teams cannot bridge the communication gap between business users and development professionals. Business users cannot communicate what changes need to be made to reflect business goals and development teams are unable to respond effectively. This becomes especially problematic in companies with highly dynamic business models or globally distributed development teams. Disbursed intelligence and teams: Different users have and require different information about their applications. A CIO may need to know the availability, cost and risk of the application portfolio. She herself knows the value of executing certain development tasks to support a larger strategic priority. But are these priorities acted on from a daily maintenance perspective? A business analyst may need to know the adaptability of the application that runs a key business process. He also understands the structure and sequencing of business processes from an abstract level. But do development team members share that critical insight? This is especially true in outsourced teams that may lag in their knowledge about an application portfolio. Addressing the Challenge: Business Intelligence for Applications How can we overcome the challenges of complexity to improve maintenance activities? The answer is by collecting and using business intelligence for applications. By sharing information about application portfolios across global teams, users can better respond to the needs of the business. And they can start reallocating resources away from the daily firefighting toward higher value activities. Business intelligence for applications allows the following: Managers to better prioritize maintenance activities based on business needs Business analysts to better communicate change requests Development managers to better focus effort Developers to better execute necessary changes Improved knowledge transfer between development teams But what does business intelligence for applications entail? Let's look at its constituent parts. Technical Insights Development professionals must be able to understand the complex structures and behaviors of their enterprise applications. This requires visualizations of how data and other elements flow through a system. It requires the ability to probe an application for artifacts of interest, such as variables that require extra security, elements that will be affected by a proposed change, or code that is inefficiently architected. It requires the ability to measure the size and complexity of the applications to assess the size of a project and focus effort. To fully understand the reality of our application portfolio requires rich technical insight. Rather than relying solely on high-level scans of artifacts, users must be able to assess their applications to a level that is useful. A manager or architect may find summary analytics to be sufficient. A developer will require highly detailed analysis within programs. Similarly, users will require technical insight across diverse applications. Application portfolios consist of software from Cobol to Java. Technical analysis must be just as inclusive. Business Insights Over time applications tend to lose their connection with the business function they were designed to support. This is manifested in the creation of names for variables, programs, and other elements that are impenetrable to business users. This requires a shared lexicon that allows business analysts and development teams to speak the same language. Additionally, it is important for users to understand the logic of how a system behaves. This logic describes business decisions like "approve discount if customer status equals 'gold.'" Governance of this logic allows analysts to better communicate how a process must adapt to support new goals. It also allows development teams to focus immediately on adapting the correct logic. Stakeholder Insights As discussed, users have different information and information needs related to the application portfolio. Complexity can be reduced by collecting relevant insights and making them available where necessary. For example, a business user may have insight into the purpose and behavior of a business process. Mapping this intelligence onto software assets allows development staff to more readily understand how code modifications should be executed. Other kinds of information can also be associated with applications to provide a richer insight. For instance, executives can assign value and risk to portions of the application portfolio. Similarly, cost and business service data like availability could be associated with an application. This metadata requires a mechanism for associating it with the underlying applications. Stakeholders have different levels within and different functions across an application. This means that their information needs will be different. A CIO will need a portfolio-wide view of her applications. A developer will need a deep view of a particular portion of an application. Similarly, a manager of a business process will require information about, say, availability and complexity, to be process-centered. The manager of an outsourcing relationship will require information about adherence to service level agreements to be provider-centered. This mechanism for grouping intelligence and abstracting it to the appropriate level is business contextualization. This aids maintenance by providing the right kind of intelligence to the right user in the maintenance process. Each will consume information in a different fashion for different goals. Let's turn to the three ways in which the intelligence is utilized. Assessment and management reports: Summary inventories and assessments provide managers with a foundation for planning maintenance activities. For instance, management may discover that maintenance activities are focused on burning platforms or non-strategic applications. Priorities can then be reallocated. In this case, complexity is overcome through intelligence on what the contents of the portfolio are. Portfolio management dashboards allow managers to track KPIs (key performance indicators) over time. This allows executives to determine where misalignments exist between goals like availability or efficiency and the reality of their applications. Complexity is mitigated by identifying priority development tasks and redirecting resources away from uncritical activities. This kind of information can be made manifest via browser-based dashboards. Similarly, managing adherence to service level agreements is especially important for outsourced or globally distributed teams. Collecting business intelligence lets management better partner with remote locations. Development teams: As discussed previously, business analysts and development teams are heavy consumers of the collected intelligence. They use the always-current, always-shared information to better communicate business requirements and technical challenges. The information is also vital for executing daily development tasks and more sophisticated modernization initiatives. Developers can understand the targeted applications, locate potential impacts, create test cases, and more. This is very true for outsourced or global development, where knowledge transfer about complex application portfolios must be a priority. In parallel, development managers will want to ensure that developers are focused on the right tasks. By constraining analysis within a defined "context," developers can see and analyze a sub-set of their application portfolio. This ensures that maintenance professionals are equipped with the information they need to focus on. Third-Party Software: Enterprise software tools are made significantly more useful when they can be connected to business intelligence about applications. Software tools that directly relate to applications but ignore the reality of the application code itself provide specious information. However, when used in concert with business intelligence about applications, they provide an extremely powerful combination: Requirements management tools can link with underlying software to estimate necessary effort. Integrated development environments can provide query results, such as impact analysis, that focus on areas in the application as they are being maintained. A test or build management tool could invoke services from the business intelligence repository to determine where complexity has risen, and if so, then the build may be flagged to fail. A source code management system could invoke a service to determine how code quality measures have changed between versions. A SOA/BPM suite can link coarse-grained business processes the atomic logic hidden within. Application maintenance is a serious drain on resources and can impair operational flexibility. Companies must make the maintenance process as effective as possible to ensure that applications can adapt to business needs. This requires that the challenge of complexity is overcome. This requires business intelligence on the applications that you are targeting. Charles Dickerson is senior vice president at Relativity Technologies, a provider of enterprise application modernization solutions. He has 20 years of product marketing and product management experience in the software industry. ...

North American manufacturers have faced years of intense, globalized competition. This onslaught compelled them to modernize their manufacturing processes to compete effectively. The result has been that many plants have become models of efficiency and agility. This modernization allowed manufacturers to more quickly adjust production to address shifts in demand and business goals...

Understanding the business and technical reality of your software assets is imperative in order to align them with corporate priorities ...

How many times have you read a book and realized that you can't recall a major character? Or, maybe you were left wondering how an important plot came to pass. The average novel contains 50,000 lines of text. Now, imagine a multimillion-line novel written by a team of authors over the course of decades that was repeatedly rewritten to the point that entire chapters were no longer relevant to the plot. That is the typical application portfolio of today...

As your business has grown, its office space requirements have changed. New buildings may be bought and sold as divisions are launched and canceled. Existing offices may be heavily renovated to make them more flexible and efficient, and cubicles may be constantly adjusted to support smaller organizational shifts. In each case, the portfolio of office space is adjusted based on the needs of the business...