Software engineering methodologies are evolving to address the complexity and probable dynamism of the business requirements. One of the methodologies –Agile - helps teams respond to the unpredictability of building software through incremental, iterative work cadences, also known as sprints. In an agile paradigm, every aspect of development — requirements, design, etc. is continually revisited throughout the lifecycle creating high visibility of the progress to all the stakeholders in the application development process. Traditional methodology involves creating the requirements for the complete application and then the development team almost goes into hibernation to develop the application and more often than not ends up giving unpleasant surprises to business. Nobody inclusive of the SMEs sometimes is able to visualize the final application state; moreover the demands are changing and creating chaos in the development process. AGILE comes to rescue as all the stakeholders are involved in the application development process beginning with the first iteration. Instead of building what developer understands or rather interprets and showing end product collectively, we prefer to show application in pieces take feedback and improve in an iterative manner. It becomes a continuous improvement process. AGILE gives a good visibility on development process, application feature sets and planning process to all stakeholders.
There are a few challenges in implementing AGILE methodology in general. Traditionally, there are certain challenges in web application development using agile methodology majorly in infrastructure setup and release management process.
Environment Setup
Firstly, the key challenge - being able to make the application accessible from anywhere to all the non-co-located stakeholders. Further the deployment environment created has a few issues. To make an intermediate application (sprint) available over the internet to a disparate set of people to get their feedback, we need to setup an independent infrastructure which is a DMZ kind of setup. This infrastructure is managed by an independent IT team which is mostly isolated from the development team. The process of procurement, provisioning and hardening this infrastructure consumes a good amount of resources in terms of time, IT management, people and hardware cost. Since, it is a time consuming process it might cause iterative slippages in the overall development cycle. In Windows Azure world the procurement, provisioning and hardening is outsourced, we setup an application in minutes and it is ready to utilize immediately. It helps to avoid the delay in first feedback cycle avoiding any overall slippages.
Release Management
Second aspect is that the Sprints (Build for set of features) are required to be deployed regularly and this needs to be done quickly to get the real benefits of agile process; release management becomes very crucial. In a traditional approach of release management, the deployment is done by an IT team from within their location. Deployment process gets delayed in terms of educating the IT team for application specific deployment and configurations. There are high chances of oversight and issues in versions of the application build provided to the IT team for deployment. How many times have you encountered the weird issue of something working at the developers end but not so at the deployment team’s end? Generally, the issues arise because of wrong configuration and deployment contributes large chunk in overall life cycle. These issues employ a good amount of time to fix them, which is completely unnecessary. To address these issues in traditional approach, we need stringent deployment process, documentation, test deployment, verification etc. The stringent process consumes time and resources causing a very hideous shift in focus. The bottom line; to be Agile is to be able to release quickly, take feedback, implement and go back in release. Azure deployment process is pretty much easier and doesn’t depend on the source location of the deployment. Very important point is; it can also be straight away done by the development team itself so chances of configuration and wrong versions are reduced. It gives another practical benefit of fixing the issues in deployment quickly by the developers and which reduces an unnecessary layer of issues; communication; providing unnecessary fixes to an independent IT team. Practically the right people to solve the application issues in application deployment are Developers and if they have an easy and quick access to deployment then it quickens the process. Azure also brings location independence for deployment. Deployment can be done from anywhere and anytime.
There are challenges in traditional approach to setup an internet enabled application deployment infrastructure. The next thing that comes to my mind is the non-reusability. Let me elucidate its essential to setup a domain name for users to be able to reach to the intermediate application over the internet. Huge Investments are made in making this infrastructure secured enough to address vulnerabilities. (Generally) The sad part being these resources are not going to be used in the final production environment considering the production environment is physically a totally different data center. This makes the investment a complete waste. You must have already gauged the benefit of getting on to Azure in this aspect as well. Let’s summarize agile implementation with and without Azure.
Measures
| Without Azure
| With Azure
|
Procure or allocate Infrastructure for intermediate application
| Time consuming Process
| Quick and Easy
|
Hardening the Infrastructure
| Time consuming and need to done carefully
| Quick and Easy
|
Release Management
| Development and IT team is involved. Time consuming and error prone
| Less time consuming and can be done by the developers hence less error prone
|
Application Fixes and upgrades
| Turnaround time is high due to involvement of an isolated team
| Less turnaround time
|
Cost benefits
| Less. Infrastructure cost for intermediate application and reusability is very less
| Due to elastic nature, charged only for usage
|
Security
| Need to address locally. Expensive in terms of resources and time
| Offloaded to Azure |
To share something from my first hand experience with a web application (ASP.Net) development where customer insisted we use Agile Methodology SCRUM. We used to add a small set of features and functionalities and seek the customer’s feedback on changes, requirements and planning for the next build. Most of the heart burn and the issues in implementing this model rose from the infrastructure and deployment related roadblocks. We spent more time resolving these peripheral bottlenecks rather than getting the detailed feedback for the build. Since, I have started exploring Azure I realized how easy, convenient and inexpensive it would be to develop the same web application with the same methodology but on AZURE.
To diagrammatically represent what I feel about AGILE with and without Azure.
To focus on the application development process rather than the secondary activities of infrastructure setup, release management, Azure brings lot of advantages to the table. Azure helps being more agile in the dynamic business and application development process. Hope to see software engineering processes tweaked and suited to derive the most out of such technology evolutions.
