Building the Business Application

In trying to bring more and more data into play, application designers typically place things closest to the user . However, as we learned in Chapter 1, if this is done without regard for storage or data infrastructures , the application can be quickly compromised once in production. The application design process (as shown in Figure 2-4) will then give way to the realities of system implementation (as shown in Figure 2-5).

Figure 2-4: The application development lifecycle

Figure 2-5: Application implementation challenges

The application designers concentrate on the business requirements and produce a requirements document. This determines what will be provided to end users at the completion of the development process. The document, once finished and signed off by management, will also be used as a basis for an external design document. This is generally comprised of an external view of end-user functions, access points, and outputs. It's possible that sources, types, and quantities of data will be factored into external design discussions. This is followed by internal design activities where the application programmers determine the logic and identify external software development components to be used in building the application system.

It is during the internal design process that application designers and programmers work with database administrators to provide a logical design for the application data. Unfortunately, in many cases the physical attributes of the database requirements remain unaddressed. These design activities are followed by an iterative process of actually building (for example, coding) the application by a team of application programmers.

As components are completed, they are tested on their own-something known as unit testing-and then integrated with other components to form a major function of the application system. These functions or combined sets of components are integrated and tested in what evolves into a larger process of system testing. As all the components come together, user testing and acceptance begins, where actual end users test the system for accuracy and functionality. The components are modified in an iterative process as functionality errors are encountered . Once the system is completely tested by a segment of end users and signed off by management, the system moves into production mode. This is where the application first encounters the storage infrastructure.

Moving into production mode is a tricky business. In large systems, other activities come into play such as user education, migrating users from older systems into new systems, and ensuring that the application's business data stays in sync from one system to the next .

However, as the new business applications progress to this point, implementation will produce some interesting challenges, especially in the absence of storage infrastructure information and planning. Now it's a matter of how the application works with an unknown server and storage infrastructure. If the storage infrastructure has not been taken into account, the window of application non-linear performance (see Chapter 1) becomes very thin and quickly results in an unresponsive application as soon as users and data are applied in production mode. (See Figure 2-6.)

Figure 2-6: The realities of application implementation

A third process in the application development cycle, albeit unplanned , is a post-implementation analysis and understanding of the real storage and data access requirements of the application system. This generally results in quickly provisioning additional resources into the storage configurations to handle the production processing. Due to the immediacy of this action, the resources are provisioned at a macro level without accounting for growth or scalability.

Obviously, the third process should be integrated into the application's development process, probably somewhere between the external and internal design activities. However, this requires two major pieces of information. First is the availability of storage solutions to offer to the application designers. Secondly, a more detailed understanding of input and output processes is needed to enhance the application's design through I/O processing and storage requirements beforehand. (More information on this can be found in Chapters 6, 7, and 8.)

It is important to note that enterprise storage infrastructures deal with multiple applications and should be seen in context of an enterprise view rather than addressed piecemeal for each application system. This becomes problematic , however, during an implementation frenzy when the new applications are being deployed online. This points out another level of difficulty: developing an effective storage strategy that works with the traditional client/server storage model. The ability to look at the requirements from a cumulative perspective, noting the data size , characteristics, and access requirements on an enterprise scale, requires storage configurations that support multiple applications in a scalable manner. The application design-development-implementation process will not change, it will only get faster and less resource-aware. Accounting for it through an enterprise storage infrastructure strategy helps, but this must be integrated with storage solutions that mediate the challenge. (This forms a whole topic outside the scope of this book. Additional information can be found later in Chapter 17.)