At the VS 2005 rollout in San Francisco, the client piece of Team System will enter formal release, providing software professionals a tighter bundling of some life cycle tools. But the more important piece is the Server edition, which is not due out until Q1 2006. Fortunately there are all those community previews to give us an idea of what to expect.

Microsoft’s Visual Studio Team System was first announced back at the TechEd conference in early 2004. In Team System, Microsoft promised it would build the back end infrastructure enabling software tools for different parts of the lifecycle to plug in.

Visual Studio provided a common shell for development tools to plug in. By contrast, Visual Studio Team System provides the back end infrastructure so those tools not only hook into the developer shell, but also exchange the same metadata and artifacts across the life cycle.

Unifying the software life cycle has been a goal since the dark days of CASE (Computer-Aided Software Development) over 15 years ago. The concept got a shot in the arm when Rational retooled the idea during the era of client/server development, buying dozens of tools that covered activities form cradle to grave.

The weakness of Rational’s approach was that the tools retained their heritage as separate products, bundled in suites that in most cases were bound by loose interfaces. With Eclipse, Rational is only now in the midst of a definitive next generation stab.

Recently, Borland, Compuware, Serena, Telelogic, and MKS have embarked on similar routes.

With Team System, Microsoft threw down the gauntlet on developing a set of tools covering the software lifecycle based on a common engine. The difference between Microsoft and providers like Borland is that Microsoft is not pretending to supply all the tools itself.

Microsoft being Microsoft, it should have little problem drawing a critical mass third party ecosystem although there may be at best arms length tie-ins with best of breed leaders like Mercury in testing tools. It will be interesting to see the kind of support provided by the likes of Borland, Compuware, and Serena et al.

It’s a strategy that was later emulated on the Java side by the Eclipse Foundation, although under an open source context. Significantly, only now is Eclipse starting projects that will provide the same kind of life cycle integration that Team System aims to deliver.

With beta 3 of client and server out for community preview, there is little secret as to what Team System Server will look like (the server part became available in the past month). According to Notion Solutions consultant Chris Menegay, who has spent the last year conducting Team System courses, with beta 3 the product finally stabilized.

Under the hood will be a common engine that will store code artifacts and meta data. Not surprisingly Microsoft terms it a data warehouse rather than a repository, because that might dredge up memories of an ill-fated repository project with Texas Instruments roughly a decade ago. For the record, nobody succeeded at building software repositories because it was virtually impossible to develop products that could be all things to all people.

Using Team System, developers begin their day on a Team Explorer portal displaying a checklist of tasks and code that they check out from the data warehouse. Thanks to meta data, those work items link to other parts of the system, such as Microsoft Project, which is automatically updated when tasks are checked off by architects, developers, or testers.

And, with the bundling of lightweight testing tools, developers (or testers, if they are a separate group) do not have to leave the development shell to perform unit testing, test coverage analysis, code profiling, or other routine tasks.

At the front end of the life cycle, Team System also bundles modeling tools enabling you to perform the same kind of roundtrip code generation that TogetherSoft (now part of Borland) introduced to the Java world roughly five years ago. Because the code and model are kept part of the same artifact, neither ever falls out of sync.

Because we’ll be hearing a lot more about the topic soon, we caught up with Menegay to get a sneak peak at what to expect. The core architecture is pretty good, but this being version 1, there are some stupid mistakes, he noted.

Menegay likes the flexibility by which customers can tailor work items, which are the unit of activity tracked by Team System. The integration of test artifacts with source code control is effective, he noted. Similarly, project tracking is well synchronized with team member task lists.

While Menegay says that most of the integration is pretty slick, it falls down when it comes to user permissions. Because Team System for now lacks central administrative control over user access, there is no such thing as single sign-on for all the processes. They need to build a front end to manage permissions, he said.

Regardless of the merits of Microsoft’s platform, its development environments have set the agenda when it came to unifying tools spanning the life cycle. Significantly, the Eclipse Foundation has largely aped Microsoft in its strategy of developing a common front end for development tools.

Now with Team System, Microsoft is first off the mark for delivering a unified platform for the back end, so not only will tools be operated off a common interface, but they will hook into the same meta data engine. Only recently has Eclipse taken that bait. It will be interesting to see if Team System shows whether Microsoft is actually older and wiser than its TI repository days.