TEAM Zarate Tarrani Notes From the Field

I must be bipolar because I have two passions: software engineering processes (a.k.a. applications delivery) and service level management.

Applications delivery is, for the most part, project-oriented, while service level management is operations-oriented. The practitioners who work within each of these domains often seem to live on different planets, and in some organizations, in different galaxies. However, there are many common touchpoints, including: quality, issue management and change control. Once an application has been released into production another touchpoint is maintenance, which is performed to either add enhancements or correct defects. Maintenance is an indication of quality. Too much maintenance may indicate poor development and QA practices on the application delivery side. However, it can also indicate responsiveness to user requests for enhancements (a good thing) or little control over requirements (a bad thing).

Internet development projects, especially those that are designed to acquire and/or retain customers in support of a B2C strategy, are unique in that most applications and systems are in a near-constant state of maintenance from the standpoint of features, adjusting to customer dynamics and other factors that marketing deems important. These systems pose challenges to traditional applications delivery methods because of their 24x7 nature and the immense pressures of business imperatives and competitive advantage that internal business applications normally don't impose.

With respect to initial systems development getting it right the first time is a common sense solution. That, of course, is easier said than done, but Six Sigma for Internet Application Development provides some excellent guidelines. Another article that addresses some of the challenges faced by teams that need to quickly develop and deploy applications is Rapid Application Development: Project Management Issues to Consider. QA and release management, regardless of the type of system, are two closely related areas that interface applications delivery and operations. Since requirements ultimately come from the business (end users - the reason we have jobs in the first place) to operations, which are then communicated to the applications delivery side, understanding how requirements relate to releases of enhancements and fixes is essential. A good starting point to gaining this understanding is An Examination of the Effects of Requirements Changes on Software Releases.

If you want to cast a pall over a social gathering of developers all you have to do is bring up the topic of software maintenance. This is probably the least sexy topic, aside from QA, for applications delivery folks. On the other hand, much of what is inflicted on end users is due to poor software maintenance practices. Did I say poor practices? In many cases they border on criminal - developers wildly patching production systems with no plan, no approval and no business ever touching a production system in the first place. Good practices, on the other hand, incorporate software configuration management, unit and integration testing, dependency analysis and other tasks that most developers hate. Also stirred into this mixture are regression testing, release management and change control. A good introduction to software maintenance is Tutorial on Software Maintenance, which is in PDF format. Another document that covers the basics and adds structure is Software Maintenance Process: A Seven-step approach in PowerPoint format. Once you have the basics down you'll probably want to examine some advanced techniques that tie maintenance to SQA, such as Applying Quantitative Methods to Software Maintenance and a related article titled Measurements to Manage Software Maintenance. If you're in the medical device industry then Architecture Level Prediction of Software Maintenance is essential reading because there is a world of difference between a business application and the software embedded in a dialysis machine.

As you dig into the software maintenance body of knowledge one name keeps popping up: George Stark. He has a lot of software maintenance material on his web site. One that I particularly like is Software Maintenance Management Strategies: Observations from the Field. He also wrote an interesting paper for MITRE titled Return on Investment from a Software Measurement Program. You can also download the paper in MS Word format.

MITRE has another document that you'll find useful: A Management Guide to Software Maintenance in COTS-Based Systems. COTS is Commercial Off The Shelf software, and, yes, there are maintenance strategies that can be applied to shrink-wrap software that comprises portions of business systems.

In a future entry I'll discuss in more detail my thoughts on configuration, change and release management; application acceptance processes and topics related to bridging the gap (chasm?) between applications delivery and operations.