Understanding Enterprise Application Design

As mentioned earlier, the application design step is essential to the success of the application's development. This step requires creating a high-level framework, which includes determining what components will be bought vs. built, creating a database schema, and creating a component-level design.

Understanding Multitier Architectures

The most common enterprise application design revolves around a multitier architecture. A multitier architecture distributes core functionality across different servers to maximize overall application performance. The four major components of any application include presentation, workflow, business logic, and data access. The presentation layer captures user input and displays the functional output. The workflow layer typically manages the flow of execution from one block of code to another. The business logic implements specific functionality that acts upon input data. The data access keeps user input persistent by reading from and writing to a database.

As Figure 1-3 illustrates, classical desktop applications typically package all four application layers into a single binary file, the .exe file. A two-tier application separates the data access layer to a different process. This allows for greater scalability because you can introduce an additional server to offload work. A three-tier application separates the business logic layer, as well as the data access layer, to different processes. And in an n- tier application, all major application layers are separated into their own processes for the greatest scalability.

Figure 1-3: Multitier architectures distribute work to different servers.

Determining Buy vs. Build

Most developers would enjoy the opportunity to develop an enterprise application completely from the ground up. However, this may not be very cost effective. It terms of dollars, it is likely to cost more in developing and testing than to purchase a third-party solution. In many cases, such as database services, process automation, messaging, and directory services, the decision to leverage existing software solutions should be easy.

Licensing Microsoft solutions such as SQL Server, BizTalk Server, MSMQ, and Active Directory can be more cost effective than building equivalent systems from scratch. However, other solutions, such as document management, are not as obvious because you can develop a lightweight version relatively quickly. Figure 1-4 illustrates an enterprise architecture with the purchased technologies shaded. The blocks that are not shaded need to be developed internally. You need to investigate early on and decide whether to buy or build specific application components. This includes evaluating the effort required to integrate the component as well as the features it supports.

Figure 1-4: Architectural diagram with the purchased components shaded

Defining the User Interface

The user interface definition is an important starting point in the application design process and results in the creation of the user interface definition document. Two levels of detail make up this document: the user interface mockup and the user interface details.

The user interface mockup can vary from hand-drawn representations of Windows forms and Web pages to screen captures of a semifunctional prototype. Its primary purpose is to represent how the finished application will look and broadly define what functions the application will perform.

The user interface details provide the next level of technical information. This specifies exactly what user controls will be displayed within each Windows form or Web page. This specification also includes additional details for each control, such as what events each control responds to and what business functionality is executed. Finally, the specification indicates data formatting and data validation. Data formatting outlines how a label or textbox should represent data, such as percentages vs. currency. Data validation outlines the acceptable ranges for textbox controls, such as restricting letters from a number entry field.

Creating a Database Schema

The database schema is one of the most important elements of the enterprise application design. The difference between a good schema and a bad one can determine the scalability and performance of the application. It is important to structure the schema for extensibility because new features will certainly work their way into the product. However, abstracting data into too many tables will result in poor performance because all the tables will then need to be joined. Figure 1-5 illustrates the IssueTracker data schema.

Figure 1-5: The IssueTracker database schema

The person responsible for the schema design needs to understand what the application does and how it will access the data. This includes knowing which tables will be accessed most and how often data will be accessed. During development, the schema designer will also be responsible for creating primary keys, indexes, and stored procedures. There will always be minor changes to the database schema; however, you should complete the overall schema design before the component-level design begins.

Creating the Component-Level Design

The component-level design is where most of the real design time goes. Starting with the high-level architecture, you need to expand each block into detailed class definitions. Each class definition will have private and public data as well as private and public methods . Implementing the principles of object-oriented design will improve overall reusability and extensibility.