System i SCM: A Commodity?

Introduction

All software vendors have naturally learned to tout their product’s unique selling points, i.e. those features of their design that they feel exist only in their product and make them stand apart (and hopefully, above) the competition. The question before us now is this: does the prospect really care? Has SCM on the iSeries matured to the point of being viewed as a commodity? What can prospective software consumers do to make sure that the solution that they buy and the vendor that they choose, are the best available for their needs? What can software vendors do to help them come to that decision quickly, honestly (and more often!)?

Software as a Commodity

Before I share my ideas on the questions above, I need to share an opinion I've been forming over the last ten years in this business: software solutions in a very mature market become commodities.

The term commodity generally refers to any product that is essentially undifferentiated. This means that there is no difference in the product from vendor to vendor. Milk is generally said to be a commodity. As long as the product meets the provincial health guidelines for milk, there is really no difference between producers or sellers.

Why do people buy software? It’s quite simple actually. They have a problem and they are hoping that your software can make this problem go away. They want it to go away quickly. They want it to go away forever. They want it to go away and not cause new problems they didn’t have before. Finally, they want it to go away at a price they can justify up the line to their superiors.

If I were a prospect today, looking for a SCM solution, I wonder how much concern I’d truly have for the dozen upon dozen of features and functions of any one product. I’d even go so far as to say most don’t care about what the vendor touts as their product’s USP’s. Even more, I’m convinced that one vendor’s negative talk about another vendor is not only unbelievable, but it is completely counter-productive.

Those thoughts probably come as a shock to some of today’s SCM vendors, many of whom have been in the market for 10, 15 and 20 years. Vendors who have “always done it this way”. What worked well in a fast-paced emerging marketplace has lost much of its effectiveness in the mature "commodity" marketplace.

Selling the Swiss Army Knife

I believe that SCM solutions, especially on the iSeries, have reached the maturation-saturation point. This is the point where two things have happened.

First, the vendors have been actively developing their products for ten years (or more) now. The products are packed with feature and function.

Secondly, as a direct result, the products are beginning to suffer under their own weight. This can have a kick-back effect of making the product look complex and hard to use. It can also make the product harder to teach and harder to support. Sales Reps and Sales Engineers, especially new ones to the product, have a harder time knowing how to sell the tool. Marketing begins to struggle to summarize and differentiate their product. They are all trying to sell a “Swiss army knife” that has 150 tools in it! Where do you start?

We All Look the Same

The other phenomenon in play here is software homogenization. During their development years, the vendors “ping-ponged” off each other. Vendor A develops Feature A and wins sales against Vendor B. Vendor B, not enjoying this phenomenon, sees Feature A and raises with Feature B. After 15 years of fierce competition, there few significant features or functions that one vendor has that the others do not have.

How does this Effect the Prospect?

This creates an interesting effect in the customer’s product evaluation process. Venerable IT managers naturally fall back to comfortable evaluation tools that have worked well for them for years. These tools were all originally designed to ferret out differences, weaknesses and compliance with the customer's needs. Because of the points made above, they've lost most of the effectiveness they once held. For example:

• Request for Proposal. The RFP contains page after page after page of desired feature and function. Chances are quite good that the RFP comes back from the vendor with 98% of the features met, with the other 2% “under consideration”.
• Vendor Web Site. Wading through a slough of glossies and white papers and customer testimonials. All very positive. All extremely high level.
• “Independent” Industry Analyst Reviews. Many of these are sponsored by the vendor. Those not so sponsored are, by necessity, limited in content and scope, and performed by journalists with unknown technical expertise.
• Discussions with Vendor Sales Reps. Sales Reps trained in "Solution Selling" will focus on the customer's primary needs. “Give me your top five problems”.
• Product Demonstrations. Dutiful Sales Engineers then demonstrate those top five problems. They show their product at “the 30,000 foot level” in the interest of expediency and the ever-crucial “ease of use”.
  

After proceeding through all of the above with one vendor, the prospect proceeds on to the next vendor. Amazingly, the next vendor’s solution can also meet all of their primary needs and also looks very easy to use.

It’s All about Trust

What, then, finally tips the scales for the prospect? I can sum it up in just one word: trust.

Gary Elfring, author of the book Selling Software, has this to say about the topic:

“If you want to sell someone a piece of software you have to over-come all those negative feelings they already have about software. Your potential customer needs to trust you. How do you get them to do this? You have to learn to see the world through your customer's eyes. This is not as easy to do as it sounds, since you are more than likely not a programmer or someone who uses software on a daily basis. And, the fact is, you just don't think the same way your potential customers do.”

Making the Sale

There are five main areas that will factor into a successful sale:

• Evaluating the Software
• Evaluating the Sales Team
• Evaluating the Company
• Evaluating the Future of the Product
• Evaluating the Service After the Sale

Evaluating the Software

How the customers actually evaluate software is very different that how we, as the programmers and Sales Engineers, think prospects should evaluate our software! They want a solution to their problem that can be installed and learned quickly and not cause more problems in the process.

“Don’t sell the steak, sell the sizzle”, says sales guru Elmer Wheeler. What is the “sizzle”? It is that specific portion of the product that gets the prospect salivating. The trick here, of course, is finding that specific portion! Thomas Sant, another modern-day sales guru, adds to this concept: “A good sizzle should answer the one question every customer has rattling around in their head when they are listening to our sales presentation or reading our proposal: So what?”

Evaluating the Sales Team

How well do they understand my business? My needs? My staff? How responsive have they been to my requests? Do they act like professionals interested in developing a long-term relationship with me, or will they just care about me until I send in the check?

Evaluating the Company

Has it been around for a while? Will it continue to be around for a while? What is its reputation in the industry? Does it lead? Is it recognized as a trusted source of information? Are its key leaders known and respected in the marketplace as industry experts? What do its current customers say they like about the company?

Evaluating R&D

Yes, the iSeries software is very mature, but it’s not dead. Besides, software can always be improved. What is the vendor doing to maintain the health and usability of its product? Even more importantly, what is the vendor doing to reach into other areas beyond their current products, and how important are/will those developments be to my organization?

Evaluating Service after the Sale

This is probably the hardest of all to evaluate until you’ve actually become a customer! However, prospects will need a strong sense that the company is investing appropriately in services after the sale, both for a fee and as part of the (significant) maintenance charges. When I call Tech Support, does someone answer in a few rings or do I have to leave a message? If I leave a message, how long until I get called back? If I get through, does the person on the end understand my problem and its solution? What about the Professional Services department? Are they truly “professional”? When they arrive on location, will they be able to deliver the agreed-upon services on time and accurately?

Conclusion

Buying and selling commodity software is not impossible, it is just different. I believe that prospects that follow these new methods will be much more satisfied with their final choice. Likewise, vendors following these new methods will undoubtedly be more successful and profitable.

Software Configuration Management : Three Key Ingredients for Your Sanity

Introduction

From the very first days of programming, IT Managers have been concerned about managing the changes to mission-critical applications that drive their business. Now more than ever, IT teams are challenged to meet not only their own needs, but the rapidly evolving needs of the entire corporation they serve. Implementing a more formal process could mean the difference between corporate success and corporate failure over the next five years.

Yes! It is that important!

Quality software delivered on time and that works as requested is no longer an occasional miracle. It is now an absolute expectation that IT departments must meet every time. Savvy IT manager are increasingly adopting best-practices to improve their core business functions. They are also looking for tools to help them attain these goals without over-burdening their already maxed-out staff.

Today, we have matured these concerns into a formal discipline that many call Software Configuration Management or SCM for short. If you did an internet search of SCM, you would doubtless find dozens of web sites, white papers, even entire books on the topic. (See the side bar for a collection of some of my links).

The goal of this paper is much simpler: to introduce you to the basic concepts, to get you thinking about the ideals, and perhaps even to motivate you to investigate this powerful discipline further.

The Three Tenets of SCM

In its simplest form, SCM can be broken down into three core components: Process, Documentation and Security. The remainder of this paper will focus on two key aspects of each of those components. First of all, what are the attributes of this component? What makes it so important, so beneficial? Secondly, if you are looking for a software-based solution to help you meet these standards, what features and functions should you be looking for?

Process

From the cradle to the grave, human beings thrive on consistency. Any parent of a toddler will tell you how important it is to maintain a consistent routine. As adults, it is well-documented that our stress levels soar when our daily routines are significantly altered. Why is it, then, that we IT professionals endure so much chaos in our daily lives? How can we stop the madness and regain our sanity? The only way to break out of this chaotic, never-ending fire fighting mode is to first define, and then fully embrace, a formal process.

If you examine today’s most popular best-practice models such as CMMI, COBIT, and ITIL, you will find good process management at the heart each of them. Many industry regulations such as SOX and BASEL are based on one or more of these standards. For many companies, these laws suddenly elevate the need for a well-defined formal process from “would be nice if we had it” to “somebody goes to jail if we don’t have it”.

Why is a formal process so vital? Consistency and productivity.

When you create a process, you are outlining the precise steps for the successful completion of any business function. Taking the “road less traveled” made have made all the difference for poet Robert Frost, but it will most certainly mean disaster for you. Whether you are requisitioning a new PC or rolling out the next release of your mission-critical application, you have created a precise path getting you from start to finish.

Benefits of a Formal Process

• Increased Productivity. By making the process the same upon each iteration, you make it repeatable. By making it repeatable, people inherently become more efficient in navigating each step. Additionally, any new-comers to the process become productive much more quickly and with fewer mistakes. Taken together, these two benefits spawn even more benefits such as: increased job sharing, more efficient use of human resources, faster time-to-market, and a reduction in backlogs.
• Increased Consistency. Because you are performing each step along the path the same way each time, you are limiting the amount of variations to the process. This dramatically increases the consistency of the output of your process. There are fewer errors in the final result, and the result is much more likely to be as expected. This dynamic was proven years ago by W. Edward Deming, the founding father of Total Quality Management. (See appendix for more information on Deming and TQM).
• Increased Predictability. The formula here is so simple: Chaos = Unpredictability, Consistency = Predictability. It is this defined and enforced process that removes the chaos and replaces it with the consistency, which then leads to greater predictability. This means that everyone involved in the process intimately knows each step of the process from start to finish. Once the process begins, it is much easier to monitor its progress. You will know more quickly when the process stops, when it deviates and when it gets bogged down. The sooner you know, the sooner you can take corrective action to reduce the time lost and increase the accuracy of the final results.

Software Features Supporting Process

• Improving your Existing Process. If you have already established a formal process to manage your workflow, can the tool implement and enforce it? Will the tool make following your process easier, saving your team valuable time? Does it make the process repeatable?
• Creating a Process. If you have no process, can the tool help you create one? If you have a poor process, can the tool help you improve it? Is the vendor knowledgeable enough in process management techniques and best-practice methodologies to guide you?
• Complete Solution. Can the solution manage your entire process, helping you from start to finish? Will it adapt to your desired level of process compliance (e.g. SOX)?

Information Documentation

It has been said that a typical IT professional spends 10% of his day reading information but 40% of his day searching for that information. Said another way, data doesn’t become knowledge until you can get your hands on it (and your mind around it!).

Having defined and implemented your process, the next benefit of a more formal SCM process is that it collects informative data. In fact, the vast majority of this information is collected automatically in the form of process-based documentation. This elegant sounding term is simply this: as people push work through the process, the process documents the who, what, when, where, why and how of that work.

Benefits of Process-based Documentation

• Continuous improvements can be made to your process. The golden rule of Continuous Process Improvement is that you can’t improve what you can’t measure. Now you’ll have the measurements to pin-point what is working efficiently and what is not.
• Easier compliance with best-practice and auditing regulations. There isn’t much that makes auditors smile, but giving them stacks of reports about your activities really lights up their faces.
• Enhanced communication among teams and across teams. It doesn’t matter if you are a two person shop or if you have dozens of developers across many continents, people need information about what the other members of the team are working on. This information must constantly be kept up to date, must be easy to find, and must be easy to filter.
• Faster, more accurate determination of the health of a project. By the same token, project managers need current data, filtered views and meaningful reports to track the progress of work.
• Highly automated capture of data. Automated means the data is captured consistently and accurately every time. Automated means little or no human effort is required. This frees your staff to focus their energies on why they are there in the first place: to drive your business forward.

Software Features Supporting Documentation

• Information Capture. Look at the quality and quantity of the information captured. Can it be customized? Is it enough for your needs? For the needs of your team? Your auditors?
• Information Retrieval. Evaluate what takes to access this information. Remember, you’d like to spend somewhere less than 40% of your day gathering this knowledge. Look for features here such as ad-hoc filters to get just-in-time views, parameter driven graphical reports and logical displays with meaningful values and dashboard-type metrics.
• Information Automation. Evaluate the level of automation. How much human effort is required to capture the data you need? How much effort is required to keep the information up-to-the-minute up-to-date?

Security

Having a process is pointless if people can circumnavigate it. Have logged data is worthless if can be altered. While SCM security certainly means locking down your production source and objects, it also means controlling who does what, to what, when and how. In other words, security enforces the adherence to your established procedures. No more cowboys. No Wild Wild West. You need to set it tight, keep it tight and prove it’s tight.

Benefits of a Secured System

• Production control. You know that the source and objects in your production environment can only be changed via your established process. This gives you greater confidence that the master source in production matches the master object in production.
• Adherence to procedures. You know that your procedures are being followed because there is no other way to effect changes. This ensures that the changes that come out of your process are what you are expecting. It also ensures that you have the full documentation you need come audit time.

Software Features Supporting Security

• Ease of implementation and maintenance. Look for a tool that enables you to set security based on job types or roles, e.g. developer, manager, QA tester, implementer. Then associate the many individual users with these roles, only changing the default settings when absolutely necessary.
• Ability to fine tune. Each key step in your process should have at least a Y/N switch for each profile. Make sure your tool gives you all the security options per role that you will need not only today, but as far down the road as you can see.
• Integrate with other security lists. As much as possible, you’d like a tool that can tap into other security tools and lists that you are already maintaining, e.g. LDAP.
• Graphical or web-based access. This separates the user interface from the data and the platform, giving you platform independence, fast learning and ease of use.
• Effective reporting. You need to continuously monitor the effectiveness of your policy with easy to understand audit reports that show both the adherence of your security and the places where people are violating it.

Ease of Use

For those of you who are counting along, I promised three tenets and here is my fourth! As a SCM Sales Engineer of over ten years, I’ve given thousands of product walkthroughs. Someone during the call will usually ask me, “Is the product easy to use?” In fact, they ask it with such frequency that I felt compelled to add it here. However, in my opinion, it isn’t worthy quality for evaluation.

“Not worthy?” you say. “Isn’t ease of use important?”

Yes, of course. It is vitally important. It is so important that no product on the market today could exist if it was not truly “easy to use”. Next, ease of use is such a subjective term. What is easy to one user seems impossible to the next. Finally, during the evaluation stage, just how much of this can you determine? Your closest view is during the live demonstration and guess who is driving that? A seasoned Sales Engineer who knows the product like the back of his hand, can give you the demo in his sleep and is well trained to make the product look how? You guessed it! Easy to use.

So, save yourself some time. Don’t ask the vendor if it is easy to use. If you must have some rating on the product’s ease of use, find out some people that you trust that are using the product and ask them.

Powerpoint Tips and Techniques

It seems that many of us are in the process of writing or at least improving, the content of PowerPoint presentations. Additionally many of us are also giving these powerpoints, often to audiences that we can’t see. I’d like to offer some suggested “rules of thumb” that might help guide you as you create and give these presentations.

When we create a PowerPoint, our natural instinct leads us to cram our slides with tons of information and then to talk very quickly through that information so we get through it all on time. However, when you give so much and at such a rapid pace, it’s the old “drinking from a fire hose” effect: they end up with absolutely nothing. Focus on quality, not quantity. Less is definitely more! The “spray and pray” method is completely ineffective.

My suggestions would be along two lines: Simplify your Content and Engage you Audience.

Simplify your Content

First, do enough cutting so that you can get through your presentation on time in a natural and easy pace.

On each slide, ask yourself if this slide address something of importance from the audience’s point of view. Remember, you are giving this presentation for their benefit, not your own! Is it one of their pain points? Does it answer one of their questions? Does it separate Aldon from the competition in their minds? Is this information that will help them understand the demonstration? Knowing that they will retain only a very small fraction of the information you give them, is this point one that you want them to remember as they walk out of the conference room?

Also be cautious about putting too many words on slides. They will try to listen to you and read at the same time, but they can’t, so they shift between half-listening and half-reading. The net effect: they get little of your message. Pictures and graphs are fantastic if you have the time. If not, have your text limited to the primary speaking points. Let your voice explain the details. If you need to spell it all out for yourself to give the presentation, use the speaker notes section and print off the powerpoint before you give it.

Next, pay attention to how your presentation looks visually and follow the KISS method: keep it simple. Key points here include:

• Be consistent with font type and font size. Too many variations distract from your message rather than enhance it.
• Ditto with colors.
• Animation is a lot of fun to play with, for sure, but it adds very little and can distract a great deal. So use it with great caution and very sparingly.

Finally, don’t try to tell your audience how they should feel. It doesn’t work and it makes your entire presentation suspect. Instead, tell them about a key feature you know they’ll be interested in (i.e. from the discovery call) and tell them how our other clients feel about it. For example, instead of saying “here is a feature your developers will love”, say “our customers that have used CVS before tell us that they really love our private versioning functions.”

Involve and Engage your Audience

At the start of every presentation, you generally get about two minutes of “free time” from your listeners. If you don’t give them a reason to listen to the rest of your presentation in those two minutes, you will most likely loose them. Starting off by telling them how great you are isn’t going to get you very far! Instead, tell them what’s in it for them. Tell them what they will gain by listening to you. Tell them how you are going to get them there and how long it will take.

Even if you succeed here, you can still loose them as your audience as you go unless you involve them more often. You can do this visually and verbally.

To involve them visually, I like to use a pointer to point to what I am talking about on the screen. If you are presenting over the internet, you can tell powerpoint to keep your arrow pointer “always on” by clicking in the lower left corner as it is in play mode. This is effective as long as you don’t fidget about too much, then it gets distracting.

To involve them verbally, set a mental note to stop every other slide. Stop presenting, take a breath and ask them a question. Sometimes a simple close-ended yes/no question is all you need. At least you are taking a break, pacing yourself, checking in with them, keeping them awake. Most importantly, you give them the opportunity to interrupt you to ask for clarifications or questions.

Here are some sample close ended questions (I’m sure you can come up with a hundred more!):

• I remember from our discovery call that this area was of importance to you. Can you see how your shop can benefit from a feature like this?
• Do these concepts make sense to every one so far?
• Has your department faced any problem like this in the past?
• Could your developers use a feature like this?

A “yes” answer from them not only lets you know you’re on target and reaching them, but it reinforces in their minds that you are hitting good points. This keeps them engaged and, even more importantly, leaves them feeling generally satisfied with your solution. If you can associate these questions to pains that you already know that they have, then you get a great percentage of affirmative responses!

Conclusion

Powerpoint is a great tool, and, like any tool, it can either help you or hurt you. With a little attention and a little practice, it is possible to hit ‘em out of the park every time. You know you’ve finally arrived when someone in your audience says to you “Can you please send me a copy of that powerpoint? I’d like to show it to my boss.”

COMMON: A Vendor's Point of View

I was digging around the other day and ran across a discussion in another forum about the decline in attendance at COMMON. Here is an excerpt from one attendee's point of view that I took some exception to.

"Also, the vendors should put some of the blame on themselves for being pains in the neck after the conference by calling you up every week to see if you are interested yet. Over the years I have learned that the free stuff is not worth giving up my business card only to be hassled by a sales person who can't take no for an answer. I have yet to get really useful information from someone there on the Expo floor because the sales force really can't answer the technical questions that many of us have about their product. It really irks me to walk through the Expo floor only to have one of them ask, "Are you doing any software development?" or some other pitch that the obvious answer is yes. Of course we are; that is why we are there! I would rather see a focused technical session on their product that I could attend if I was interested. Who can decide anything on the five-minute rat race that is given at the Expo?"

My Response:

First of all, the expo is a very strong financial supporter of COMMON. Take away the vendors and your registration fees will jump dramatically.

Second, the expo is a service to the attendees. If you scoff at that thought, then you are missing the point. Most software vendors view themselves as a solution providers. Yes, we would like to sell you our software, but the only way we are going to do that is if we can prove to you that it is a valuable and cost-justifiable solution that you and your company need for problems that you are currently having. I can't tell you how often people stop at our booth to enter a raffle only to leave willingly with product brochures describing solutions that they never new existed for problems that they are currently plagued with. Additionally, any solid vendor is not going to sit still in their product line. There will always be something new. So, skipping the expo because "it's the same ole', same ole" is doing both yourself and your company a disservice.

Third, let's be realistic: if you drop your business card in a fish bowl, someone will call you. If you don't want to be called, don't give out your card, just take some literature and move on. If you are called, but not interested, simply tell the person this and ask them not to call you again. Chances are good that they won't. No sales person has ever made a sale by pestering someone to death.

Finally, many vendors do, indeed, bring their technical resources to the shows. I am living proof. My company sends me quite often, just for that reason. In fact, many of them also give sessions in their particular field of expertise. I have given several "Change Management 101" type sessions. Will they be able to answer your every and most difficult technical question, no. No one person can, and no company can afford to bring their entire shop. But I don't know a vendor on the floor who isn't willing and able to forward your question on to the right person.

So, the next time you are at COMMON, give the Expo another shot. If you have the right mindset, I think you'll be pleasantly surprised. But be careful! You just might find something there that could dramatically improve your life and your company's bottom line.

Setting up QA in an SCM Environment

A customer asks: "The upper management here is also trying to get a Quality Assurance Environment set up to use with our SCM tool. We do not have a lot of experience with QA environments, can you recommend a website, document or other information you might have in order for me to get started? I'm not looking for specific details, but would like road map of things to keep in mind when setting something like this up."

First of all, let me state that there are some SCM vendors that offer their own testing tools and there are other SCM vendors that recommend another vendor's "best of breed" testing tool. Each of those solutions has its pros and cons (I'll save that discussion for another blog-day!)

What all vendors provide, however, is the ability to manage your QA environment. Your first big question is this: how much testing do you need and who's going to be doing it? Is it the programmers? Do you have a separate QA staff? Will then end users get involved?

If it is just the programmers, then you probably just need one "System Test" environment, e.g. DEV to ST to PROD.

If the developers test first, then hand it off to QA, then you should have separate environments (and libraries) for each level, e.g. DEV to ST to QA to PROD. This is because the QA people will want very tight controls over when a series of changes can come into their world and when it can leave their world. They don't want to be shooting a moving target, right?

Finally, if you want the users to get involved in testing and approving their changes, you should set up a User Acceptance Testing level, e.g. DEV to ST to QA to UAT to PROD. Again, the idea is that you want the UAT environment to be very tightly controlled. Only one task's objects should typically be in UAT at a time.

For each environment you defined above, you will teach your SCM tool how to manage it by answering the following questions:

• What are the library name(s) for source, object and data? (You can have them all be in the same library if you wish).
• Will you maintain a full compliment of all database files at each level? (I recommend yes, albeit with a very small set of test data in each level. This gives many advantages to you that I can explain later if you'd like).
• Would you like to have just one data library, or multiples? (Hint: multiple data libraries sometimes come in handy if you have more than one tester, more than one application, etc).
• Will you maintain a full compliment of all objects at each level? (I recommend no. Keep each level empty except for the objects currently being tested at that level. Let you library list find items in the higher levels when you run your tests).
• How should you promote into this environment? (I recommend copy source, compile the object over the appropriate library list).
• Whom can execute the promotions at each level? (I recommend that Programmers can promote freely into the ST, but only QA can promote into QA and UAT).
• Would you like any one (or any group of people) to approve or sign off on the promotion before it can run? (I recommend yes! This is an easy way to get "electronic signatures" on file proving that you have followed your established procedures. It is also a fantastic way to end forever the classic complaint from the end user "this isn't what I was expecting"!)
• When a promotion is ready to be pulled in to the next environment, whom should be notified, how and what to say?
• When a promotion has successfully updated an environment, whom should be notified, how and what to say?
• Would you like to be able to recover (undo) a promotion into this environment? (I recommend yes to give you the ability to back out a promotion that really messed up your environment or that was promoted too soon.)
• When the promotion into the next environment is successful, would you like to remove the items from the lower environment? (I recommend yes for all items except the database files).

There are two "best of breed" testing tools that I have experience with. Original Software and SmartTest. Original's web site has a host of other great white papers that are worth reading to increase your base knowledge of the QA process.

Also, I'd highly recommend that you read this excellent white paper by Paul Conte, "Application Testing Basics: A Practical Guide to Improving Software Quality". You can find it here.