Microsoft’s initial release of VS Team will, as one expects from a first release, fall short of meeting vendors’ and customers’ needs. For one thing, the current design does not support the use of multiple VS Team Foundation servers. This will stymie contracted and outsourced projects as well as projects shared on a limited-trust basis with partners. Load distribution is also absent from this first release, a fact that raises questions about redundancy. Participation from remote locations will be managed through typical remote-access technology such as VPN and Windows Terminal Services.
Given these limitations, VS Team’s definition of “enterprise” may not match reality; however, VS Team could meet the needs of the great majority of midsize-to-large development projects, perhaps petering out before the scales tip to huge or gargantuan.
VS Team’s design toolset comprises three elements. Its class-modeling tool is a familiar component found in all commercial-grade IDEs. It maps the methods, encapsulated data, and interfaces used within self-contained project modules. It doesn’t lay out the cohesive solution that will eventually be deployed, which is good. Class modelers are sometimes misused for this broader purpose, a practice that inappropriately saddles developers with the design of the deployment architecture.
The second design tool in VS Team is the service-oriented application designer. Here, a typical project will come to life as a reconfigurable web of components such as .Net assemblies, COM/DCOM (Distributed COM) objects and Web services. The designer defines connections between components, with associated policies governing such details as the selection of interservice communications protocols and the enforcement of security. The interface paradigm is drag, drop, and connect; and the completed design persists in XML for consumption and modification by custom tools.
Finally, VS Team’s logical infrastructure designer reconciles service-oriented design with operational reality. This design interface maps out the deployment topology and identifies conflicts between it and the application’s architecture. For example, contrary to architectural assumptions, there may simply be no network route between one system and another. The basis for the architectural validation is the System Definition Model, which, as part of Microsoft’s Dynamic Systems Initiative, describes the structure of a group of distributed systems.
As elements of class design, SOA (service-oriented architecture), and topology change, the validation flags raised in the various designers change as well. The ideal would be to identify problems as maps are drawn. Instead, validation is performed as an independent step, as when saving a file. The first release of VS Team will also lack the ability to simulate a topology. Without this, the exploration of options for resolving design conflicts won’t be any more efficient than trading e-mails containing designs and advising, “Try this and get back to me.”
Staying in control
The best feature of VS Team Foundation may be its completely rewritten SCCS (source code control system). This replaces the weak Visual SourceSafe, which provided only basic
source-code control to small groups of developers. Microsoft estimates that VS Team Foundation will scale to handle as many as 500 developers per group.