A new model has been evolving in recent years that combines the advantages of the application service provider (ASP) and onsite operations model. Both of these paths are converging to a model known as the Development Service Provider (DSP). A DSP is an ASP environment for developers. Generally centered on a specific application or application area, so that work done in the DSP environment continues to build value for all organizations using the application.
For those organizations coming from the ASP world, the DSP provides process and infrastructure for customizing application instances, providing support for market differentiation through significantly personalized applications. For those coming from the customized package software world, the DSP provides process and infrastructure for making changes in a leveraged controlled environment. Customizations are done to a current release. Centralized code management can see all customization that has been done, so that new release functionality can be implemented in such a way that minimizes impact to those custom features. In fact, the very concept of a "release" is only necessary if software is actually bundled up and shipped in source form so that it can be modified out of the environment.
So what exactly is a DSP? An ASP is an operating environment for applications. A DSP is an operating environment for software development, centered on a specific set of applications. Although DSP environments will vary considerably in their level of sophistication, key components will include:
- Discovery tools - tools that accelerate a developer's learning process when assuming responsibility for either a custom system or highly modified system. These tools are invaluable when converting an application to a DSP environment.
- Unit development environment - tools and related support environment that are more focused on individual developer productivity and the unit construction process rather than run time performance and architecture. Tools like a good IDE for Java development, perhaps a cross-platform development environment for host applications.
- Source code abstraction/assembly - tools and related framework that support moving source code (rather than run time code) to a more component based (source code) architecture. Since custom code will generally be supported in this environment, mechanisms like this for tracking and directing the assembly process are critical.
- Asset management repository - tools and related knowledge base that catalogs and controls source code and meta model-based assets, and supports more widespread and controlled customization. Think of this as a bill of materials breakdown for an application. Well beyond the typical source code management library, with the ability to track changes for a particular customer.
- Collaboration environment - tools and related environment that facilitates collaboration among development staff, and access to development artifacts. For more routine processes, this is workflow for development.
- Systems/Integration/Regression/Performance test management - tools and related environment that facilitate organized, automated and repeatable testing.
- Integration engine - tools and related infrastructure that implement a very high performance enterprise >
Work invested in the application through a DSP environment can be available to all clients, unless the work is custom for one client, and is to remain custom. In many software package environments, each client personalizes the application to meet similar needs but in a different way. Over time, the customizations become so extensive that it is difficult to install a new release of the base software. Doing the customization in the DSP environment supports leveraging future software releases, while being able to personalize only those things that really need to be unique.
Concentrating all or most development for an application in a DSP builds leverage through scale. Since most customization for an application is done in one environment, an asset management function can see all changes that are being done to an application. For example, instead of 20 clients customizing an application to implement a new business solution individually, one implementation is done in the DSP for all 20 clients.
The DSP also supports differentiation for competitive advantage, and reduces the cost of that differentiation from a maintenance perspective. The asset management function can see all customizations maintained for each organization participating in the DSP. Future release planning can be done in such a way that minimizes impact to the customizations. This is not a substitute for a flexible application architecture. The DSP should complement a flexible architecture with a flexible construction process.