The evolution of Microsoft’s solution for Application Lifecycle Management: Team Foundation Server – Part I

In the light of the upcoming official release of Visual Studio 2013 (November 13, 2013), I was planning to write a small blog post to have a quick look at how the product of today evolved over the years. My intention drove me eventually to come up with an elaborated article on this topic which I have splitted in different parts. Thanks to my fellow Visual Studio ALM MVP René van Osnabrugge for reviewing my text and for giving some tips to link it all together!

Part I is setting the scene and covers the introduction …

Software development is so much more than only writing technology specific code (.NET, Java, PHP, Mainframe, …). Applications are also becoming more complex due to numerous distributed services and the boundaries of an application are becoming less clear. Nearly all large enterprises struggle with communication, collaboration and cultural gaps between business users who drive the competitive need for software development, software teams who create the software, and the IT Operations team who manages application deployment and maintenance. IT departments are still often siloed internally with poor hand-offs between development teams and inconsistent approaches to core project life cycle phases and roles (architect, project manager, developer, database administrator, tester, configuration/release manager, …). This negatively affects design, quality, code management and the final deployment of software applications into a production environment.

On top of these issues, it’s quite interesting to see how different technology stacks are coming together in the bigger traditional enterprises. Product features or requirements are not only managed anymore for a specific technology stack but go way beyond specific implementation choices. A complete release/solution can easily consist of a customer facing website written in .NET which connects to Java Web Services for business transactions. The data used for processing could easily come from multiple other applications/sources (don’t forget the existence and importance of many Mainframe applications!). And I didn’t mention yet the different options that pop up if you want to offer a mobile solution on various devices and platforms. At a time of increasing costs, competitive pressure and greater complexity for business requirements, organizations require intuitive, accessible and integrated products. Most organizations have highly constrained resources and add outsourcing to the mix, which further drives the need for better prioritization and metrics for measuring IT success. In addition, regulatory compliance legislation is pushing organizations towards greater rigor with regards to application lifecycle management. On the other side of the spectrum we can identify the need for continuous delivery. Business expects IT to deliver new incremental features as fast as possible. Time-to-market has never been as important as now and can create an important competitive advantage. But let’s face it, many organizations are still far away from the continuous delivery dream. It’s not something which can be easily adopted over the week-end.

In this article I will write about the interesting evolution of Application Lifecycle Management (ALM) and the increased importance of (heterogeneous) software development processes. What I described above about continuous delivery should obviously be the ultimate goal to achieve, but it’s important to set out a realistic roadmap. Don’t run before you can walk and take your time to introduce important changes in your organization. A well-defined ALM strategy is essential to achieve the goals of the IT organization while closely aligning the direction of the business. The key for success is finding a balance between processes, tools and people.

In my next blog post, I will cover Part II to dive into the basics of Application Lifecycle Management and how Microsoft released the first version of Team System.

Part II: Diving into the basics of ALM and how did Microsoft start with an ALM solution?

Part III: Heterogeneous Software Development

Part IV: A fully integrated testing experience with TFS 2010

Part V: TFS 2012 and Continuous Value Delivery

Part VI: TFS 2013 and Visual Studio Online

 

Part VII: Conclusion