Using Designer/2000 for Team-Based
Rapid Application Development
Rapid Application Development (RAD) is an approach to developing software that puts a major emphasis on a few key characteristics:
The RAD movement really took off in the early 1990s, as a reaction to the Computer Aided Software Engineering (CASE) industry's inability to deliver a software engineering panacea and fuelled by the availability of Graphical User Interface (GUI) builders [1].
Software Engineering takes as its premise that successful systems implementation is dependant on a proper understanding of the business need in its larger context. It is a strategic approach rather than a tactical approach. In the words of Clive Finkelstein, an originator of the Information Engineering methodology, “information engineering represents an integrated set of strategic development methods” [2]. This was essential if information systems were to become integrated into businesses and has borne fruit in many organizations. In many others it has not delivered the success that was expected. The organizations and situations that expose the limitations of this approach are those where systems implementation is slower than the rate of change of business needs, where the strategy changes faster than we can implement it. Organizations in rapidly changing environments must always put a higher premium on responsiveness than planning. Information Engineering strategy plans often assume that they take account of all possible events. They never do; the government changes a law that affects industry; a competitor makes a move that threatens profitability; a technology emerges that offers new opportunities. Yes, all of these can be folded back into the strategy, but we may not be able to wait. We may need to make a tactical response right now.
Strategic vision is essential to long term success, but without an ability to respond rapidly to the unexpected, information system developers will continue to be seen as an impediment to change, not as the engine of change.
Whilst the debate between strategy and tactics slowed the swift growth of CASE a new category of tools was emerging - GUI builders.
GUI builders deliver two key benefits:
Here was the solution to the need to respond to rapidly changing business needs: programmers building prototypes and reviewing them with users: users critiquing the prototypes and seeing the changes they needed almost instantaneously. And the programmers were having fun as well. They were freed from the shackles of the functional specification and empowered by graphical programming. Surely this was systems development Nirvana? More like the Land of the Lotus Eaters [3], except that the lotus eaters forgot their past. These early RAD adopters forgot the future. When these rapidly developed applications were implemented they met the initial needs of the user, but as those needs evolved, or expanded, the lack of documentation and the sometimes spaghetti-like nature of iteratively prototyped code meant that it was frequently easier to abandon the application and re-implement it. Where the project involved even a small team of developers the opportunities of GUI programming often meant widely and wildly different user-interface styles in the same project. The instant legacy system was born.
No-one would wish to roll back the GUI programming revolution. Equally, large organizations cannot rely entirely on a portfolio of short-lived tactical solutions to local user problems. The need to revisit the balance of tactical and strategic is apparent. A real RAD environment delivers rapid, responsive developers, but it equips them with the ability to share and to reuse:
and a framework for:
In developing Designer/2000, Oracle sought to build just such an environment.
In essence all approaches to software development have only two stages - thinking about it, and doing it. `Thinking about it' may be formalized as Strategic Analysis, Systems Analysis, Architectural Design, Technical Design or whatever. `Doing it' may be described as Coding, Documenting, Testing and so on. There are as many variants of this life-cycle as there are systems development methodologists, and there has never been a shortage of them. What differentiates RAD from many of the earlier life-cycle definitions is the recognition that you cannot complete the `thinking about it' and then commence the `doing it'. There has to be iteration, based on feedback. This is an acknowledgement that no matter how good we are at analyzing the needs of the business, no matter how good we are at transforming our understanding of those needs into designs and no matter how good we are at implementing those designs, mistakes will creep in. We cannot eliminate all mistakes by rigorous analysis, there is still human error and the more effort we expend on trying to do remove it the more fruitless time we consume.
Let us rather shorten the cycle from gathering requirements to delivering to the business. Let us use prototyping. Initial prototypes will not be working systems, they could be little more than mocked-up screen lay-outs, but they will present our understanding back to the users in terms they can respond to. We can make our mistakes much earlier and correct them much more easily.
This is the essential RAD scenario. User and developer working together, communicating the needs, not in formal terms but in user terms, and focusing on getting the right system as soon as possible. It is a scenario in which the GUI builder becomes very attractive, but productive tools and the use of prototyping are not enough. As we have seen, simple one-on-one development from prototypes can lead to instant legacy. To avoid this we need a more sophisticated RAD toolset.
RAD is not, in principle, dependent on tool support, but the essential requirement of RAD, and there is a clue in the title, is rapidity. Because of this it is rare to find a RAD project without some investment in productivity tools. However, as we have seen, raw productivity is not the answer, or at least it is not the whole answer. Sustainable RAD relies on control and rapidity together. So the essential characteristics of a RAD toolset are more complex.
The most important element of a team-based RAD toolset must be a repository. A repository serves two purposes; it promotes two of the aims of team-based RAD.
Firstly it provides a basis for reuse. Reuse is vital for consistency and maintainability, and also for its contribution to productivity. The key to successful reuse is finding the appropriate component to reuse. Effective reuse without a repository is about as likely as a successful library without a catalogue.
Secondly it serves as management information for development managers and for systems maintenance managers. Source code is no basis for effective impact analysis and only partially fulfils the needs of developers maintaining and enhancing production systems.
The Designer/2000 repository manages all the objects used in modelling and generating client and server. The repository management tools present this structure to managers either in overview or in detail. For example a matrix of all the screens in a system and the database tables they access. The Repository Object Navigator provides a more detail form. For example from all modules to the customer module to the list of tables that the module uses to the customer table to the columns of the customer table it uses, and so on, as illustrated below in .
Figure : The Repository Object Navigator
Not all RAD projects start from a business level model but many do. For those that do, Designer/2000 supports the two business modelling approaches most widely used in commercial systems development: Entity Relationship models and Business Process models.
In RAD projects there is an increased emphasis on user communication and user involvement. Traditional development, usually based on entity relationship models, has often been too technology-centric and not user-centric enough. Whilst the data model is vital to understand overall information needs and to design a database to support those needs, the empirical fact is that users talk about what they do not what information they use. Process modelling presents a much more user-friendly business model. This does not mean that data modelling is no longer important, but it puts it in a process context. Because of this Designer/2000 has introduced Process Modeller which further emphasises the importance of user-involvement by its extensive use of multi-media annotation and iconic representation. This produces much more accessible pictures of the world, pictures that encourage user participation and talk the users' language, rather than the latest techno-babble. Modelling this way is faster, because users participate more freely, and more accurate, because users can understand what is represented and correct it where it is wrong. In the example below in it is easy for the user to grasp what is represented and correct that representation where it is inaccurate.
Figure : User Accessible Process Modelling
Designer/2000 transforms its business models, process and data, into equivalent system specifications. The entity relationship model becomes a database schema. The process model becomes an application architecture and program module definitions.
However, in `rapid response' projects, the starting point is the database schema and the application architecture. Hence the Designer/2000 tools for database and application design can be seeded by transformed business models or can be used to create designs directly. Once again there is the balance between data and process. Once again the Designer/2000 toolset seeks to support user-centric development and provides a program design tool (the Module Data Diagrammer MDD) which represents the program design in a form which is more understandable by users.
Experience has, for a long time, shown that users do not feel comfortable with program specifications. They want to see what the result will be, so MDD presents program designs in a concise but understandable form. The example in shows a program that will run in two windows (the double lined outer boxes). The first window will display information about customers. The second will display information about their trades, including information about the company whose stock is traded.
Figure : Abstract Design Modelling with the MDD
When a developer uses the MDD to define a module, she does so by simply identifying:
For each table included, a module inherits the definition of normal screen-based behaviour for the table and included columns. This means that developers do not have to re-specify common business rules nor the appearance and behaviour of screen items. For example an address may be stored as 120 characters of text, but normally displayed as 4 lines of 20 characters in a scrolling text box. This requirement can be specified as part of the data definition and inherited whenever address is used. The module structure is defaulted from the foreign key structures defined in the data schema. In fact to create a new module ready for prototyping the developer need only identify the data to be used and how it is to be used.
This format is easy to build, easy to describe and easy to comprehend, but it is at a higher level than say a screen layout or working code. It is an abstraction. There are two advantages to using this abstracted model. Firstly by leaving out some of the detail (such as the layout of individual fields) we can see the overall structure more clearly. Once the structure is agreed, the next stage will be to generate a layout and look at the detail. Secondly, and arguably more importantly, by abstracting detail we have a model that is largely independent of implementation language. For example when the user requests a hard copy version of a screen, no problem: copy the program module definition, and generate it as a report. When she requests a query only version for direct use by customers, once again, copy the definition, flip a switch for read-only and generate again. The program module definition the design is reusable. The only changes that need be made are to add refinements specific to the implementation language.
This style of development is very responsive to user needs, but because the definitions are repository-based, the documentation is done automatically, in a sense all you have is the documentation the Designer/2000 generators can recreate the code any time.
The previous section discussed applications definition and only briefly referred to data design. A shared database schema defined in the repository is a benefit in itself, ensuring consistency in the separately developed components. For example, one developer may be responsible for defining the customer data, in conjunction with a user representative from Marketing. Another developer needs to use that information for Order Entry. A single database definition, will ensure that these separately developed components will interoperate successfully.
Although users are more interested in what the system does than what data it uses, developers can eliminate expensive mistakes if they can communicate the underlying database structure to the users. This is particularly important if the data is to be used by different users in different ways, which is true of about 90% of corporate data. Designer/2000's Data Diagrammer and Module Logic Navigator model the data-structures and data rules, presenting different interfaces for different uses, hiding or displaying levels of detail and using informal and formal rule languages.
below shows a database schema part highlighted for review by a user concerned with that specific part of the data.
Figure : Database Schema Definition
The need for developers to focus on the needs of their users is balanced by the need to avoid costly reworking at integration testing time. A repository-based database model delivers this, even though two developers may each have their own test database and test data based on the shared schema definition.
Of course the traditional tension between productivity and maintainability makes itself felt here as well. Developers do not want to be constantly consulting and updating schema definition documentation for no immediate benefit. The IDIL documentation methodology is quickly adopted (I'll Do It Later), and in a RAD project the temptation is particularly strong to ignore the rest of the team in the interests of short-term personal progress, if indeed developers are aware of the needs of the rest of the team. The repository alleviates the problem, but only represents the `stick' part of the equation. The `carrot' is provided by the Designer/2000 server generators.
In RAD projects the requirements evolve as they emerge, so the implementations constantly change.
For example a management query of customer details includes a list of the types of products that they buy and the relative values of their spend. The first prototype delivers the list in order of product description. The user then asks for it sorted in descending order of value. She then realises that the information would be better presented as a pie chart. This third change, from tabular format to graphical format, would normally require significant reprogramming.
It is easy to think of other examples where a small change in the requirements will result in a large change in the code, or even a change to a different target tool:
Because the Designer/2000 code generators all drive from the common application model ( above) switching from one target to another is simple. Because the application design model is at a more abstract level than code it is easier to modify.
Designer/2000 client generators are available for:
A common data schema definition is vital in a team-based RAD approach. Designer/2000's data design tools deliver that, but as we observed above, it is sometimes difficult to impel developers to maintain a common definition.
By providing a server generator that:
Designer/2000 provides productivity to database designers who then deliver the reuse and interoperability payoffs to applications developers.
RAD projects move quickly. RAD projects experience and respond to frequent change. RAD projects operate under heavy time pressure. RAD project managers are presumably masochists.
Designer/2000's data design tools support and accelerate the work of database design whilst at the same time improving the consistency of applications. The application design tools accelerate the development and evolution of prototypes. Each toolset offers productivity benefits to its users and they both offer balm to the harassed project manager.
Designer/2000 repository management tools, the Repository Object Manager RON and the Matrix Diagrammer, allow managers and others to assess the project deliverables, to investigate work in progress and to identify gaps, inconsistencies and errors. They can do this because all the models created for data and application design are accessible in a single shared repository.
below is a matrix of tables against modules, just showing insert usages. This matrix quickly highlights where we have database tables defined and no way of inserting into them.
Figure : Identifying Missing Functionality with the Matrix Diagrammer
below shows the RON. The navigator is currently focused on a list of modules, partitioned into releases. The manager can immediately identify any new modules that have perhaps been created as part of a prototyping session and allocate them to the appropriate release set. When development for the release is complete the manager can lock the set of objects in the release to avoid any last-minute destabilising bug fixes.
Figure : Managing Modules in Releases
All this management information and control is based not on separately maintained (or not maintained) documents but on the actual models created by the developers. The models are created for the productivity benefits they confer on the developers. They are exploited by managers but with no additional load on the high-pressure goal-focused RAD team.
The environment described above represents a combination of highly productive and user-responsive development allied to up-to-date documentation and control. A combination which it is difficult to imagine without repository-based development tools that can deliver:
A RAD toolkit must deliver all these, but it should be more than just a model-based programming environment. It should be capable of embracing the whole life-cycle, including Business Process Modelling, Enterprise Data Modelling and Design Recovery. Any of these may be a start point as well as the simpler Rapid Response project:
| Business Process Modelling: | A business process re-engineering exercise has identified a weakness in customer complaint tracking. We need to reorganize that function and deliver a new computer-based tracking and monitoring system |
| Enterprise Data Modelling: | A corporate information architecture has recently been implemented. We need to deliver new systems rapidly and incrementally to payback the investment. |
| Design Recovery: | A need has arisen for an integrated order fulfilment process, spanning several separate warehouses. We need to understand the existing warehouse databases in order to create a single distributed schema and implement the necessary system. |
| Rapid Response: | A competitor has offered direct internet-based access for order entry from high-value customers. We need to offer the same, and go one better by providing order tracking! |
RAD is not necessarily the only delivery mechanism for successful developers, but it is an essential part of all development strategies. Designer/2000 attempts to mature RAD from a high risk, high anxiety strategy or a small scale, low expectations tactic. Designer/2000 takes the rapid responsive programming of GUI builders and merges it with business-driven and repository-managed team development. Productivity without anarchy, control without bureaucracy.
[1] for example Visual Basic(tm), Powerbuilder(tm), Oracle Forms
[2] Finkelstein, C. (1989). An Introduction to Information Engineering, Addison Wesley: Sydney
[3] Homer's `The Odyssey'