I re-visited a Gartner article dated September 2006. It says that Enterprise Architecture road maps can include more explicit life cycle information — showing, or example, the exit timings for technologies in addition to the adoption timing. They can show the overlap of change from older to newer technologies as well.
Any given element of technology depicted in the technology road map could be subdivided into life cycle stages, such as:
• Emerging (available for limited use in new implementations)
• Mainstream (strongly recommended for new implementations)
• Containment (installed and still requiring support)
• Retirement (installed and scheduled for retirement)
In my opinion this view by Gartner is useful when deciding, for example, what platform/technology to use for the development of a new application. One would preferably not select a technology that falls within the “Containment” stage, but rather in the “Mainstream”, or, depending on the appetite of the project, the “Emerging” stage. Such a technology decision will influence in which stage the ultimate application falls into, as the technology used to develop it strongly influences the application’s lifecycle stage into the future.
Continuing with the 2004 Meta Group analysis, the second portfolio sunsetting challenge is the aged application’s data and potential future use of this data, from both legal and ongoing operation considerations. Simply put, while an application might be destined for the junk pile, the data often is reused and repurposed. Therefore, it could well have another five- to 10-year or longer window. Part of the application decommissioning is a plan to keep the data fresh and flexible, which points to mature archiving alternatives.
Application Lifecycle Management, when applied to a collection of applications, can be part of a Portfolio Assessment discipline. An Analysis by META Group analyst, Rich Evans, highlighted that although a portfolio assessment generally provides a thorough application inventory, the inventory is often devoid of the connection and the interapplication “hooks” that are typical of long-lived undocumented or poorly documented applications. This is often the starting and realisation point for the need for additional tools that can help uncover not just the “whats” of the application inventory but also the “hows”. Before the actual decommissioning and sunsetting, the all-too-often ad hoc connections and hooks have to be uncovered, and new connection solutions must be put in place.
ALM can be seen as part of an application portfolio management discipline, which takes a view on groupings of applications that can become outdated, marginal, or cost-prohibitive. Continued cost pressures and changing and expanding requirements, coupled with legacy integration challenges, make a compelling case for full-scale application portfolio analysis, making it a critical component of Enterprise Architecture. Although picking retirement candidates might prove easy, the actual “retirement”, which includes complicated extrication and often long-term data requirements, demands strong project plans, tools and technical skills. In most cases retirement requires extensive effort (at a cost) by the business to manage the change of migrating to a new target application.
I previously referred to Application Lifecycle Management (ALM) and that I will devote a few entreis to this topic. ALM falls solidly into the Application Architecture space, although Application can also mean Solution, which might include Infrastructure aspects that also require Lifecycle Management. In simple terms ALM means having a view of what to do with an application in the future when its life comes into question as a result of ageing, inability to scale (up or down), software that is no longer supported or business requirements no longer being fully met despite enhancement possibilities. There are also other factors impacting the life expectancy of an application.
A last practical word on Application Standards and its enforcement. How successful are organisations at applying Application Development Principles and Standards? In my experience, not always very successful. I would like to hear comments from others, but my feeling is the larger the IT community of an organisation, the more difficult it will be to govern development efforts. In the organisation where I work currently, the discipline of developing applications against a set of principles or standards, is seriously lacking. I also think that development should be governed from a central “authority” but in a collaborative fashion – not a policing approach.
What else can be said about application Standards? Anything that increases the quality, longevity and value of an application is worth upholding as a Standard or Principle against which it can be measured. Documentation is perhaps a Standard that needs to be met for any application, as it promotes understanding and maintainability into the future. An aspect that should be part of an application’s docmentation is a “roadmap” of its life cycle management. I intend spending more time on application lifecycle management (ALM) in the next few blogs.
What other checklist questions can be asked to evaluate the adherence of an application to Standards? Some quality attributes standardized under ISO/IEC 9126 include 6 different qualities: Functionality, Reliability, Usability, Efficiency, Maintainability and Portability. The quality attributes tend to be in opposition to each other. Greater efficiency often negatively affects portability and maintainability. Portability will often limit the functionality of an application. Improve one quality attribute and another quality attributes might suffer. The trick then to being a good software architect is to make the tradeoffs necessary to deliver the proper solution for the system.
Some more examples of application development principles are: Applications should be web-enabled (it’s functionality should be exposable on the Internet, even if via another existing web-enabled application). Applications should be designed to support 24×7 availability (should not depend heavily on batch processes or maintenance slots). Applications must be rules-driven or parameter-driven (rules should not be hard-coded and variables should be changeable via parameter settings). Users must have a common experience when using an application (user interfaces should be familiar and not require major adjustment on users side).
Some examples of application development principles are: Applications should be integrated using standard interoperability methods and protocols. Applications should be designed with Security in mind. Applications should be accessible via Application Programming Interfaces. Applications should be flexible in that changes can easily be made. Applications should be scalable, i.e. not be negatively impacted by changes in user numbers, transaction volume or data quantity. Applications should not dictate the channels or media used to operate with clients or third parties. Applications should support Data Warehousing, i.e. provide correct data and correct granularity of data for analysis. Applications should be able to expose its inner state, i.e. report abnormalities within itself or within its environment so that operators can take appropriate action.