Blogs

About this blog

Topics related to Application Performance Management, Cloud Technology, and SmartCloud Control Desk. Our goals are to describe, teach and relate, as well as provoke thought by approaching our topics from a variety of points of view.

This article will focus on the process of developing the
labs that will be available at Pulse in 2013. Specifically, I will discuss the
testing and care that goes into making sure the steps in each lab work are a
fair representation of how the product will be used in the real world and the
laser focus on every step being perfectly documented and as infallible as
possible.

As David Ross mentioned in his previous three blog posts,
preparation for Pulse in any year begins four to six months before the actual
date of the conference. He outlined the decisions behind the hosting,
platform
and laptop
preparation. Another component of the labs is much more basic: the product
and specific topic of the lab.

Each of the groups within IBM Tivoli Technical Enablement is
responsible for a particular inventory of products. In our everyday lives, we
work with the development and support groups for our product set to understand
the design and capabilities of each product. We are a peripheral step in the
release process and we are able to use and test the products during their
transition from early versions up to and including the released code and,
fortunately, to provide feedback when things don’t work as documented or simply
don’t seem logical. Many of us have firsthand experience working with
customers—whether in a training situation or on-site consulting—so we can
provide a unique perspective in many cases.

The goal of our being involved throughout the process is
primarily to develop the courseware and exercises that will be presented to
both internal and external customers. We are fortunate to have a process that
allows us to create the materials as the development progresses. We start with
the broad strokes, create the slides and notes based on what we are told in the
training sessions development presents to us and then we refine the materials
so that training is available at or near the time the product is released.

It’s a constant struggle to document how things are supposed
to work when we can’t always prove it until the final release. But that’s a
different story. Now, back to our regularly scheduled blog…..

Each year around the beginning of the third quarter, the
call goes out across IBM Tivoli for Pulse Lab topics. The labs are “built” by
various groups across the organization. My group is responsible for products in
the Cloud space such as IBM Service Delivery Manager (ISDM), Tivoli Service
Automation Manager (TSAM), and the IBM SmartCloud Provisioning suite of
products. Within each group, there are subgroups of subject matter experts who
have been working with the particular product for a period of time, either in
the capacity of an instructor (and probably prior to that a courseware
developer) or, as in the case of SmartCloud Provisioning in 2012, simply
courseware developers. Several of us have worked on the SmartCloud Provisioning
Self-Paced Virtual Classes since the middle of May of this year, so we are very
familiar with it and all the material is up to date—or at least it was until
about a week ago when SCP 2.1 FP1 was released. Speaking of updates, there is a new
release of Tivoli Service Automation Manager on the street as well.

So from October to December, we look at the materials we
have created for the existing version of the various products and see how much
they need to be updated to be as current as possible for Pulse….still three
months away.

Depending on how significant the changes are in the
products, this can range from trivial to monumental. We generally hope for
something in between the two. Subject matter experts on the various products
then look at the existing exercises which have been developed for classes and
come up with a plan to combine a number of those exercises into a single lab
experience of between 60 and 90 minutes.

Once we know what we want to demonstrate with the lab, the
existing labs are printed out, put in the order we want them to be performed
and someone creates the required environment (either virtual or physical) and
starts with the first exercise and runs through the entire set to make sure the
flow is correct and that the existing labs work with the new release of the
software, if necessary. This step feeds into the topic of “image creation” that
David Ross talked about. We have to define and produce an environment which
allows the lab to work as designed. In a classroom environment, we can
manipulate the environment between exercises to make things work more smoothly
for the students. That could mean executing scripts, running workflows or
perhaps even reverting to a particular snapshot. We don’t have that ability in
a Pulse Lab. Whatever we want the student to do has to work the first time and
every time if they follow the steps in the lab.

So we test. And we delete, combine, or add steps within the
exercise to ensure a logical and efficient flow. Then we revert and we test
again using the updated exercises. Then we go on to the next exercise and hope
that something we did in the previous exercises didn’t cause an unforeseen
issue. (And it probably did, because that’s just the way things work). That’s
the domino effect in all its glory.

So as much as we try to rework our existing intellectual
capital and exercises, it’s not as simple as cutting and pasting. That’s the first
step, but testing, poking, prodding and re-testing take up most of the time—and
that’s only the time of the person who is responsible for developing that
particular Pulse Lab. Once they think they have it down and working, the next
step in the process is for someone else to take the newly minted copy of the Lab
and go through it with a new set of eyes and a different perspective. In our
group, we like to have people who are less familiar with the product and its
characteristics perform this step although the person ends up doing it is
largely determined by availability. It just can’t be the person who developed
the lab.

While that Pulse Lab is being “independently” tested, the
developer starts another Pulse Lab, gets neck deep in it and hopes and prays
that the tester doesn’t find anything too significant. Keep in mind that the
person doing the testing on the first lab probably had his or her own lab(s) to
create as well. We will generally fix each other’s typos or formatting issues,
but anything more significant than that has to go back to the developer for
investigation, testing and possible rework which is shoe-horned in around the
time requirements of the other Pulse Lab being developed.

Once the labs are written, tested, tweaked, re-tested and
re-tweaked, they go to a team of professional editors to ensure they meet the
strictly defined IBM style for training material. They double check our
spelling, they ensure that we have used the full and correct product name on
the first reference; they add trade-mark and register symbols where necessary
and they make sure that our documents are using the proper “styles” for lack of
a better description within the publishing software we use. They put things in
bold and italic, as the style would dictate, they change lists to bullet format
if we didn’t do it correctly and they make sure that anything that refers to
screen output is in courier. And that’s just a very small part of the things
they check for and correct.

Then, alas, the developer gets it back again. He or she must
review the edits made by the professional editors and determine if the proposed
changes might cause any technical issues or issues of understanding on the part
of the person performing the lab or the lab proctor. Our publishing tool makes
accepting the editing changes as simple as clicking an icon that says “Accept All,”
but we still have to look at every change.

The lab is complete, tested, documented and ready. The
developer updates the table of contents, saves the various parts of the “book”
and converts it to a PDF file. The lab is matched up with a virtual image and
it’s completed sometime in late January or early February. The laptops are
being created and tested and duplicated, the files go to the printer and when
you get to Pulse and decide you want to run through a lab, it’s there for you.

You go in, sit down, a proctor gets you started and you do
your lab. You may make some notes on the printed document, but you may never
look at it again or put it in the trash can on the way out of the room. We hope
it is beneficial and everything works perfectly.

John Crawford is a Technical
Enablement Specialist with IBM Software Services for Tivoli, specializing in
Cloud technologies. He has been with IBM for 14 years in various positions and
received his Journalism degree from Trinity
University in San Antonio, Texas.
He can be reached at jmcrawfo@us.ibm.com.