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.