Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM WebSphere software products Authors: Pat Romanski, Liz McMillan, Yeshim Deniz, hyper filter, Timothée Bensimon

Related Topics: WebSphere

IBM WebSphere software products: Article

Solutions, Not Technology, Drive WebSphere Products

Solutions, Not Technology, Drive WebSphere Products

Customer involvement at all stages of product development, including early access for independent solution vendors, is crucial to IBM's strategy for managing the WebSphere Application Server development process, according to the WebSphere marketing team, headed up by Scott Hebner, director of marketing for WebSphere infrastructure software.

The WebSphere marketing team includes Joe Anthony, program director for WebSphere Extensions marketing; Derek Bildfell, program director for business development; Aimee Munsell, program director for WebSphere Application Server; Bernie Spang, program director for WebSphere Studio marketing; and Stefan Van Overtveldt, program director for WebSphere Technical Marketing.

WebSphere Developer's Journal editor-in-chief Jack Martin recently had the opportunity to talk with Hebner and his team in a wide-ranging and exclusive discussion. This second installment focuses on customer and partner input, early access to new technologies, rapid adoption, and the naming process for new products.

WSDJ: Since you're the group that decides what WebSphere is going to be next - because WebSphere is a lot of different things to a lot of different people and it's a product that is still obviously metamorphosing - how exactly do you decide what's going into it next? What makes you pick grid computing, for instance, as something that should be part of an application server as opposed to some type of translator that would work with all PDAs. How does that happen?

Van Overtveldt: One of the key things is that there is an incredible amount of technology that becomes available to us from our research department.

WSDJ: Yes, I've been to Watson - you have a tidal wave of technology coming out of your research department.

Van Overtveldt: We've been the patent leader in the industry for 10 years in a row now. We work with customers more and more in solving real customer problems and getting technology out of this, which we then use to drive our products or drive open standards. For example, we have technology out with customers right now that allows companies to use Web services in a more business-oriented fashion. It's the concept of service provisioning that none of our competitors can match and that we already have in production. Then, obviously, there are the more traditional ways of meeting customer requirements...

WSDJ: I've done a lot of work in Watson over the years and in any given cubicle is a scientist working on a product; in the next cubicle there's another scientist working on a completely different product; and three cubicles down there are five scientists working on another product - there are thousands upon thousands of them there. So how do you decide if a product is something a customer wants?

Munsell: We've always spent a lot of time with customers and what we've done in the last two-three years is drive a much more customer scenario-based process. So rather than just ending up with a list of cool individual features customers might want, we really try to understand much more in depth the types of projects the customers are trying to do every day and what their experience needs to be - everything from trying out the product, to purchasing it to installing it, deploying new apps, and then managing those applications.

In addition we are getting customers and partners involved earlier in working with development in a joint process to see what features we need to drive in to make that experience real. The biggest challenge of managing the application server development process is that since we have gotten so popular, the number of requirements has just escalated, both from other parts of the company, and from customers and partners. We probably get to maybe one tenth of the different things that we would like to do in each product coming out.

Bildfell: In our prioritization, we also consider what we have to build into the product, and what is available from our business partners. For example, emerging solutions in many areas of Web services provisioning and management are available from many of our partners, such as AmberPoint and Wily Technology. Where there are reliable partner solutions to fill out our customer requirements, it becomes less critical to build this capability into our products. This is also a critical differentiator in our approach to Eclipse; we've defined and delivered the fundamental technology, and we encourage our partners to build out specific solutions to their selected customer segments.

WSDJ: Say you have 100 features and only 10 of them are going to make it - what makes the 10 truly based on the majority of customers asking for them? Because you are saying that what's going into your products is solution driven, rather than technologically driven. You are not putting things in just because you can; you are putting things in because people want them.

Munsell: The top items are the ones most customers need but also the ones that will have the biggest impact on helping them solve their problems. We have to do some projection into how new technologies can solve a problem better in the future.

Spang: One of the other things we rely on is our early contact with customers through mechanisms like our alphaWorks site, where our research and development labs can post early technologies before they are committed in any products. The visitors at the alphaWorks site know that; they know they're getting access to the bowels of the research labs. From that we get feedback. Building on that we have teams such as the jStart Team (which stands for jumpstart), which started in the early days of Java when they were going out to jumpstart our customers' knowledge of Java. That team has evolved over the years to work with XML when it first came out, and Web services when it came out. Now grid computing is a part of it.

These are teams that go out and work with customers who are piloting things, testing things out to see how this new technology will solve their problems effectively. We are doing it in such a way that the customer knows that they are piloting something, and we are seeing how it goes. That gives us direct feedback from the real use and real value that the customers are seeing or, as we sometimes find, not.

Bildfell: This early access to our technologies is key to the rapid adoption we have seen in the independent solution vendor (ISV) community. ISVs need to start building their solutions before the latest technologies are stable enough for deployment in production solutions. These early experiences by the ISVs and early-adopter companies that work with JStart really help us to remain the leaders in emerging technologies - such as Web services and autonomic computing - which become the industry-leading solutions of tomorrow.

WSDJ: So, it's solution driven.

Spang: Yes.

WSDJ: That leads me to a question I have always been interested in. How do you decide what to name something? What is that process? Does Scott come in one day and say, "that's what this thing is." How do you end up with these names?

Munsell: As one example, we recently introduced WebSphere Application Server - Express. We went into that process and looked at the midmarket customers and customers who are really in the very early stages of e-business and looked at what they needed. We started to talk about the benefits that they are going to get from a product like this, and asked "what do we want the name to mean to them?" A lot of the feedback was that this is something that is going to have to be fast and easy, get them going quickly, sort of an on-ramp to getting on the expressway, so to speak. We came up with a short list of candidates, beat it up a lot, and "Express" was where we came out.

WSDJ: Do you do focus groups on naming? After all, the computer industry is the worst place for acronyms.

Munsell: We do focus groups because the two things we are trying to balance are, first trying to come up with something unique and accurate, but then making sure it is plain enough that people can readily understand what it is.

WSDJ: Exactly.

Munsell: I think a lot of the names we started out with and thought were really great descriptions turned out to take a paragraph to explain to the focus groups, who are a proxy for your prospective customers. Not a good thing.

Spang: One of the big accomplishments of my team over the past two years was that we had to decide on the brand transition, the naming transition from our VisualAge for Java product into what is now WebSphere Studio.

WSDJ: Which is an excellent name, by the way.

Spang: Thank you. But it came with a lot of problems. We already had a product line of WebSphere Studio Professional and WebSphere Studio Advanced, which at the time were on a different code base and were totally focused on Web development, the Web pages part. The Java development programming was VisualAge for Java.

We were faced with an issue where we had done focus groups on the right name for a development environment and Studio is one that resonated and was used by others in the industry, so it was high on the list. WebSphere Studio made sense, but we would have to transition from the state where our salespeople and customers thought of WebSphere Studio as just a Web development environment to thinking of it as a complete development environment.

One of the painful lessons that I have learned in the past two years is what you just mentioned about acronyms: we didn't get ahead of the "WSAD" use internally in time - "WSAD," which is used by all the development team, the people who built the developer domain Web sites, the developers who are writing documents and white papers about the product - and now the marketplace knows WebSphere Studio as WSAD, and we are now very much focused on working to change that - which is going to take a lot of effort. It would have been better to do it up front. WSAD is short for WebSphere Studio Application Developer, which is one configuration out of five base configurations of Studio, and it doesn't take into account the many toolkits that plug into those. It doesn't get the whole WebSphere Studio message across, and we are now in a bit of a recovery to get everybody to think in terms of WebSphere Studio. One of the other things I learned about naming is that you can't please all the people all of the time.

The process that we go through is to collect names and do a lot of brainstorming. We actually get the development team, the marketing team, and the sales team together in a room. We do brainstorming up on the wall, then we do focus group sessions. I've attended a few on the other side of the glass. One of the things that came consistently from developers about our product was, "it doesn't matter what you name it; if it's not good, I'm not going to use it, and if it's good, I don't care what you call it.

WSDJ: That's true, but the way I look at it - unless they can understand what it is in the first place, what you end up with is a very obscure product that a lot of hard-core coders may be using, but you miss maybe 95% of the market.

Spang: That's why we ended up using WebSphere Studio - simply because people know what a studio is - and then we named the configurations for the developer role: an application developer, a device developer, a site developer.

WSDJ: Like "station wagon" - everyone knows what you are talking about.

Munsell: In the technology industry, in particular, one of the things that you have to do is look at what the acronym for a potential name spells. We had a few that got ruled out just for that.

Spang: Application Server Suite was right out.

WSDJ: I think you've answered my question about customers being involved in the process. It is obvious that they had input into everything that you're doing.

Munsell: I have always been impressed by the fact that everyone at IBM spends a lot of time with customers and is pretty obsessive about trying to meet their needs. That is a given. But it is also true that everyone has their own language and interprets things differently. One of the things we started doing that has made a big difference is that we have the cross-functional team - marketing, sales, development, support - in the room at the same time with early testers of the product or concept testers.

It is amazing the in-depth discussions that you get with the customers when you have all those different views in the room at the same time, as opposed to people walking away and interpreting what's meant by "easy," for example. We all know customers want rapid time-to-market. So in one session a tester was asked, "What is rapid?" Some people in development - based on certain experiences with customers - expected the answer to be three months. I thought maybe three weeks, and we had a midmarket customer in the room who pretty much said three days to get up and running with a new project.

More Stories By Jacques Martin

Jack Martin, editor-in-chief of WebSphere Journal, is cofounder and CEO of Simplex Knowledge Company (publisher of Sarbanes-Oxley Compliance Journal http://www.s-ox.com), an Internet software boutique specializing in WebSphere development. Simplex developed the first remote video transmission system designed specifically for childcare centers, which received worldwide media attention, and the world's first diagnostic quality ultrasound broadcast system. Jack is co-author of Understanding WebSphere, from Prentice Hall.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.