Database Development Teams: The Great Divide

Software-application development involves more people than just the developers; the work of architects, testers, project managers, and—if the application stores data—DBAs affects the application’s success. If we want to advance the industry, streamline application development, and build higher quality applications, then it’s more important than ever that the different teams involved in application development work together in a coordinated and managed way. The growth of the software development lifecycle (SDLC) market brings a promise of tools that will help unify everyone within the software life cycle, not just through the application’s development, but also through the deployment, management, and eventual round tripping of requirements to the next version of that application. SDLC–tool suites typically contain products that help gather requirements, design and develop applications, and test the application; the tool suite can also include a platform that lets project team members work together. Microsoft entered the SDLC market last year with Visual Studio 2005 Team System.

Despite the SDLC industry’s focus on managing the entire application-development life cycle, most of the popular software-development tools and methodologies, such as the Software Engineering Institute’s Capability Maturity Model Integration approach or an Agile development methodology such as Scrum, fail to integrate the database into the life cycle. And, worse than that, most of these tools don’t even acknowledge a role in the life cycle for someone who works in or around the database.

Walls of Obstruction

A long history of Chinese walls has separated traditional development teams (who some regard as cowboys who just throw together software without any fore- or after-thought) from the DBA community members (who some regard as inflexible nine-to-five-ers who implement and maintain those systems). The walls between these two camps often hinder development and therefore decrease the quality of the final software. Some DBAs’ inflexibility in working with the developer community has led to “developer worst practices” (e.g., pass-through SQL) that have caused SQL–injection vulnerabilities, failure to optimize presented queries, and poor database performance. On the developer side of the wall, the general lack of database-system knowledge has led to terrible decisions regarding elements such as application design. For example, once I attended a meeting of architects who were working on a new system; in the meeting, the entire group agreed that no stored procedures should be used because all business logic should reside in the middle tier.

Reaching Common Ground

If we’re going to successfully build high-quality software, our teams must understand each other’s problems and actively work together to reach the correct resolutions. I introduced Microsoft’s new Visual Studio Team System product,Visual Studio Team Edition for Database Professionals (Team Data), in the Web-exclusive article, “The Power to Control Change” (http://www.sqlmag.com, InstantDoc ID 50303). In the article, I mention that this product is poised to fundamentally change the way we all work with databases throughout the development life cycle and bring together all those involved in building the applications regardless of their allegiances to application or data. With Team Data, Microsoft is trying to help bridge the gap between the application and data worlds by addressing the entire database-development process. In addition, Team Data introduces the concept of the Database Development Lifecycle, which integrates database professionals into the software life cycle and makes them first-class citizens who the rest of the development team sees as valued members.

Although I haven’t looked at Team Data features in this column, I have touched on one of the most important features of this new release, the “process.” The process isn’t built using code and doesn’t have a pretty graphical interface, but it’s a key tool in building better software faster. Team Data can help break down the walls, but the tool suite can’t entirely fix the problem without a concerted effort to integrate all team members into the software-development process. If some of the problems I describe in this column sound like those of your company, it’s time to take a long, hard look at what you’re doing. If they don’t, congratulations! You’re on the path to building great systems (and going home earlier). Next month, I’ll start diving into some Team Data features and explain how they work.