Supporting Application Development

Methodologies or frameworks for the infrastructure to support Application Development (AD) is an interesting topic by itself, but one I’ve seldom seen mentioned or described, despite ITIL.  Even in companies that are following ITIL practices, the procedures are not often accompanied by feedback mechanisms to further improve things.

For example, do you trace incident or problem reports back to application change requests?  For major changes to application software, compare the post-implementation defect levels for different application groups.  Investigate the differences and consider ways to improve application development practices.

Many organizations believe that by designating support staff as level 1, 2 or 3, that they’ve established real procedures.  Other than “expected time to resolve” criteria, I’ve seldom heard of any real process analysis associated with those categories.  Nor have I heard of processes for a more organizationally flat structure.  A process needs to be more than assigning a severity level and contacting a software vendor.

What are your company’s infrastructure processes for supporting AD efforts?  What are the feedback mechanisms in those processes, such as periodic reviews?  If you were an infrastructure manager, how would you know how effective has been your support for AD, and where there may be perceived deficiencies?

Does each organization have a clear view of major plans and events for the next 3 to 6 months?  Does the AD area have any clues as to when systems is thinking of upgrading the version of the DBMS, or other essential software?

Hint to infrastructure:  if an AD team is pedal to the metal on delivering to the business, 2-3 weeks notice that you’re planning to upgrade to a new version of some key component is likely to be greeted by less than rabid enthusiasm.

Hint to the AD manager:  if you have not budgeted in time, resources and tooling (test scripts, etc.) for at least one version upgrade per year of the DBMS, and at least once every other year for the OS, some rude surprises may await you.

A tale of non-communication, with details altered out of sympathy:

Application development has a software product from a vendor, with much in-house enhancement.  In their published plans for the next quarter, AD had included an upgrade to a newer version of the product.  They knew that a newer version of the DBMS than currently used by the application would be needed for it, but since that newer version was already in use in-house by other applications, they were not concerned.

When the specific requirements became official requests to the infrastructure, the fun began.  The newer version of the DBMS required a newer version of the operating system than was currently used by that application.  And their servers were only marginal for the newer level of the OS; a hardware refresh was recommended.

The newer version of the OS not only brought along new run-time libraries, but used newer versions of compilers.  Even without any hardware refreshes, the regression testing alone for the DBMS and OS upgrades added significant time to the overall project.

Lesson learned:  frequent regular review of upcoming plans, including details as “DBMS version xxx needed.”  A review, meaning a meeting (even if virtual), with some communication, should be held.  Make sure the right people are talking to each other.