This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - ALM development, projects and processes: Read more in this section
- Getting business leaders involved with ALM process
- Virtual applications for ALM
- Tools for SOA ALM processes
- Unified DevOps approach to ALM
Explore other sections in this guide:
Enterprise architecture (EA) and application lifecycle management (ALM) are in many ways strongly symbiotic. By formalizing the relationship between business goals, processes and information technology, EA can make it easy to establish governance policies that can be input into the standards of functionality and performance that ALM enforces with its release management discipline.
The problem with this happy union is that as applications become components and are freely used for multiple missions. It's hard to retain EA ties to ALM because the addition of a single component to an application can change everything. IT and EA professionals can use virtual applications to link EA and ALM and improve both governance and application quality.
Most companies have practiced inheritance in creating linkages between EA and ALM and between components and governance. An application has a set of governance policies created by the EA context and the components inherit those policies. Component reuse creates multiple inheritances but becomes increasingly difficult to manage as applications become more componentized and the number of inherited rules explodes.
Since an application in a componentized world is essentially a virtual construct, it's possible to use virtualization/abstraction principles to find a way out of this inheritance dilemma. The goal is to define virtual applications based on how users break down into information-based job categories and how federated IT defines information dependencies across organizations. These virtual applications can then be used to frame governance-based ALM practices.
If your company has already created inheritance mappings between EA/governance and components, you can start with the results of this process. Forget for a moment the current application boundaries and group application components based on common links upward to business processes and business units. This can often be done by collecting components with common governance requirements. The result will be functionally defined virtual applications, components that support common activities.
Enterprise architecture progressions
If inheritance mapping has already gotten out of hand, or was never successful, the best way to create virtual applications is to follow EA progressions from the top down such as the following:
The logical way of looking at an application is to assemble the components based on business function mappings.
- Business goals to business processes
- Business processes to technical/information support of activities at the functional level
- Functional support to components that provide it
At the critical level of functional support, most EA models will link business functions to technical functions, and that's where virtual applications come into play. Regardless of how applications are currently structured, the logical way of looking at an application is to assemble the components based on business function mappings.
Components that are united in support of common business applications are virtual application members. You can name the virtual application for the operational/functional groupings you've defined in EA. Note that the way this gets done depends somewhat on the specific EA model used, but all the models will follow the progression described here.
Another tool in creating EA-based virtual applications for ALM is the specific IT elements involved in any federated IT architectures that were exposed/developed by EA. Federated IT is typically used in EA models for decentralized businesses -- ones that operate as independent business units -- to define how information and technology components are shared.
EAs and IT architects both report that components associated with federated IT relationships are typically supporting either horizontal functions like payroll and personnel or the highest-level business goals. In many cases, grouping other components around magnet components creates an optimized collection of component-driven virtual applications. Federated IT approaches to virtualized application creation can also be used to double-check the results of either the inheritance or process-driven mechanisms described earlier.
Meeting business goals
When you have a collection of virtual applications, the next step is to align these with your "real" applications using a simple diagram to show overlaps. This will do two things: help relate virtual-application ALM with actual applications and tell you whether your real applications are structured optimally to serve your business goals as defined by your EA model.
Where real application boundaries have little correspondence to functional/operational virtual application boundaries, your software isn't mapped well to business processes and you may benefit from rethinking your software solutions. Applications that cross many virtual applications show a distinctly horizontal technology orientation that may not accommodate the special needs of your own vertical market. It also makes governance more complicated because any application change impacts every operating unit.
More on virtual applications
Dos and don'ts for virtualizing apps
Best practices virtualizing applications
Value of virtual app delivery controllers
Pros and cons of virtual apps
Once you have a real/virtual application relationship map, you can decide whether to frame ALM totally on virtual applications, on real applications, or both. Companies report that where component reuse levels are high, virtual application ALM makes more sense because the virtual applications map components to business functions better, facilitating testing and governance.
Where component reuse is low-staying with real applications in ALM practices, keep a careful eye on componentization trends and the relationship between real and virtual applications over time. A shift in componentization will quickly change your ALM balance more toward virtual-application mapping.
Some users who have tried the virtual application methodology complain it increases ALM complexity by forcing more conformance testing and validation for a given component change. That's simply not true; proper ALM has to test applications in their business context and that's what creates complexity with component reuse. Virtual applications only uncover the complexity and that's a far better outcome than ignoring business issues in ALM practice definition.
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.