DB2 9.5 and IBM Data Studio – Things I Couldn’t Tell You Before DB2 9.5 Was Announced

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.

Paul Zikopoulos
Paul Zikopoulos
Paul C. Zikopoulos, BA, MBA is the Program Director for the DB2 Evangelist team at IBM. He is an award-winning writer and speaker with more than 14 years of experience with DB2. Paul has written more than 230 magazine articles and 11 books on DB2 including, Information on Demand: Introduction to DB2 9.5 New Features, DB2 9 Database Administration Certification Guide and Reference (6th Edition), DB2 9: New Features, Information on Demand: Introduction to DB2 9 New Features, Off to the Races with Apache Derby, DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Clusters) and a DB2 Certified Solutions Expert (BI and DBA). In his spare time, he enjoys all sorts of sporting activities, including running with his dog Chachi, avoiding punches in his MMA training, and trying to figure out the world according to Chloë - his daughter.

Latest Articles