The Development Process

I l @ ve RuBoard

As I've mentioned, developing enterprise applications requires a balancing act between many functional and cross-organizational requirements. You must approach the design from four perspectives ”business, application, information, and technology ”in order to create a cohesive design that can adapt and grow to meet the needs of the business over time.

Figure 1-1 provides an overview of this process. The diagram is an abstraction of what, in practice, should be an organic and fluid process with natural feedback mechanisms that closely interrelate each phase of the process. Communication across all of the development phases will help ensure the success of the project.

Figure 1-1. An overview of the enterprise application development process.

Let's take a closer look at each stage in the process.

Collecting Requirements

Developing a set of requirements at the outset is crucial to developing a successful product. This list of requirements will help you prioritize and drive the infrastructure development and the application development simultaneously (with the goal that they'll meet somewhere at the end of the process). The requirements fall into four main categories:

• Customer requirements

• Infrastructure and availability requirements

• Performance requirements

• Deployment requirements

I'll deal with each of these points in turn .

Customer Requirements

Ask yourself these questions. How will your customer use your application? What are the common user scenarios that you need to satisfy , at a bare minimum? Spelling these out at the start will not only help you keep better track of the progress of development, but it will also help you ensure that you're spending your time on the important parts of the product rather than on features that have minimal use.

Infrastructure and Availability Requirements

If you're creating a client-server type application, what resources do you have at your disposal? By resources, I mean both workforce and hardware. Certainly, the scope of your application will influence your workforce requirements, but the converse is also true: your available workforce will influence what development is possible to meet your market window. Also, you need to consider what support your application will need once it is deployed.

On the hardware side, you should evaluate your user scenarios. How will customers use your system? Given finite resources, how will you distribute the application load? And given the client requirements, what flexibility do you have to locate execution code elsewhere? Can you implement caching to reduce server loads? All of this and more has to go into your thinking.

Performance Requirements

No one wants an application that is slow, but user expectations can have as much to do with responsiveness as with speed. When you're dealing with a large amount of data, an operation might take a long time to complete, but you should always give the user the impression that, no matter what, your application is doing something. This is, in part, an issue of user interface responsiveness. On the other hand, some operations simply cannot take a long time to complete. Recall the mapping company example. Taking too long to perform a common and frequent operation is clearly unacceptable. You must therefore set your expectations up front so it is clear where you and your team should focus your effort on performance optimizations.

Deployment Requirements

Can you expect the customer to perform installations or maintenance? What system requirements can you rely on? Do you need network or Internet connections? If so, what bandwidth can you expect? From a deployment perspective, you should profile your potential customers. Will they likely be corporate users with an IT support infrastructure and a T1 Internet connection, or will they likely be retirees with machines that have only a 56K modem that was set up by a relative? What support are you prepared to provide? These are all important considerations.

Design and Architecture

Using the requirements you've developed, you can begin architecting a system. A lot of effort will go into this phase (or should, anyway). Skimping on the design and architecture will cause huge problems on larger projects. (Goodness knows , we all can and do get away with it frequently on smaller projects.) Ideally, you should spend the time needed to develop quality system specifications that define how your application will look, behave, and perform. Using this information, you can start modeling the system, looking for design flaws before they can affect the schedule. Of course, there's also the ultimate goal of development: extensibility. Implementing an architecture that will grow with your business requirements is a nontrivial task, but it's better to deal with it at this point so you don't have to scramble to apply a messy set of patchwork fixes at some later stage.

Your architecture should take into account the following three technological considerations:

• The user interface

• The component architecture (Of course we're using .NET, but how can you structure your application into components in a logical way?)

• The network architecture

The User Interface

I've discussed some considerations for for determining a client architecture. What does this usually translate into? Four main options are available for client applications, as described in the following sections.

Option 1: client only

In a client-only application, also known as a single- tier application , all of the application resides in one place. The vast majority of applications, even in this day and age, fall into this category. There are no distributed components to the application, unless you count possible Internet-based application updates. Granted, this category is gradually shrinking, but I am fairly sure that it will never go away. Productivity, utility, and graphics applications, as well as games , are typical examples of client-only applications.

Option 2: thin client

The most common example of a thin client is an application that uses a Web browser. Aside from minimal scripting logic, the application's logic and execution are handled on the server side. This involves minimal download time for the client; graphics and page layout constitute the majority of the download time. In this way, you can minimize your client requirements and take advantage of the widely installed base of Web browsers. The advantages here are obvious. Changes need to be made only on the server side, you have far more control over changes to the system, and you can reduce the number of things your users can do to mess things up. In addition, you produce a client that is loosely coupled to the underlying implementation. A Web browser doesn't care whether the server is IIS or even Apache, as long as it talks HTTP and serves up HTML.

Option 3: fat client

The fat client definitely falls on the larger side of the client-server application category. Typically, a fat client application is something like a Windows Forms “based application. All of the user interface and possibly some or all of the business logic is contained in the client application. The client might even do some direct data access. The server has to deal only with some of the business logic and most of the data access. You can typically think of a fat client as being more tightly coupled to the underlying system and more sensitive to changes.

Option 4: mixed client

The mixed client falls somewhere between a thin and a fat client in a client-server application. You can think of it as a Web application that contains user controls. Essentially, the appearance and function of the client is generated by both the client and server. You can use a mixed client application as a way to provide greater user interaction without the overhead of a fat client, but the mixed client application does incur more client-side overhead than a simple thin client.

The Component Architecture

With larger applications, it's important to divide the application into components and subsystems, usually based on functional areas. Visual Basic .NET also has the added ability to build up a hierarchy of classes through the use of namespaces. Namespaces are an integral part of the .NET Framework. Using namespaces in your projects to place your classes into some sort of logical hierarchy can provide more information to developers about the purpose of each and every class you create. Namespaces can also provide some direction on how your components and classes should be used.

More Info

Chapter 2 deals with namespaces and how to organize your application into specific areas that can make larger class libraries much easier to understand.

The Network Architecture

By dividing your application into components along functional-specific lines, you can simplify the task of splitting it into distinct functional tiers. Why? It's all about performance and scalability. A multitier system enables separation of components in a way that enables distribution of processing resources. Imagine a situation in which you have a Web service that is performing poorly. You might determine that the client load is too much for a single machine but that your database is hardly being used. In this scenario, with a multitiered application architecture, you can move the database to another machine and put additional systems in place to handle the incoming client requests .

Leveraging an existing component architecture makes separation of the application into distinct tiers much more feasible . This enables companies to focus financial resources on the parts of the system that would benefit from hardware upgrades. It is often good practice to design your application with a tier structure in mind. Even if all of the "tiers" are resident on the same machine, they can be easily moved elsewhere to improve performance or add capacity at a later date.

More Info

Chapter 9 describes in greater detail the benefits of tiered application architectures and what the technology and infrastructure considerations are.

Implementation

Implementation can be the hardest part of the whole product cycle. As I mentioned earlier, good teamwork is essential. It is also important to have clearly defined roles and responsibilities. These don't always have to be strictly enforced, but you need to know who can make definitive decisions for any given area of the product.

During the implementation phase, you must focus on both security and reliability. These should already be part of your design and architecture, of course. Every team member should be on the lookout for potential issues and be proactive about addressing them. Remember the old saying: "A chain is only as strong as its weakest link." Even a small flaw in an otherwise robust system can bring the whole thing crashing down.Another important part of the implementation phase is working feedback into the specifications. A specification should never be treated as an immutable document. It should adapt as problems are encountered and solutions are formulated. Follow this up with good documentation and peer code reviews, and you should have a fairly robust process in place.

Testing

Testing is an often unappreciated phase of product development. For a large applications or system, you cannot just say, "The devs will test their own code." Developers, like writers, are usually poor judges of their own work. They tend to be great at unit testing, but they don't usually have time to worry about whole-system testing. Experience does help in knowing what to look for, but ultimately you need people who are dedicated to testing the whole product.

When you develop your test plan, you should first build off of functional requirements, but performance requirements should also be a primary consideration. Testing should also take into account your application's planned deployment scenarios. Your customer's perception of your product will be greatly influenced by the effort your team puts into the testing process. Fixing a bug early is far less expensive than fixing it after a product has shipped.

Deployment

Deployment ”delivering the product to the customer ”is the true test of the entire product development process. It is important to work out your product support strategy ahead of time. You must also ensure that your support team can channel feedback to the spec, development, and test people on your team so that customer experiences can be worked into the design, implementation, and test phases of future revisions.

I l @ ve RuBoard