How well system development methodologies do (or do not) plan for the full service lifecycle - including retirement.

In my experience and opinion, most system development methodologies do not do a very good job of planning for the full lifecycle of a services including when the service will be deprecated or retired. The methodologies of the big consulting companies (IBM Global Services, PWC, etc.) are more focused on system development and typically don't give much attention to the system activities after initial operating capability (IOC) is developed. For example, Summit-D (by Coopers&Lybrand and PriceWaterhouseCoopers) was a very influential methodology in the 1990's (and may still be today) but sadly the last module is "Transition" where the new system developed is put into operation, reviewed and elements of the old system(s) are shutdown. If you want to really think about a succession of system solutions you have to occasionally imagine the process in reverse - i.e. what will happen when the system I am currently building is replaced/modified in the transition phase of some future system development effort. I worked for a big-name financial services company in the '90s that bought the rights to Summit-D so that they could tailor-it to do just that - the company founder was admirably obsessed with planning for the long-term. This situation is different but not much better in the OO/UML-style methodologies of the late 90's and past few years - such RUP. Since the UML provides for specific notation and idioms around systems, subsystems, interfaces, abstract classes, inheritance, etc. there is lots of design emphasis on distinguishing between "what" you want done and "how" you want it done - this implies some alternatives over time and would apply to the realization of service interfaces. This has gotten even more emphasis with the Model-Driven Architecture (MDA) in the platform-independent model (PIM) and the platform-specific model (PSM). All good by sadly, in my observations, while the technical support for designing service evolution is there - it isn't practiced that often. The Rational Unified Process for example as a methodology shares with its predecessors (like Summit-D) an emphasis on developing a solution and getting the thing installed, delivered or to general/retail availability. The RUP does include the idea of generations (larger scale aggregates of the phases/interations in the "humpback" chart that is so familiar) but this doesn't get much emphasis in the documentation and even less in practice. The foundation work for RUP (Unified Process and Objectory) was better in this regard. UP/Objectory placed more emphasis on Use-Case realization - the idea that a use of the system could be realized by more than one solution. UP/Objectory also placed more emphasis on Use-Cases for managing the system plan over a long period of time. A fair criticism of RUP (and similar approaches) is that they have been overly seduced by classes - because you can generate code for them and there is money in tools for that. The gossip in the industry is that this is one of the reasons Ivar left IBM/Rational - too much emphasis on class/code tools and not enough on evolving a good system architecture/solution over time. While the Dept. of Defense methodologies have generally been a poor fit for most of the projects I've worked on, you can find some good references on planning for the succession of services, service retirement, etc. is in some of the Dept. of Defense materials. The vocabulary is "retirement", "end-of-service" or "disposal" in these materials and may include material that doesn't apply to software systems (e.g. "...environmental impact of any hazardous materials remaining on-site." - though this is getting more attention in IT systems as well now) but with a little interpretation there is lots of good stuff here. This is the doctrine though - I suspect in practice many DoD projects are as focused as their private sector counter-parts to get systems built and turned on - full lifecycle planning may get neglected in the process. This would probably make a good research project and could be applied as a set of tailorings for some of the "big-name" methodologies (RUP, CATALYST, etc.)

No comments: