When production applications are deployed and are scaling, requirements also keep evolving. Managing them properly...
requires understanding why they are happening in your organization, formulating and implementing a strategy to address them, and most importantly, getting over roadblocks and watching out for pitfalls while doing it.
Here are some reasons requirements keep evolving even as production applications are scaling:
- Identification of real requirements: Once production applications are deployed and used, many requirements missed during the gathering phase get identified during real usage. Actual and persistent usage by users and customers highlight key features missing and user interface enhancements needed for making the production application service business processes more completely. It may also be for providing a smoother and easier user experience.
- Rapid technology advances or business growth: Just when many companies get their online e-commerce together, they may need to integrate with social media like facebook, YouTube, Twitter and Google+. Just when they are finished with that, they may need mobile apps doing the same things or more. Virtualization, private and public clouds come along necessitating a second look at production applications and evaluating them for cost savings, better availability, reliability and disaster recovery. Rapid technology advances or business growth bring in new requirements even as you are deploying and scaling your production applications.
- Marketplace changes: Marketplace changes may mean changes in products and services sold or sales channels including online ones. These may bring on new sets of requirements for the production applications.
- Business model changes: Business models could change drastically, making parts of existing production applications obsolete while requiring new features or changes urgently.
- Legislative changes: Legislative changes in tax rates, the law, compliance or reporting requirements may necessitate new features.
- Mergers and Acquisitions: Mergers and acquisitions may require merging completely disparate production applications of the merged companies or at least build integration between them.
- Internal and external integrations: Once a core production application goes into use, integration with other internal systems like order management, customer support and accounting systems or external systems like third-party shipping or logistics services may bring on new requirements in applications or the way data is stored and used.
When requirements evolve even as production applications are scaling, here are some strategies that can help in managing it:
- Requirements prioritization, build and release planning: Agile methodologies naturally accommodate requirements re-prioritization at any time. The team is always working only on stories that go into the next build. When requirements evolve, they get re-prioritized as the stories for the next build, the one after that, and so on. Since the planning and execution horizon is short, evolving requirements can be accommodated easily as a matter of routine. Even when Agile methodologies are not used, instead of planning and executing one large release after a long duration, breaking them up into multiple releases evenly, can have the same effect. Evolving requirements can be folded into these multiple releases.
- Periodic requirements checkpoints and detailed review: Even if stakeholders have signed off on requirements at the beginning of the development effort, it pays to conduct a periodic review of requirements. Having the reasons requirements evolve (as enumerated in the previous section) in mind, a review with stakeholders can unearth changes that have happened since the last review. It allows the stakeholders and the development team to ask the question: Are we on the right track? What has changed since the last review? What are the older requirements that are obsolete and what new ones have popped up? What is the new set of requirements that we need to work on (till the next such review, of course)?
- Periodic architecture, design review and redesign efforts: Even if we have performed an exceptional job of architecting solutions and designing them, evolving requirements and re-prioritization slowly erode the fidelity of your production applications over a period of time. Just adding, modifying and deleting features periodically from your production application may weaken the underlying architecture. It is worthwhile to ask the question every few releases: Is our architecture still good? Is our design still appropriate?
- Periodic re-factoring for technology advances and rapid business growth: When production applications are in use and requirements are also evolving, technology also advances at the same time bringing in more precise, better ways of implementing the same or new features. Re-factoring existing production applications, especially for integrating new technology like social media or smart phone apps or for accommodating rapid growth, may become important. The platforms chosen may be inadequate in the face of rapid growth. Do we need to incorporate virtualization, private or public clouds? What kinds of re-factoring do we need to do before running these production applications using virtual machines or the cloud?
When production applications scale, that may not be the end of managing requirements gathering, but the beginning. Changes in the marketplace, business models and technology advances may make obsolete requirements already implemented in our production applications while bringing in new ones that were not anticipated before. These evolving requirements can be addressed effectively if we view requirements as part of constantly evolving production applications. Periodic review of production applications used, architecture and design and comparing them to the latest set of requirements helps make the right course corrections along the way. Evolving requirements need not derail production applications that are scaling.