Posted on behalf of Martine Wedlake, Ph.D., Storage UI Architect, IBM Software Group
From talking with customers, we know that it's really important that you find what you need quickly and easily. The original navigation structure for IBM Tivoli Storage Productivity Center (TPC)
was built around a resource explorer model -- very much like a windows file explorer. This unfortunately, means you can have a ton of entries in the navigation that you'll need to hunt through to find anything.
For example, I took a look at one of our TPC deployments in the lab and started counting the number of clickable entries in the navigation -- I stopped counting once I got to 1000. Based on how far I got through, I'd say that there were about 1500 or so. I should point out, that this is not a particularly large deployment -- 25 storage systems, 7 servers, 4 hypervisors, 5 fabrics with 46 switches. You can expect a much larger set of entries on larger deployments.
So, we knew pretty early on that we needed to improve the navigation. To do that we switched from a resource explorer view to a by-category view. This allowed us to dramatically simplify the navigation to only 13 high-level categories and no more than two levels deep. No more hunting and pecking to find what you want!
We also made it possible to directly link to the things you want without having to go through the navigation at all. For example, for an SVC storage system's detail page you can link directly to the set of backend controllers in your environment consuming the storage. You don't need to go back out to the navigation menu and then try to track down the servers all over again. Here’s a picture:
The overall concept is whenever you see something interesting; you should be able to drill-down into it. In addition to the navigation of the product, we've spent considerable effort to make the content of the user interface easier and more intuitive; and to make it consistent with the work we had done previously on the Storwize V7000 and SAN Volume Controller user interfaces – if you've seen one of our GUIs, you'll be able to get up to speed quickly on any of the others.
To that end, we borrowed significantly from the Storwize V7000 GUI, for example: configurable tables, visual theme, embedded help system, charting and general icons. Here’s a screenshot of Storwize V7000 GUI to help show the similarities:
Beyond these cosmetic enhancements, we spent a lot of time working with our stakeholders to deliver the content in an intuitive and simplified way. Knowing what to put on the pages and how to simplify the pages involved a dramatic shift in our development process. But, before I move on to that, I really need to highlight the improvements made with reporting.
In this release, we've embraced the Tivoli Common Reporting
which includes IBM Cognos
. This is a huge step forward for improving your ability to view and create reports for TPC.
To start with, you will not need to know SQL or database schema to create reports -- the drag and drop interface allows you to simply incorporate the data columns you wish to show and Cognos already understands the relationships between the entities. For example, let's say you want to show the volumes connected to a given server. In Cognos, you simply add columns for the Server Name and the Storage Volume into the canvas. The tool already understands the relationships between these entities and will automatically join the data appropriately to show which volumes are mapped to which servers.
Of course, we also provide upwards of 45 or so reports out of the box for those who don't wish to create reports themselves. Another neat feature is that the reports included with TPC can be copied and edited by the built-in editor tool within Cognos, so you can take one of our reports and modify it to your liking. Here are some of the reports that are included with TPC:
Working with our customers is part of the most rewarding aspects of my work here at IBM. For this release of TPC
, we employed a radically different development model from what we have done in the past. We like many in the industry used to develop in a methodology called waterfall where requirements are captured and approved at the beginning of the project which leads to a phase of high-level and low-level designs, leading eventually to development, test and delivery to customer. For this release of TPC, we wanted to include customer input throughout the development cycle -- not just at the beginning when collecting requirements.
As such, we hosted 17 sessions with 34 customers, 7 business partners and 4 internal customers spread throughout the development cycle (held monthly). We also sent developers and GUI designers out into the field to talk directly with 7 customers. From these combined sessions, we captured 261 distinct requirements and were able to contain 188 of them within the first phase of development, with 47 being deferred into the second phase. That means that 72% of the requirements are already implemented in the first phase alone, and 90% of the requirements are expected to be implemented by the second phase. This is very impressive, as compared against traditional waterfall development.
The best part of an iterative, agile approach is that we are constantly evaluating the effectiveness of the solutions. We learn right away if something isn't quite hitting the mark, and have plenty of time to make changes to improve it.
As a quick plug, it is not too late to participate in our Early Adopter Program for the next phase of TPC. Please feel free to contact me directly (firstname.lastname@example.org
) if you would like to participate. We would love to work with you to make TPC even better.