infrastructure

Requirements-based provisioning useful in all aspects of IT

At some point in time, we all have likely engaged with some level of requirements-based testing (RBT) or development. While RBT is generally a fundamental in software quality, there can be limitations and cons as described in this Software Quality Insights tip. In my professional IT work, I currently focus primarily on infrastructure and related technologies. But that is not to say that we cannot take a page from the requirements-based disciplines.

One of the most frustrating situations in the new build process of any system or collection of systems is when others have applied technologies without defining requirements. This frequently arises in disaster recovery, system availability or business continuity arenas. While the development and application teams want to provision a highly-available solution, there can be a disconnect between the internal decisions and what infrastructure teams can provide.

The current IT landscape offers infrastructure professionals many options in protection and availability. This is made possible by virtualization, load-balancing solutions and a matured backup software space. My approach has been for the application and development teams to provide the availability requirements for a technology solution. This usually involves defining two important terms:

Recovery Time Objective (RTO) – How much time would be required to recover from any system-level failure that would make the system and business process available.

Recovery Point Objective (RPO) – A defined requirement for point-in-time recoverability for the business process.

The RTO and RPO work together to determine what availability and recovery would be provided to a business process. Infrastructure professionals can play this game quite well now with the current landscape of tools and technologies. Be sure to engage them as appropriate in the system provisioning process.

Why waterfall developers still shun Agile

Jon Kern, co-author of the Agile Manifesto, told me recently that many companies won’t adopt the agile development methodology soon. Why? Some companies are doing just fine with waterfall, he said, because it has worked in the past and is still working. Also, they see little chance that their business analysts and leaders will agree to get involved in the development process.

Intrigued by Kern’s assessment, I asked some software development and testing veterans for their views. I asked about their work with and opinions on why companies stick with waterfall development.

It’s true that waterfall methodologies can work quite well, said Mike Kelly, a software testing and development consultant and a fan of the agile methodology.

“I know this will surprise some people, but I’ve worked on several successful waterfall projects,” Kelly said. “It’s crazy, I know. Seriously, I’ve been a member of teams that do roughly the same thing, with minor variation, again and again. The business context is well understood, the requirements are mostly right upfront, and the team kind knows what needs to be done to be successful. If it’s working, it might not make sense to change it.”

Bernard Golden — CEO of IT infrastructure consulting firm, HyperStratus – has worked with development teams that don’t think the agile methodology can be effective in large-scale, enterprise projects. They think that agile is a good micro practice that should live within a good macro project management/planning process. To an extent, he agrees, and thinks agile is “best suited for scoped projects that have small user populations — built on top of robust system infrastructures built as traditional projects.”

Golden is also doubtful that having a “business person be part of the development process ensures that systems will achieve user satisfaction.” Thinking that “one guy can subsume all end user viewpoints and prevent end user political unhappiness strikes me as quite naive about the way organizations works.”

In this short video clip, Golden explains more about why agile may not stack up.

Kelly has also worked on projects where business managers just didn’t want to do more than turn in a list of requirements. “The business [people] didn’t get into business to talk about development methodologies, and to them, it’s often a distraction,” he said.

Requirements analysis expert Robin Goldsmith believes business managers don’t believe that doing systems work is their job.

“Agile is very much driven from a programmer’s perspective, and business folks don’t identify, understand, or agree with it,” said Goldsmith, president of the consultancy, Go Pro Management Inc. “ As an analogy, I have many years of experience working in the most technical of programming roles within IT; but these days I have no interest in fooling around with software internals—I just want stuff to work, and that’s not unreasonable.”

Goldsmith sees the agile-versus-waterfall debate as the subtext behind a larger business-versus-IT cultural issue that causes continual problems for software projects.

Do you agree? I’ll be continuing this discussion with software testing and development experts, and your input would be very valuable. You can share your experiences and views by commenting below or writing to me at  jstafford at techtarget.com.