At the IBM Information Management Information on Demand (IOD) conference in Las Vegas in October 2007, IBM made a number of major announcements, which included the christening of the DB2 Viper 2 beta as DB2 Version 9.5 (DB2 9.5), and the introduction of a new toolset for IBM data servers (DB2 for Linux, UNIX, and Windows, DB2 for i5/OS, DB2 for z/OS, and Informix IDS) called IBM Data Studio.

I’ve been writing a series on some of the features that were part of the DB2 Viper 2 beta program. Now that DB2 9.5 is generally available, I can share with you the vision and the ideology behind the new IBM Studio data toolset.

What the DB2 toolset looked like before DB2 9.5

Before the official announcement of the IBM Data Studio, IBM focused most of its attention (and coordination) on client-side deliverables around the run time. For example, IBM delivered cross-DB2-family APIs for Call Level Interface (CLI), Java Database Connectivity (JDBC), SQL Java (SQLJ), .NET, Perl, Ruby on Rails (RoR), PHP, Python, and more.

From a development perspective, there wasn’t a coordinated focus on the graphical user interface (GUI). In DB2 Universal Database (DB2 UDB) Version 8, IBM delivered the DB2 Developer Center, which evolved into the DB2 Developer’s Workbench in DB2 9, but the audience for this tool was focused somewhere between developers and application-focused database administrators (DBAs). From a development perspective, one challenge was that developers don’t just build stored procedures and user-defined functions (commonly called routines); they had to build Web sites using JavaServer Pages (JSP) and applications using a framework such as Java EE (formerly called J2EE), and so on. For Java developers, our toolset may have helped with 10% of their job, but they couldn’t do everything they wanted to do using a single IDE. Multiple tools imply a larger client-side footprint, not to mention the learning curve, all to manage the end-to-end life cycle of an application.

Our previous toolsets also appealed to application DBAs and provided them with a framework to build routines (if this wasn’t the Java developer’s responsibility), but there was no tooling to do schema evolution. For schema work, the application DBA had to turn to the Control Center; however, the Control Center was built on an entirely different set of technologies from the DB2 9 Developer Workbench. Depending on your job responsibilities, you may have had to use both tools.

Another group of users, operational DBAs, could use the Control Center or the command line processor (CLP). However, they likely wanted a lightweight infrastructure to manage the health of their data servers. For this task, these folks likely leveraged yet another set of tools, the Web-based Command Center and the Web-based Health Center.

In the end, your IT staff’s DB2 data server toolkit looked more like a bunch of separate tools than a tool suite:

The IBM data server toolset with the announcement of IBM Data Studio and beyond

The IBM Data Studio announcement is a major first step towards a realignment of the disparate DB2 tools into a single customizable toolset. And these tools extend beyond the DB2 mandate; they are tools for all IBM relational data servers. But it’s even more than that.

IBM Data Studio provides perspectives that appeal to any tasks within the entire application life cycle, which IBM defines as:

Different vendors likely define this process with different labels, but for the most part, every application rolled out by your IT department experiences these activities.

When you consider the breadth of the IBM software group (IBM SWG) portfolio, you can appreciate the kind of expertise IBM has to offer. From this broad-based perspective, IBM strategists identified the following roles (with a data server focus) that the IBM Data Studio toolset needed to serve. The IBM Data Studio addresses these roles directly with add-ins and perspectives.

These roles are shown below:

You can see that I tried to map the application life cycle outlined earlier in this article with the roles that IBM strategists identified. For example, the Design phase encompasses work across job responsibilities (in this case, the business analyst and the database architect). As you look more closely at this figure, you can see that the high-level aggregate role of DBA gets broken down into granular DBA-related roles.

To simplify things, I’ve shown you some roles, and some of what folks in these roles do in their day-to-day jobs below. The toolset is based on Eclipse – the architecture of the IDE where personnel work. Notice, however, that there is a Web component. The deployment and management of these solutions are moving toward Web-based interfaces (such as the Data Studio Administration Control), and thus the Data Studio toolset set has Eclipse-based and Web 2.0-based facets.

Notice in the previous figure that I’ve grouped application developers and database developers in the same quadrant. Of course, there is administration work to be done such as change management, schema evolution, and so on, which a DBA needs to do. There is also a whole category dedicated to governance. For example, if you’re a retailer, are you compliant with the Payment Credit Industry Data Security Standard (PCI DSS – or PCI, for short)?

Quite simply, no other vendor that I’m aware of has an integrated suite that addresses all of the roles illustrated in the previous figure. One of the primary advantages of such a toolset would be its ability to help the entire organization gather information at the design phase and use that information to make the development stages easier. It follows that during the development phase, the organization would gather even more information about the project, and then infuse that information (which builds on the information gathered at the design phase) to facilitate the deployment phase. With improved information, the deployment phase would naturally run more smoothly. The momentum builds, of course, and by the time you get to governance, many of the manual requirements to adhere to a standard are already fulfilled because they’ve been identified and built throughout the whole process with a toolset that is ubiquitous to all of its stakeholders.

By the governance phase, the framework would be able to take care of most of the things you need to know about the application life cycle; the toolset would know what it is you are trying to do and might even be able to automate some of it for you.