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
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
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
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.