In the last decade, information technology has become increasingly important to enterprises of every size, everywhere in the world. It has literally changed the way the world works. And in the 21st century, organizations will not only have to continue to reengineer their businesses, they will have to do so at breakneck speed. This pressure to redesign our businesses around evolving technologies is making it mandatory for organizations to model their businesses and business requirements faster and faster; and as systems become more integrated, they involve more and more users
But, unfortunately, while enormous effort has been expended over the last couple of decades on computer databases and programming, far less has been devoted to developing new ways to develop world-class business models and requirements. This white paper is intended to address new trends in business modeling and requirements and to pinpoint how large organizations can take advantage of these trends.
Let’s begin by looking at the way other fields have been using computer technology to aid their modeling and requirements process. For example, twenty or thirty years ago, ”doing architecture” meant having a roomful of architects and draftsmen slaving away developing huge numbers of high-level, perspective, and detail drawings. These drawings were needed so that all the people involved in specifying the requirements for a new building, i.e., the owners, engineers and builders, could “see” how all of the elements of a structure were going to fit together. Not surprisingly, this was an enormous and time-consuming task.
Today, however, it is possible to design buildings to a high degree of realism in a very short time without all the work and all the drawings. Using state-of-the-art architectural software and computers, “doing architecture” in the 21st century means specifying a building and then letting the computer do the drawing. It is now possible to let people visualize exactly how their buildings will look down to finest detail—in fact, architects routinely invite their user/owner’s to “walk through” their buildings before the first foundation is laid.[1][1] Modeling software and high-speed personal computers has made all of this possible.
Figure 1 - Architectural Drawings produced with Computer-aided Design Package
This computer-aided design revolution is not reserved just for architecture either. Every night on television, you are apt to see automobile manufacturers display virtual 3D versions of their latest cars. But what you see on TV is only the tip of the iceberg. In their engineering departments, real automobile engineers using real high-speed workstations can not only design 3D cars and parts, they can visualize them as well. In some cases, these engineers can automatically produce actual physical prototypes of the cars and parts themselves.
The
same thing is happening in aerospace. Before Boeing put their 777 into
production, ten thousand Boeing engineers not only designed the plane
electronically, they also simulated it’s performance characteristics using
“virtual flight tests.” And they also created “virtual assembly lines”
so that problems with machine tools or assembly glitches could be worked out
before the expending billions of dollars on a real 777 assembly line.
Q. With all of the success of computer-aided design, the billion-dollar question is: Why can’t business users, managers, and developers model their business systems requirements and then visualize the results like architects and engineers?
A. They can!
Like architects and engineers, business modelers and software developers can work with their customers in real-time to produce new business systems models that users (and developers) can see, use, and test. Organizations can model their businesses and prototype these models using an integrated business modeling and systems requirements methodology called Next Practice Methodology (NP/M). NP/M, in turn, is built around a set of advanced modeling tools and techniques called Next Practice Development Environment (NP/DE). NP/M and NP/DE are the products of The Ken Orr Institute, one of the world's leading software engineering research organizations. To come up with NP/M and NP/DE, The Ken Orr Institute has combined decades of research and experience in business requirements and software engineering together with state-of-the-art technology from two leading edge software tool vendors: ProForma (ProVision Workbench) and ARTech (GeneXus) to create NP/DE.[1][2]
Figure 2 - Focus of Attention during Design
Researchers in a variety of other fields have found that using models or prototypes dramatically shortens the time to come up with a good solution. For a great many problems, using drawings turns out to be a much better way of getting users engaged than does presenting the same information in text form. And working prototypes are better than drawings. In his book Serious Play, Michael Schrage writes about the importance of developing models and prototypes as key to creative collaboration. Schrage has found in his research that the ability to produce and use models and prototypes significantly increases communication while at the same time spurring creativity—people using models and prototypes learn to work with each other at a higher level!
Other people are catching on to the importance of producing software incrementally, one prototype at a time. In the last few years, a variety of “agile” systems approaches (e.g., eXtreme Programming (XP)) have caught the interest of the software world. Instead of focusing just on rigorous processes and tons of documentation, these agile methodologies focus on quickly producing working programs that do a small part of the total requirements, usually within a couple of weeks. Then, every week or two until the end of the project, they develop yet another working program with more functionality than the last. Over time, agile practitioners have found that they can come up with effective systems much faster than they could using traditional approaches.
Although organizations have been developing software for decades, only recently have they come to understand just how complex and risky the process really is. Now systems managers and developers are beginning to understand just how important the role of developing interim versions of working software is to the success of their projects. A recent study from Harvard researchers showed that one of the key indicators of the success of a new software product was how early in the process their users were able to get their hands on beta version of the ultimate product.
Researchers at The Ken Orr Institute have taken this knowledge about how mixed groups best communicate and collaborate and combined it with active prototyping to come up with NP/M. Because the approach is built around high-speed software that allows users to move quickly from one step to the next, NP/M provides a framework where teams of users and developer can move quickly from high-level models (context and workflow diagrams) of their businesses down to low-level user specifications (screens, reports, etc.), and then to prototypes using real data. Just as in architecture, rough systems requirements can be quickly entered, prototyped, and modified as many times as it takes to get to a solution everyone can agree upon.
The process for doing this within NP/M is called Systems Visualization (SV). Like architects or aerospace engineers, NP/M software developers work with Subject Matter Experts to "show" how their new system will behave under real-world circumstances. With current technology, you don't have to be an architect to "see' what your dream home will look like from any angle; with SV you don’t have to be an expert programmer to “see” your dream system either.
The Ken Orr Institute has a long history of pioneering software engineering methods. Ken Orr is the creator of a number of breakthrough technologies in software engineering. In coming up with NP/M, Ken and his coworkers took what they knew about rapid development of easy-to-understand business models and married that with automatic database design and program generation. This approach had been advocated before, but the tools to make this possible didn’t exist. Now they do. Working with ProForma Corporation, the developers of ProVision and ARTech Ltd. (the developers of GeneXus), Ken and his colleagues designed a state-of-the-art platform for requirements engineering.
What makes NP/M possible is the existence of a truly revolutionary set of business modeling, automatic design, program generation, and prototyping tools. No architect starting work on a major product today would think of beginning without a tool like AUTOCAD. In the same way, we think that no systems requirements project should begin without the right requirements, design, prototyping, and collaboration tools = NP/DE. The NP/DE consists of three major tools:
Each of these tools was selected as "best of breed" for its specific capabilities and "customized" to provide seamless integration within the NP/M framework.
NP Development Environment
Where ProVision, GeneXus, and GXPX provide the technology for Systems Visualization, eProject provides the technology for all of the other communication that goes on within an NP Project. You can think of eProject as a 21st century “war room,” where all the documentation, email, standards, training material, etc., is stored so that anyone with the right security codes and access to the Internet can store and retrieve project information. NP Projects come with a “requirements project template” that cuts down the time required to start a new project. Since one of the driving forces behind agile requirements is to get things done as rapidly as possible, eProject makes it possible for project teams to work together in spite of location and/or scheduling conflicts.
NP Projects are very much like the “agile” projects discussed earlier. NP focuses upon providing state-of-the-art artifacts that allow users and developers to define their new system. The only difference is that instead of just getting the code, the user gets an extensive set of documentation of his project as well.
In
most large NP/M projects, the 1st week is spent setting up the project, training
personnel and developing the initial business model(s). The second week is spent
developing the first set of user interfaces, database design, and a working
prototype.
The process then continues for anywhere from 4 to 12 weeks, with new prototypes being developed and reviewed, sometimes as often as two or three times a day. Sometimes questions are raised and other SMEs have to be brought in; sometimes people have other commitments or go on vacation. No matter what, NP/M projects are built around the concept of "time-boxed" management. Time-boxed project management means that the project is broken down into predefined deliverables that are produced at (or by) specific times. Changes and additions are then incorporated based on whether they can be finished in that period of time; otherwise, they go into the next release of the prototype, at most 2 weeks later.
Since NP Projects are much more interactive than most traditional requirements projects, it’s especially important, that all the right people are on board. Experience has shown that a number of different sets of skills must be employed for such a project to be successful.
We have found that a successful NP Project has the following roles:
Normally, the Requirements Project Manager is responsible for all the organizational and management functions for the project, but because NP Teams are small, the RPM usually can fill in for one of the other functions. On the first couple of projects, the NP Trainer/Facilitator is usually brought in from outside, as is the NP Prototyper/Librarian. Subject Matter Experts (SMEs) are recruited from within the organization based on their knowledge of the existing and/or planned business environment. Technology Experts (TEs) are recruited for their knowledge of existing and/or anticipated technologies planned for the new business.
An organization chart for a typical NP Project is shown below:
Decades of research and development have gone into NP/M and NP/DE, but without training, all of this would be wasted. Thus, the first week of a typical NP Project is devoted to teaching the project team the basics of NP/M and enough about the NP/DE so that the team can get right into the requirements/prototype phase immediately. As the project progresses, the project team receives additional on-the-job sessions about the specific uses of the tools and method.
The NP Requirements Prototyping Package includes the following:
· 1 copy of ProVision -- Business Edition
· 1 copy of GeneXus
· 1 copy of Next Practice Interface
· 1 subscription to eProject
· 2 days of training on ProVision
· 3 days of training on GeneXus
· 5/12 weeks of 2 consultants (1 Facilitator / 1 Prototyper)
What's the bottom line for using NP/M? Well, the real advantage is that the users get something that they can see, touch, and manipulate. If they don't like the way the system behaves, they can change it before it’s too late.
On the technical side, the developers get a system that is completely documented: screen and report layouts, database tables and attributes, and business rules for the most important functions. Moreover, all the documentation is always up-to-date. Whenever changes are made to the prototype, those changes are automatically made to all the appropriate documentation.
Most importantly, however, the users and developers have a common reference point--the prototype. At the end of an NP/M project, a very large portion of the risk is removed from the project. Management knows the project is worth doing, and everyone has a common point of departure.