Architected for Extensibility
Each tool offered in Team Foundation is highly customizable and automatable. Work item definitions, source control policies, build scripts, process templates, and programmability interfaces all enable customers to tailor their Team Foundation installation to their needs. In addition, at the core of Team Foundation is a set of mechanisms intended to enable outside tools to integrate into the Team Foundation environment as first-class citizens.

These shared Team Foundation integration services are depicted as blue boxes in Figure 2. The green boxes represent the elements a tool builder can provide to leverage the Team Foundation architecture. The orange boxes show the tooling included in Team Foundation.

Team Foundation's shared services include the following:

• The linking service enables tools to establish loosely coupled relationships ("links") between the data elements they hold. For example, in Team Foundation the relationship between a defect work item and the source code that was changed to fix the defect is held as this sort of link. To participate, a tool must implement methods that expose their data as Team Foundation "artifacts" and respond to queries against them. Using this facility a tool can participate in a relationship that it wasn't initially designed to recognize.
• To use security service supports Team Foundation-specific security groups, that can be used to collect Windows identities for permission assignment. These groups which are local to a Team Foundation Server, can be administered without the help of the IT department. When a new tool is introduced to Team Foundation, it should respect these groups by using the group security service API. The security service also provides authorization services. Tools that do not offer their own authorization mechanism have the option to use the security service to secure objects and establish permissions.
• The eventing service is a Web service-based pub/sub mechanism. As you'd expect, tools can raise events to the eventing service. Subscribers can register to receive notification when an event matches their subscription criteria. A notification recipient can either be a Web service or an e-mail address. When it's a Web service, the subscription includes the URL of a Web service to be called when a notification is to be delivered. When it's an e-mail address, a notification can be delivered through e-mail via an SMTP server.
• The classification service works in coordination with the linking service to allow classification of Team Foundation artifacts according to predefined taxonomies. This enables tools in which the artifacts do not share a common "natural" taxonomy to organize their data in such a way that cross-tool reporting along common axes is possible. For instance, if work items are naturally organized by team and tests are naturally organized by component, tests can additionally be organized by team to enable them to be reported alongside work items.
• When a new tool is introduced to Team Foundation, its artifact types, link types, event schemas, and service interfaces are registered via the registration service. Clients of the new tool discover its location by asking the registration service.

• For a consistent client experience, use VSIP to integrate the UI into the IDE. Alternatively, you can build a stand-alone .NET application that accesses the application tier using the intelligent proxy layer.
• Add creation of your tool's artifacts to the Team Project Creation Wizard (and, by implication, the process template that drives it).
• Make your tool and its data visible as nodes on the Visual Studio Team Explorer.
• Use the warehouse dynamic schema modification facilities to extend the warehouse with your tool's data. Then build a warehouse adapter to pull your tool's operational data into the warehouse structures.

Finally: More on Team Foundation...

• Figure 1
• Figure 2