Challenges of Designing Enterprise Systems

All software projects have been there. The rollout deadline is upon them, the developers are at odds with the architects about something, the testers are sitting around waiting, and programmers are adding features that don't map to requirements. And the customer is calling.

Building software these days is very difficult. Enterprise developers can no longer whip up a Microsoft Visual Basic executable and ship it with a Microsoft Office Access database on a floppy disk. Those days are gone. Today's enterprise-scale applications have many layers and services. These projects are held to a higher standard than projects from years ago. More and more customers, Chief Information Officers (CIOs), and other stakeholders are reading magazines and Weblogs. They know what they want, and an .EXE and .MDB combination isn't it.

Enterprise-scale software has significantly more moving pieces than they did 10 or 15 years ago. Web-based applications, XML, and Web services make systems easier and better-from the architect or user's point of view. The reach, interoperability, and extensibility benefits cannot be matched. The downside is that these systems aren't easy to build. All the services, stacks, versions, and application programming interfaces (APIs) known as "XML Web services" make it challenging for any size team to get the various elements plugged together.

Global Communication

Geographically-separated teams are a roadblock to successfully building and implementing enterprise-scale applications. In an environment that includes telecommuting and outsourcing, the odds are that the team has at least one member who is not doing project management, design, development, or testing on the local area network (LAN). When a project has team members working remotely, it's important for the code as well as the communication to flow through any firewalls.

Whether the team is distributed across the globe, country, city, or cubical farm, cross-group communication is never easy. Team members tend to live in their own silos, seeing the project through their own personal portal. Hopefully, e-mail, telephone, or instant messaging (IM) is being used for communication.

One drawback to all these various forms of communication is that they force developers to use a tool outside of Visual Studio, which is supposed to be their primary environment. Leaving Visual Studio and launching custom task-tracking and bug-tracking software when the project manager would like them to create a new Web service isn't an efficient use of their time. Rather than requiring them to embed Outlook or another e-mail-reading capability inside Visual Studio, Microsoft has developed VSTS, which integrates the messaging of requirements, tasks, accomplishments, and bugs right into the integrated development environment (IDE). And they don't have to leave Visual Studio to communicate with other team members about the project.

Multiple Tools

In many small or medium-sized software development team, there is an array of software products in use. The project managers use Microsoft Office Project and Microsoft Office Excel to track requirements, iterations, phases, milestones, and deliverables. The architects use Microsoft Office Visio or other third-party tools to diagram their data centers, networks, application services, and classes. The developers have and will continue to use Visual Studio to implement these services and classes. Developers and testers who want to test their software will also need third-party tools to perform unit tests, code coverage, static analysis, load and Web testing. If these testers are lucky, those testing utilities will plug into Visual Studio or at least run in managed code. The end result of using so many tools is a hard drive full of software from various manufacturers. Newly hired team members will need weeks of training to gain experience on all these niche applications.

Another potential weakness is a lack of guidance. Not that project managers or team leads are weak individuals. However, no single person can know it all. With a good search engine, an appetite for reading, and plenty of spare time, a person can come close. Unless such a rare person joins the project, they will need process guidance and best practices, preferably compiled by scores of domain experts. With this harness, we can go forth and write code, confident that we are proceeding according to best practices. Even then, any guidance implemented in the development process needs to be extensible.

The final problem with using multiple tools is also related to communication, but not between team members. The project itself needs to communicate with the project manager. This person needs to have his or her finger on the pulse of the project at all time. Today's managers have to rely on Project or Excel to provide them with such a detailed and accurate view. The status of the project presented by these tools, however, is only as accurate as the data recently typed into Project or Excel documents. Ideally, the project metrics should be relayed to the project manager in real time, without additional typing. Such metrics might include the following information: tasks still outstanding, satisfied tasks, code churn, efficiency, and bugs.

Solving The Problem

Some software development problems will never be solved. In many problematic situations, the customer, team, project, budget, and timeframe difficulties are beyond the help of any tool or methodology.

So what about the specific problems such as poor team communication, problems with working remotely, tools that don't integrate, lack of guidance, and lack of insight into the project's status. The best chance for success comes from planning, starting with a good design, following best practices, testing, and communicating effectively. Given that, wouldn't it be great if there was a tool that was available to guide us in accomplishing this? And wouldn't it be great if this tool plugged right into the development environment that we already use for 8 to18 hours a day? Such a tool does exist. It's called Visual Studio 2005 Team System.

Goals of Visual Studio 2005 Team System

Microsoft did something unique with Visual Studio 2005 Team System. It took a step back. Microsoft studied the ways that shops successfully, and sometimes unsuccessfully, developed software. Then it decided to build a product that would substantially increase the likelihood of project success and quality. With Visual Studio 2005 Team System, Microsoft will definitely change the way we think about Visual Studio. No longer is Visual Studio just a productive IDE for development. VSTS actually transforms it into a powerful tool that integrates the entire team with the entire solution across the entire software development life cycle. At its core, VSTS is essentially the same suite of tools that Microsoft uses internally to successfully plan, build, and deploy its software to users such as us. Microsoft knows that other software development teams, face the same challenges as it does.

Visual Studio 2005 Team System is designed to achieve four primary goals:

Be productive by reducing the complexity of delivering modern service-oriented solutions

Be integrated with all tools, and facilitate better team collaboration

Be capable by being robust, secure, and scalable, and by having the ability to work remotely

Be extensible by allowing processes to be customized

The first three goals are easily understood. The fourth goal means that third parties must be able to introduce VSTS add-ins. If the team happens to use an alternate methodology, designer, source-code control, or testing infrastructure, those tools can be integrated with Visual Studio 2005 Team System. The fourth goal also reflects Microsoft's ongoing support for its partners and developers, such as those in Visual Studio Integrator Program (VSIP) today. There are two types of partners that could be interested in extending VSTS: tool builders and system integrators. Tool builders plug in tools, whereas system integrators plug in methodology and frameworks.

So, is having a tool that dictates a methodology a good thing? Some developers would caution Microsoft to stay out of their way when they build software and to stick to simply providing the tools for building it. And that's exactly what Microsoft did with VSTS. VSTS is extensible at every angle. If the questions being asked by the tool aren't satisfactory or don't fit the team, they can be changed. If the source-code check-in policies are too restrictive or not restrictive enough, they can be changed. If the number or types of tasks the team is receiving is causing strife, they can be changed.

The Need for a Methodology

Having a methodology is important, no matter what it is. If the methodology is to write down all the tasks to do today, prioritize them, and then remove most of them from the list, at least a list exists. Even the term "methodology" is not very concrete. It simply means a concise and consistent approach to accomplishing something. There are well-known methodologies as well as obscure ones. VSTS itself is not a methodology. It is simply a tool that gives guidance and communicates which items need to be worked on, and it does so according to whatever methodology is happened to be used.

Microsoft Solution Framework

Microsoft Solution Framework (MSF) is a set of software development processes, principles, and proven practices that enable developers to achieve success in the software development life cycle (SDLC). MSF is rooted in well-known industry best practices. First introduced in 1995, MSF has aggregated 25 years of guidance from both internal and external sources.

Over the years, MSF has morphed to meet the changing needs of developers. MSF version 4.0, which ships with Visual Studio 2005, breaks down into two flavors, which are essentially two philosophies: MSF for Agile Software Development and MSF for CMMI Process Improvement. MSF for Agile Software Development will appeal to the "agilists" out there-that is, teams accustomed to more rapid, ready-for-change environments that are tightly coupled with the customer. MSF for CMMI Process Improvement will appeal to larger shops or larger projects that feature many reporting levels, projects in which long-range planning and communication are more important.

MSF for Agile Software Development

The MSF agile process is brand new. It is intended for smaller shops, with 5 to 20 members on the development team. Officially, the agile process model was created by a council known as the Agile Alliance.

Here are some tenants that the Agile Alliance agree on:

Individuals and interactions are more important than processes and tools.

Customer collaboration is more important than contracts.

Working software is more important than comprehensive documentation.

Responding to change is more important than following a plan.

MSF Agile is the default methodology in VSTS built for Visual Studio 2005 Team System, and the tight-coupling can be felt when used. The default artifacts-which include requirements, tasks, and bugs-are intuitive to developers who have used Visual Studio. This format makes the most sense when it is considered how many developers work in shops that use Visual Studio.

Quality and constant deliverables define an agile process. Gone are the days of a formal specification phase. With MSF Agile, Microsoft demonstrates its recognition that throwing hard-and-fast specifications and requirements over the wall to the developers often results in a failed development effort.

MSF for CMMI Process Improvement

CMMI stands for Capability Maturity Model Integration. Its goal is to provide a model for continuous process improvement. This should result in reduced software development-cycle times, improved ability to meet cost and schedule targets, and improved quality. It is a formal methodology managed by the Software Engineering Institute of Carnegie Mellon University.

One of the major advantages of using CMMI is that it is an evaluated standard by which can be compared to the ability to develop software against other firms. Specifically, the U.S. Department of Defense and other large software consumers often look at the CMMI rating achieved by their vendors in order to determine who should receive a development contract.

Visual Studio 2005 Team System implements CMMI for Process Improvement that is specific to software engineering. This is an excellent process to use on a project if the company is attempting to achieve a measured, baseline competency in software development. Far more status documents and reports must be completed in this model than in MSF Agile, but this more formal development process reduces risk on large software projects and provides a measurable baseline that can be used to achieve certifications in the various CMMI levels or ISO 9000/9001.

Visual Studio 2005 Team System Overview

VSTS is not an edition of Visual Studio, but rather a series of editions. VSTS is not really intended for solo professionals or consultants (but individuals can benefit from features within the individual role based products). It's valuable for teams that include project manager, architect, developer, and tester roles.

Visual Studio 2005 Team Edition for Software Architects

This edition is specifically designed for both the infrastructure and software architect roles. It includes visual designers, referred to as the distributed application designers or service-oriented architecture (SOA) designers. The architect can create diagrams to represent the logical datacenter, the application, and the deployment of the application. These designers follow the simple drag, drop, and connect heuristic that has been so popular with Visual Studio. More than just pretty drawings, the diagrams can be validated against well-known and custom constraints, and then turned into code with a quick click. With this slick presentation of diagrams, Microsoft is persisting the information in System Definition Model (SDM), which is an implementation of Dynamic Systems Initiative (DSI).

Visual Studio 2005 Team Edition for Software Developers

This is the edition for the developers and programmers on the team. This will probably be the most common of the VSTS editions. In addition to all the base Visual Studio 2005 professional features, developers will get the static code analyzer (akin to FxCop), unit testing (akin to NUnit), code coverage, and code profiler. Some of these features are shared with the Team Edition for Software Testers, as determining which role should be in charge of writing and running these source code tests is sometimes a gray area.

Visual Studio 2005 Team Edition for Testers

Whether a team member is a developer or a true tester, this edition will provide access to all the coverage, quality, and load-testing facilities needed for a successful project. Team Edition for Software Test includes load testing (akin to the Application Center Test), Unit Testing, Code Coverage, as well as test-case management tools for managing all the tests and running and monitoring them from a centralized area. The ability to plug in whatever manual tests is also supported in Team Edition for Software Testers. Again, some of these tests are shared with Team Edition for Software Developers.

Visual Studio 2005 Team Foundation Server

This edition of Visual Studio will provide the back-end database and Web services to enable the team to collaborate, by sharing work items and source code. If the team intend to run VSTS in full effect, they will need this product to connect all of the team members together. Team Foundation Server is more than just an "edition" of Visual Studio 2005 Team System. It's the engine behind the software development life cycle.

Team Foundation Server (TFS) includes the Team Explorer, a standalone client that offers an alternate way-besides using Visual Studio, Excel, and Project-of creating and managing work items. The Team Explorer is a standalone interface to Team Foundation Server, and it's lightweight and downloadable. It's intended for the "casual stakeholder": the person on the team who has to check in documentation, manage images for a Web project, etc.

Figure 1-1

Major Features within VSTS..

Roles Within Visual Studio 2005 Team System

A role doesn't necessarily mean a person. In many organizations, roles overlap. VSTS is flexible, because it has to be.

There are four VSTS roles - Project Manager, Architect, Developer and Tester. Of course there are many other roles. For example, the architect role can be broken into two sub-roles:

Software/Application Architect. Designs software and services

Infrastructure Architect. Designs network and infrastructure

Another role that can utilize VSTS includes the IT professional staff that will be tasked with deploying the finished product to the infrastructure.

Integration with Other Microsoft Products

Team System is composed of many moving parts. In the client-only editions, VSTS is Visual Studio 2005 with the appropriate add-ins. Team Foundation Server, is an entire architecture of services. Here is a list of some of the other products and how they integrate.

• SQL Server 2005 - Repository for all the team artifacts. Reporting Services for team reports.
• Windows SharePoint Portal Services - Team project portal.
• Visual Studio 2005 - Primary environment for all roles.
• Microsoft Project 2003 - Tool for project managers
• Microsoft Excel 2003 - Alternate tool for project managers
• Internet Explorer - Used to interact with the team project portals and view reporting services reports

In addition to these tools, Microsoft and its partners have announced other VSTS integrated tools and utilities. Microsoft is planning to include migration utilities for Microsoft Visual SourceSafe as well as Rational ClearCase source control software. Other partners have committed additional modeling tool support, requirements gathering support, and testing tools