The Tivoli Provisioning Manager development team has implemented usability testing in the Agile development process. By allowing customers to experience the product while in development, we are building a strong partnership with our customers to shape the solution that they need.
Here are the main points that we followed to be able to fit formal usability testing into the Agile schedule. By doing so, our team greatly improved the task flow and user interaction for the features tested.
1. We created a team
Our usability team is cross-functional, made up of people who have a "day job” but are also passionate about usability. Our team is composed of: a user interface (UI) developer, a tester, an Information Development (ID) representative, an Outside In Design (OID) representative, and a sponsoring manager.
2. We tested with 4-6 users
Our team conducts 5-6 usability sessions at the beginning of a sprint, each with a single user. We recruit users who are typical for our product: either external customers (existing or new, who are participants in the Early Adoption Program) or internal customers (Level 3 Support, Services, or Sales).
Testing with 5 users is sufficient to reveal 80 percent of the usability issues. This way we received enough feedback on the main flow, and we were able to figure out the top priority issues. For more information about testing with 5 users, see Jakob Nielsen’s article Why You Only Need to Test with 5 Users
3. We tested every sprint
Our team calls the first week of a sprint “the usability week.” Usability sessions are 1.5-2 hours long. Additional time is needed to set up the environment for the session, write the script, and summarize the results. We conduct moderated sessions, both in-person (in the Usability Lab) and remotely (using IBM LotusLive).
By keeping a consistent schedule, we know we are getting feedback from customers every sprint, so we can plan accordingly to fix the issues in a timely manner. After a few sprints of consistent usability testing, it becomes second nature for teams to validate their developed features with users, as shown below.
1. Obtain feedback within first week of sprint. Incorporate feedback into the design.
2. Incorporate usability feedback. Depending on the severity of the problems found, the feedback is applied to the development or the design work.
3. Validate solutions by a combination of internal testing and additional usability tests.
4. Repeat entire cycle every sprint.
In addition, we have other channels of communication with customers, like the EAP forum, where we keep the communication ongoing throughout the development cycle. Forum communication can cover additional topics of discussion, which are not necessarily covered by the usability sessions.
Continue with How Tivoli Provisioning Manager integrated usability testing in Agile - Part 2
, where I am sharing some other important points.
Modificado em por Rick Osowski
"Consolidation drives value." "Manage less and do more."
These initiatives, and many others like them, make sense from a financial standpoint, but can often lead to sleepless nights for operations managers once they realize the majority of their business, sometimes as much as 85%, is now run out of a single datacenter or a single platform. What happens when the system goes down? What happens when my datacenter loses connectivity? How quickly can I recover from an outage? Do I even need to recover, can I just roll-over to an active or passive backup?
Many mission critical core business applications, from larger vendors such as SAP and their ERP solutions, are run in datacenters much like this. However through high-availability and disaster recovery (HADR) capabilities provided by IBM, these datacenters can establish a failover policy to prevent even the slightest interruption to your company’s centralized business processes and financial systems.
IBM’s core HADR capabilities are provided by the Tivoli System Automation family of products, which we’ll specifically touch on System Automation for Multiplatforms here. Tivoli System Automation for Multiplatforms (SA MP) is a high availability clustering solution with advanced automation capabilities. It includes out-of-the-box resiliency policies for many IBM products delivering mission-critical capabilities to our customers. SA MP is the default, built-in HADR solution for IBM DB2 for Linux, Unix, and Windows available at no extra charge to DB2 LUW customers. The expansive capability of System Automation to provide a single point-of-view into your HADR capabilities and manage them, whether your fail-over datacenters are across the street or across the continent, provides immense value to our customers in managing their heterogeneous environments.
One such customer leveraging these out-of-the-box policies from SA MP for DB2, and by extension SAP, is China Ocean Shipping (Group) Company. For a detailed overview of the entire solution implemented by COSCO, including IBM POWER hardware capabilties, please follow the link below. In this post, I’ll briefly touch on how COSCO was able to leverage HADR capabilities to prevent major damage to the business during multiple datacenter outages. COSCO consolidated much of their business operations onto a single SAP ERP solution, but required the highest levels of service availability from this single system. By putting their SAP solution on top of DB2 and leveraging the HADR capabilities provided by SA MP, this customer was able to deploy a single SAP ERP solution across multiple datacenters worldwide, offering near real-time replication. These HADR capabilities and benefits were fully realized multiple times when the customer’s main datacenters experience prolonged outages, including the historic 2011 Tōhoku earthquake. They were able to seamlessly switch over from their datacenter in Tokyo to the off-site datacenter in Beijing, with virtually no service interruption.
Now the actual definition of “disaster recovery” may not always come to mind when you are planning your HADR strategies, but Tivoli System Automation, along with the many other IBM products it is embedded in are available to minimize your key HADR metrics, both recovery point objective (RPO) and recovery time objective (RTO). Many additional policies are available for other IBM and third-party products to monitor and ensure the availability for your business services. For more information on how you can be completely confident in your business’s HADR solution, check out the links below for a deeper dive into Tivoli System Automation for Multiplatforms.
For more information:
Tivoli System Automation for Multiplatforms
Tivoli System Automation for Multiplatforms SAP Success Stories
China Ocean Shipping (Group) Company surges into new markets with IBM and SAP
I wrote a new tool I call "db2tsacheck" to help avoid unwanted surprises due to configuration problems. Its sole purpose is to look for as many configuration problems as possible for TSAMP managed DB2 HADR or DB2 HA Shared Disk environments. Its a tool you can run on a periodic basis to validate all is well with your configuration.
To download the new version, please visit the following URL:
Although the first two releases provided good coverage of known configuration problems and checks for best practices, the flow and way the information was presented to the user was somewhat cumbersome. The new version overcomes this.
Here's a screenshot showing the new look and flow :
Here's what it looks like after hitting <enter> to have db2tsacheck attempt to fix all the problems found :
The output is much more compact and makes it more immediately obvious what is and is not a problem.
Problems found can be selectively fixed by entering the individual numbers associated with each problem listed, or all problems can be fixed by simply hitting <enter> after all the problems are listed.
Here's what the output of db2tsacheck looks like when its shows a clean bill of health (no problems) :
I just wanted to take a moment to spread the word about a new performance cookbook resource available from the IBM Service Management (ISM) Library. You can find it here:
This cookbook is based on the latest available version of TPM 7210 and combines all the most recent performance improvements available. Performance areas discussed in the cookbook include:
- Functional Overview
- Architectural Overview
- Performance Overview
- Deployment Infrastructure
- Runtime Performance Recommendations
- WebSphere Recommendations
- DBMS Server Recommendations
- DB2 Recommendations
- Oracle Recommendations
- TPAE Database connections
- CDS Recommendations
- DMS Recommendations
- Tuning Device Management Server variables
- Tuning Dynamic Content Delivery variables
- Depot sizing and placement
- Routine Maintenance Recommendations
- Database monitoring and improvement
- Deployment Engine Recommendations
- Reporting: Separate Database
- DE Clustering
Grab your copy today!
Modificado em por Isabell Sippli(IBM)
The Tivoli System Automation development team just released a whitepaper on SAP High Availability with Tivoli System Automation for Multiplatforms on AIX and Linux.
This paper describes an approach to creating a highly available SAP solution that covers all critial components. The IBM High Availability (HA) middleware solution (Tivoli System
Automation for Multiplatforms) provides this level of high availability.
High availability is a term used to describe systems that are continuously available that are up and running, performing the tasks they are dedicated to and are available to end users most
of the time.
• When failures occur, either caused by hardware or software, highly available systems must recover quickly.
• Even on peak loads and a loss of availablility, the systems must perform appropriately and process transactions within a reasonable amount of time.
A highly available SAP installation will meet a recovery time objectives of a few minutes.
Tivoli System Automation for Multiplatforms is a high availability cluster solution and automation product that provides several monitoring mechanisms to detect system failures and a set of rules to initiate the correct action without any user intervention. The set of rules is called a policy, this policy describes the relationships between applications or resources. This policy and the monitoring mechanisms provide System Automation for Multiplatforms with extensive up-to-date information about the system landscape so that it can restart the resource on the current node or move the whole application to another cluster node.
When the database of your SAP system is IBM DB2 for Linux, UNIX, and Windows the cluster manager System Automation for Multiplatforms is already included. DB2 for LUW itself can be protected using System Automation for Multiplatforms.
To protect the SAP Central Services, System Automation for Multiplatforms will be deployed on the cluster nodes and will be configured to monitor the SAP Central Services.
The paper will detail why companies need HA solutions for SAP, and introduce degrees of availability. Furthermore, it describes which components of an SAP system should be protected, and highlight the available IBM solutions for SAP high availability.
Jul 9 2014: For up-to-date information about this topic please consult our documentation.
If you're planning on asking IBM Support for help, more than likely there will be a minimum amount of detail they will need up front. The most obvious being details about your environment, such as platform/OS and product versions.
Now if you're needing the root cause for some event that has since pasted, then keep in mind that someone providing "remote" support will likely need historical log or trace data before they will be able to offer you anything significant.
For the Tivoli System Automation for Multiplaforms (TSAMP) product, we have a diagnostic data collection utility called "getsadata". This tool is a one stop, collect all, very exhaustive data collector that will provide TSAMP Support staff with everything they need to help you in 95% of cases. Of course we would still like an accurate problem description and a timeline, but often even the information collected by getsadata can be used by Support to work out what you need help with
So first let me point you to a link that explains how to use TSAMP's data collector (getsadata) :
The "getsadata" utility is bundled and installed with the TSAMP product within the "/usr/sbin/rsct/install/bin" directory. However, if you're many fixpacks behind the latest, or if you are not using the latest release level of TSAMP, then I would encourage you to download the latest version of getsadata, which can always be obtained via the above URL.
Here are some key things to remember:
1. Execute 'getsadata' with root authority. Running as any other user will likely result in data Support cannot use to help you.
2. Run getsadata on all nodes in the domain where possible, but only after first running it on the node hosting the "master" automation engine (IBM.RecoveryRM), identified by using either of the following commands (executed from any node):
- lssamctrl -V
- lssrc -ls IBM.RecoveryRM | grep -i master
3. It is important to collect data as soon as possible after a problem is observed in order to collect all log and trace data before data is lost (First In, First Out, fixed size trace files). This doesn't necessarily apply if your environment has trace spooling enabled.
4. It is equally important to run the utility before any manual (user) recovery efforts are attempted. This will ensure an accurate snapshot of the current states which can then be correlated with the logs and traces collected.
Let me leave you with one fact ... if you provide the tarballs created by running getsadata at the time you open the PMR, you will enable the TSAMP Support team to provide you with a root cause analysis much more quickly than if you wait for us to perform an initial contact to request the data
Should we or shouldn't we?
The typical question of the IT Manager when her/his datacenter automation software releases a new fixpack. This question stems from prior nightmares attempting to deploy fixes that were half-baked, poorly documented and delivered in haste.
I'm not an 'alpha' adopter but I certainly am an early adopter. The reasoning I take into deploying a new fix or new release fixpack is that I want the newest features, I want the bugs corrected - especially if there is a specific one that I'm subscribed to, and I want the latest enhancements in stability and serviceability. This will invariably cause some churn in my current calendar which may in turn force other projects to take a break, downtime will have to be scheduled, and service request tickets opened to alert dependent teams, but that short team pain will always bring a longer term gain.
Further reasons to keep up to date include the following:
- At the time of a new fixpack release the development teams and test teams all have the latest code changes fresh on their minds so if something new does come up in your environment then they are ready and best prepared to deliver a quick solution.
- By keeping up with the latest maintenance you ensure that you will always be in position to upgrade to the next refresh release or migrate to the next major release when the time comes. Falling behind here often results in contingency plans for data migration and lengthy delays spent analyzing if the old code can be 'jumped' to the new release.
- New releases will always include additional serviceability and stability improvements which will make your life as a system administrator much easier.
To emphasize this point we'll look at the upcoming TPM 7210-IFIX03 release due at the end of October 2012. In it we include a host of fixes and enhancements which improve the overall function and quality of the product. In particular a migration function to upgrade your WebSphere version 6.1 to version 7.0. This is really key for shops that need to keep their web-hosting environments running at the latest technology and security levels. The IFIX03 installation is redesigned as well, moving many of the prior manual steps into scripted pre- and post- installation sections. This is really great and should be a major step forward at alleviating many common maintenance headaches. While you're at it you should also take a moment to register for the upcoming training on this TPM721 IFIX03 release,
The tool appcmd can be used for testing policies of IBM Tivoli System Automation for Multiplatforms and policies of IBM Tivoli System Automation Application Manager Agentless Adapter. You can use it to instrument IBM.Application or IBM.RemoteApplication resources. appcmd simulates resources, allows to mimic failures and tracks the execution of commands which makes it a useful tool to develop and test policies.
We publish appcmd in version 4 for free in our IBM System Automation for Multiplatforms Wiki page here
New in version 4:
* appcmd is configured using the properties file /etc/opt/IBM/tsamp/sam/cfg/appcmd.properties
* The location where appcmd stores the state of the simultated resources can be configured
* The tool appcmd_policy_converter.pl which converts XML policies with real applications to appcmd
4. We tested “anything”
By testing items that were not complete, we received excellent feedback about the end-to-end customer scenarios and important features that were needed.
For example, we tested various designs to validate the general flow of a task from the business perspective. The feedback received from a design validation session helped us determine the right choices to provide. We also tested draft documentation to identify gaps and to validate the effectiveness of search results.
In addition to testing working code and documentation during usability sessions, our team conducts validation sessions for features that are in the design phase. In these sessions, we are gathering feedback from customers from the start. This way, they are helping to shape the product functions.
5. We involved everybody
For all usability sessions, in-person and remote, our team encourages stakeholders to participate in listen-only mode. This process helps the team understand the customer’s perspective because everybody can see where the users are confused and if they are struggling to complete their tasks.
6. We recorded feedback
During the sessions, we noted all comments: positive feedback, defects discovered, questions and comments from participants, and our own observations of usability issues. We also recorded all sessions for further analysis.
Our team uses a wiki to store the information that we collect for each sprint, session, and feature tested. We are using IBM Rational Team Concert (RTC) to open defects, to track how many defects have been fixed at any point in time (and for which feature), and to remind us what issues still need to be addressed.
7. We presented results
After each set of usability sessions, we write up a report to show the results of the usability sessions to the team. Then the usability team gets together with the scrum team to assess all issues. They start working on smaller changes right away. Items that require big changes are promoted to user stories and are evaluated by product owners for future sprints.
In the report, we summarize the ratings and overall task success, the positive feedback, and the number of defects opened. We also store this report in the wiki along with the notes from the sessions.
Conclusion: We improved usability
We proved that by implementing these tips, and by keeping the focus on responding to change in a timely manner, an Agile development team can integrate effective usability testing successfully.
We took the following actions based on usability issues identified in our testing:
- Simplified the UI panels and flow
- Made the terminology industry-friendly and consistent
- Redesigned a few features that were not aligned with customer goals
As a result, when we retested those items in future sessions, we improved the original ratings from 2-3 (difficult) to 5 (very easy).
The Open Program for IBM Tivoli System Automation started.
We are developing the next version of our products:
Tivoli System Automation Application Manager (SA AppMan)
Tivoli System Automation for Multiplatforms (SA MP)
In the Open Program, we are going to
show you selected features and improvements that we intend to include in
future releases of SA AppMan and SA MP. We are looking forward to
discuss these features and improvements with you and receive your
You have the chance to participate in this new development and
influence during the Open Program for IBM Tivoli System Automation
Have a look at the Open Program for IBM Tivoli System Automation Distributed and learn more.
The IBM Tivoli Provisioning Manager development team continues to enhance the next release (TPM v8.1) with new features and usability improvements which are targeted for future delivery. We have just announced the availability of our first BETA.
If you are an existing TPM customer or stakeholder and would like to participate in the BETA and provide feedback, please contact Kimberly Mungal (firstname.lastname@example.org) to join the TPM 8.1 Early Access Program.
Automation with Tivoli System Automation products family in virtual environments has been presented on the GSE Power-Systems conference in Munich on 21.11.2011.
Virtualization technologies play an important role in datacenters – they also provide the base for currently hot discussed “cloud” infrastructures.
There is a lot of focus on virtualization technologies for distributed server platforms like zVM, VMware, System p’s Hypervisor, SUN Solaris Zones, and others.
Of course, virtualization provides several benefits this presentation concentrated on the aspects of availability, high availability and disaster recover.
More than 80% of enterprises have adopted server virtualization, but only 20% of all server workload is on virtual machines
- Lack of confidence when it comes to high availability of virtual infrastructure
- Better management tools predict increase in adoption rate to 48% by 2011
Virtualized landscapes have the same high availability needs… - stay in business 24x7x365. It is required to consider that that failures causing service outages happen on hardware as well as on software stack. Planned outages have to be avoided which are caused whenever maintenance is required – if possible avoid service interruption. In a real disaster you have to recover your business on another site - it is required to be prepared for the worst. Virtual machines, applications and data have to be available on the failover DR site.
Key points which have been addressed in the presentation:
These topics are addressed in the given presentation - if you are interested to learn more pls. contact us.
- High Availability needs of business applications.
- A high level overview of virtualization technologies and their value for reducing out-times in planned scenearios
- Promises and limitation of virtualization technologies for true high availability
- High Availability clustering with SA has application knowledge, knows about relationships between applications and can react more intelligent in planned and unplanned outage scnearios
- System Automation Multiplatforms and SA Application Manager as management utilities for composite business applications including virtualization tolerations and exploitation.
- Cross-site Disaster Recovery Solutions with virtualized environments - control (virtual) systems, application stacks and replicated data with System Automation
- Explained in scnearios
We've created a "landing page" for a collection of support resources pertaining to the Tivoli System Automation for Multiplatforms (TSA MP) product. Think of it as the home page for your initial Support needs. Here's the direct URL :
This page is permanently linked off TSAMP's IBM Support Portal site, referred to as "Featured documents".
The landing page is actually divided into a collection of categories, each with their own home page. For example :
- Installation & Migration
- Configuration & Customization
- Operation & Maintenance
Each of these pages has a collection of technotes, whitepapers, presentations, and other useful links.
Lastly, the landing page has a set of quick links to the most common resources, such as the latest fixpacks, product guides, diagnostic data collection tool, and documents to help you with data collection strategies.
The Olympics always bring a strong sense of competition as countries vie for top honors, fueled with nationalism and pure athletic pride on the line. In every sport there is almost always one competitor out in front, willing to wear a target on her/his back, doing the extra training and utilizing his/her resources more effectively when the challenge arises. We admire their grace, strength and success. We desire their quality.
Without launching into a philosophical discussion on quality, I do want to tie the above premise into an IT model: The end result of doing the right work, spending the extra time to plan and design, and implementing the right features will be perceived as a high quality solution.
What I like the most about working at IBM is that we always set the bar high. Sometimes too high - we may set out to create something too vast, too complex with too many variables. While this may not provide us with the quickest or cheapest solution, over time and with the right ingredients, we generally come out with something ground breaking and pack-leading. Quarter after quarter, year after year, decades on, our products tend to shape the market. Other technologies that did not have the right 'stuff', even internal projects which were explored but do not pan out for public consumption, fall by the side and take silver and bronze. With IBM gold is in our blood - just like the Olympic competitor keen to achieve success, our focus on quality and exceeding customer expectations will always lead us to delivering the right products and solutions.
Setting the bar high means that sometimes you will fail to hit your mark, but just like the Olympic athlete on center stage for all the world to see, you would prefer to give it your best with the highest challenge on the line than to sit on the sideline and settle for less.
Caveat: You have TWS 9.x installed....What are the commands to stop and start TWS 9.x and WAS processes?
To stop/startTWS scheduler on master and ftas from command line (this stops batchman and mailman only, leaving the TWS WAS and TDWC JazzSM piecies up)
To shut down the TWS application all the way down on master and ftas from command line (this stops netman, mailman, writer and batchman processes but leaves the TWS WAS and TDWC JazzSM pieces up)
conman stop|conman start
conman shut | Startup
To stop TWS on master/bkm (this stops the TWS WAS piecie, and leaves batchman, mailman, writer, netman and TDWC JazzSM piece up)
Note: The stopWas.sh and startWas.sh kick off the conman "stopappserver;wait" and conman "startappserver;wait" commands respectively.
To stop/start TDWC on master/bkm (this stops the TWS JazzSM piecie, and leaves batchman, mailman, writer, netman and TWS WAS piece up)
...IBM/TWAUI/wastools/stopWAS.sh -direct -user -password
...IBM/TWAUI/wastools/startWAS.sh -direct -user -password
You also have stopmon for monitoring/event rules.
For this and other good tips and troubleshooting please visit the dWAnswers user forums at:
type in the core keywords TWS and now IWS ( IBM Workload Scheduler) to see other questions and answers