It always amazes me as to how much the WDSC team accomplishes and delivers, given the fact that the team consists only of about fifty people. As a group, we have to be sufficiently staffed to fulfill the ongoing needs of our loyal customers and to provide them with a future road map that enables them to be more successful in order to sustain and advance their livelihood. All this has to be accomplished in an environment of continuous technological advancement which over the decades has given us a multitude of technologies that we have chosen to embrace.

As a team, we are somewhat unique in that we are not solely focused on a single technology area, such as a database, or a compiler. We create and support a diverse range of tools that execute on System i and graphical workstations, in order for our customers to create programs for System i, workstations, and web browsers. We work with terms such as libraries, files, members, records, fields and subfiles. We work with acronyms such as RPG, DDS, LF, DSPF, PF and CL. We work with commands such as WRKRMTDFN, and CRTSRVPGM. We have programmers that are proficient in the intricacies of the RPG language and compiler with its tokenizers, parsers, program verifiers and syntax checkers. We have experts in the use of programming languages such as C++ and Java, and frameworks such as Eclipse and its own set of technologies, SWT, GEF, JFace and EMF, We have people that are adept with web based technologies such as web application servers, web browsers, Javascript, JSP, JSF, Struts, and HTTP. We have people that are proficient in providing online help, scheduling customer usability feedback sessions, accessibility requirements, frameworks such as RSE and Lpex, as well as product packaging and installation. On top of all this, we frequently discuss possible ways for customers to modernize their applications with newer advancements, such as Web 2.0 technologies in order for them to remain competitive.

Knowing about, and being highly skilled in technologies is not sufficient. As with any other team, we also have to work through project management issues such as overlapping product release cycles, dependencies, skills, sizings, development, testing, support and intellectual property issues. We have evangelists who go out to conferences so that we may communicate and obtain feedback on our product road map, and those who provide training sessions to customers who want to experience our offerings. We are also enmeshed in the fabric of the corporation to ensure that our goals and time frames are aligned.

From our customer’s point of view, we must seem like a much larger organization since we are responsible for so much, and have such a diverse set of skills. However, the reality of being a small team necessitates that each one of us has some knowledge, skills, and responsibilities that no one else has within the team. The resulting risk posed by attrition cannot be simply alleviated by swapping people around to other team member’s tasks in an attempt to transfer and share skills. The skill sets are just too varied and different. For a highly efficient team as ours, who constantly must chose only the highest priority items to work on, the additional disruption and burden would no doubt result in later deliverables, which is unforgiving from a customer point of view. A better way would be to grow the team.

So why does the team have the size that it does? Well, since we’re a business, it all comes down to profitability. Corporations naturally react to a product that is not providing sufficient income by reducing the number of people working on the product. This enhances a group’s efficiency quotient, with the side effect of enhancing each individual’s uniqueness within the team, for the goal of greater team profitability.

Profitability is affected by many factors, such as the cost structure of the product as well as how the product is packaged. In order to properly determine product selling cost and packaging structure, we must acknowledge that there exists a diversity in our customer set where our customers are not all the same, and therefore cannot all be treated in the same manner. One size does not fit all.

Our current two offerings, the standard and advanced editions is analogous to an automobile manufacturer selling two versions of a vehicle; a base version, and a fully loaded version. We have all heard of a situation of wanting a sunroof only to find that it can only be purchased if you pay an exorbitant amount for a package that includes the navigation system and upgraded sound system. How many of you have thought of obtaining a single cable or satellite television channel only to find that it only comes packaged with an expensive group of other ’specialty’ channels that you don’t have a need for? We would all like to be able to pay for, and obtain only the things that we need. Otherwise, we have less funds to pay for other things that we could invest in.

The opposite to pre-packaging is componentization, which has is a concept where one pays for a pizza, or a burger, and then pays extra for each topping that is desired. After all, not all of us want cheese, or pickles. Componentization of any product has benefits, the first one being that customers pay only for what they need. The second one being that the vendor gains the ability to understand the volume of each option being purchased. Without this knowledge, the vendor can only obtain a general feeling of what to invest in, usually through direct customer interaction, which statistically is not as accurate as it could be since not all customers are involved. An intelligent deprecation plan could be adopted for features that are rarely used, or are to be replaced. Sales volumes would predict when deprecations should occur. The same holds true for determining what items to continue to invest in. The direct result of componentization is a vendor that is more in tune with its diverse set of customers, and if done correctly, the return on investment will rise, and there will be an increase in investment in the product team, and the product team grows.

Amongst other things, our product cost structures, and the way we package our products have to continually adapt to the current marketplace. Hopefully, both our diverse set of customers, and our team with its diverse set of skills, will all become happier System i campers with more choices to make. Meanwhile, as with any other business, our forward thinking team will continue, with the best of our ability, to help our customers by providing the things that we can only afford to produce. C’est la vie.

3 Responses to “The Reality of Diversity and the Need for Choice”


  1. Hi Brian,

    I enjoyed your post, especially the point about in a componentized world, using sales volume as a predictor to when deprecation would occur. In retrospect it seems obvious, but wasn’t something that crossed my mind before..

  2. Buck Says:

    Very good post. All businesses go through this sort of evaluation in packaging their products. And the fashion in packaging goes through a cycle from all-in-one to choose-every-option-separately.

    System i customers are very much accustomed to the former. That ‘i’ means integrated. We don’t have to choose the database (or version thereof), whether to use MVS or VM, what security package we should buy, etc. It’s all in there.

    Personally, I lean toward the salad bar pricing model for components rather than the pizza topping model, but that may be my years of midrange experience talking.


  3. [...] The Reality of Diversity and the Need for Choice « WDSC Development Team Corporations naturally react to a product that is not providing sufficient income by reducing the number of people working on the product. This enhances a group’s efficiency quotient, with the side effect of enhancing each individual’s uniqueness with (tags: IBM WDSC people efficiency profitability componentization) [...]


Leave a Reply

You must be logged in to post a comment.