IBM i Requirements: It’s About (To) Change

August 15, 2016 Alex Woodie

Have you ever wondered how IBM comes up with ideas for how to improve the IBM i platform? According to the IBM i chief architect Steve Will, the most strategic ideas originate internally within IBM. However, many new features come from the customer base through formal requirements processes. And this fall, IBM intends to launch a new requirements program that will allow users to vote on new features over the Web.

There are currently four formal requirements programs that feed ideas for new IBM i features to IBM. These include the COMMON Americas Advisory Council (CAAC), COMMON Europe Advisory Council (CEAC), the Large User Group (LUG), and IBM’s ISV Advisory Council.

While IBM generally treats the four programs the same, there are differences among them, including the types of requirements that the programs feed to IBM and the quality of the requirement descriptions, Will says.

“At any given time, for any given requirement, one of them might be better described than the other,” Will tells IT Jungle. “The COMMON Americas Advisory Council has certainly done a very good job over the last several years in trying to help their membership understand how to write requirements that more cleanly describe what they’re after. That makes it easy for us to address the requirements more quickly than others.”

Since 2009, COMMON members have submitted about 300 requirements to the popular user group, which is the largest such group dedicated to representing IBM i customers. When a COMMON member submits an idea for a new feature or an improvement on an existing one, the requirement is vetted by COMMON volunteers, including folks like Vernon Hamberg and Phil McCullough, who determine whether the idea is worth formal consideration by IBM.

COMMON filters out most of the ideas submitted by its members, some which are off the wall. For example, IBM is not likely to provide access to the proprietary Technology Independent Machine Interface (TIMI) layer of the operating system anytime soon, but it doesn’t stop people from asking for it. And IBM apparently did not formally get to consider one idea submitted on behalf of your humble IT Jungle reporter several years ago. (The text of the requirement submitted to COMMON read as follows: “Problem: What’s the name of the box? Impact: Confusion at all levels. Work-around: List off all 30 names. Proposed solution: Rename it AS/400.”)

According to Will, IBM implements the majority of the vetted requirements that it receives. In a blog post last year, IBMer Dawn May stated that IBM implements 70 percent of the requirements that it receives from the four groups. That percentage sounds about right, Will says.

“Sometimes a requirement comes in from COMMON or the other user groups and we already have it on the truck ready to go,” he says. “Sometimes, even though they’ve been vetted through the CAAC, even though they get through to us, we don’t end up accepting the requirement, or we end up having to reject it, because it’s not in line with our strategy, or we’ll never do it.”

The requirements that IBM receives from the CAAC and the CEAC trend toward smaller, tactical changes that can be implemented with Technology Refreshes in between major releases, such as asking for a change to IBM i Access Client Solutions (ACS) or a change to BRMS. The LUG, members of whom which run the biggest IBM i environments that push the envelope of what the system is capable of, tends to ask for things that can only be implemented with new versions of the OS, such as an expansion of the number of jobs that can be put into the job queue.

Will says requirements generated internally within IBM tend to be more strategic, and are rarely rejected. “When we generate a requirement, it’s typically been through significant analyses before it’s come to us, so very few of them end up getting outright rejected because they’re bad ideas or because they’re not well defined,” he says. “We might have to reject them because we don’t have the resources to do that, or the technology is not grown up enough yet.”

IBM keeps an eye on the evolution of things like I/O and compiler technology, and generates requirements related to those “strategic, farther-off goals,” Will says. “Our ISV Advisory Council tends to look a little further out in terms of the strategic needs of various languages and technologies that are associated with that. But COMMON, COMMON Europe and the LUG tend to think more short-term.”

Every fall, Will and his team of IBM i business architects hold planning meetings to evaluate the new crop of IBM i requirements that have come in from the various user groups. Will estimates that his team–which consists of folks like DB2 for i architect Scott Forstie and security architect Jeff Uehling–will evaluate about 70 to 75 fresh requirements this coming September. That’s about the same number of backlogged requirements from last year that IBM is either working to deliver or still evaluating, he says.

Requirements are critical to IBM. “Since before I became chief architect, it’s been very important in helping us know we’re on the right track and investing in the kinds of things that will make a difference to customers’ businesses,” Will says. “I’ve continued it and been pushed even harder for us to, when we go through the planning cycle, to tie items that we’re doing back to the kinds of requirements we’re getting from people.”

When IBM kicks off fall planning next month, it will be fine-tuning a new Web-based requirements program intended to give Big Blue even greater levels of feedback on its products from its customer base.

“The new process that’s going to be new to IBM i is called the Request For Enhancement, or RFE,” Will says. “That process has existed for IBM’s Software Group products for quite some time, and we’re just starting to roll that out for the IBM i OS.”

The RFE process will allow IBM i customers to vote on the new features they want to see in upcoming releases, Will says. “That may provide us with some real value in the future,” he says. “We don’t have a way to do that with the requirements coming in the traditional method.”

IBM likes the new RFE process, which should debut this fall, because it connects people in a social manner and allows them to track and influence the ultimate disposition of new product ideas submitted to IBM. Ultimately, IBM may decide to give more weight to the votes received by actual customers compared to non-customers, he says.

The four existing user groups are currently evaluating the RFE and considering whether they’re going to use it as the front-end to their requirements processes, Will says.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search