Enterprise Application Development

I l @ ve RuBoard

The word enterprise has been overused to the point where it has lost a great deal of meaning, if it really had any to begin with. To call oneself an "enterprise developer" is almost to invite ridicule ”after all, we are all enterprise developers of some sort . So, what really distinguishes an enterprise developer from a so-called "run-of-the-mill" developer? Not a lot. Enterprise applications typically have higher stakes and thus require more skill and experience on the part of the developers involved, but the project's developer is still just a developer.

For the purposes of this book, I'll define an enterprise application as an application or system that has at least two of the following characteristics:

• It is a large application that requires team development.

• It has specific performance, scalability, and reliability requirements.

• It uses a variety of implementation technologies and/or integrates multiple platforms.

• It is an application or system that is distributed across machines, networks, or companies.

Team Development

A team environment puts unique constraints on the development process. A good organizational structure with well-defined roles and responsibilities can make the difference between a successful team and project implosion. Granted, most projects are developed in circumstances that are less than desirable, but a well-structured team environment is a good goal to strive for.

Infrastructure is also extremely important. Having a good source-control system, accurate specs , and documentation will help ensure that the whole team is on the same page.

More Info

Appendix A discusses team development in Visual Basic .NET and looks at a number of common hurdles that developers encounter.

Performance, Scalability, and Reliability

Performance, scalability, and reliability are often considered the "big three" of e-commerce applications and other large-scale systems that serve critical business functions. Attaining these three goals requires the use of technologies in very specific and purposeful ways to avoid running into problems or system failures. And these goals can often be at odds with one another. For example, an application might need to sacrifice performance in favor of better scalability and or reliability. I used to have a sign posted in my office: "Quality, speed, cost. Pick two."

Or, to state it another way: given an infinite amount of time and money, you can accomplish anything. Everything else is a compromise. This is the quandary that every developer and project manager ultimately faces. Although it is possible to strike a balance, you cannot always find an optimal solution. Reliability in a system implies additional overhead, which adversely affects performance. The trade-offs you make will depend on your application's requirements and available resources.

Performance

Performance is all about making the most efficient use of your hardware resources. In server applications, performance tuning ”leading to greater throughput and potentially less overhead ”provides a direct cost savings. It requires less server hardware to satisfy the same number of requests .

Performance also implies responsiveness to the end user . Users are not tolerant of slow applications ”slow performance can doom an Internet application. Imagine a mapping service that takes five minutes to load a map to a single address. How often would you go back?

Scalability

A scalable application or system is one that can accommodate growth. There are effectively two types of scalability: resource scalability and system scalability. Resource scalability implies that your application performance will scale reasonably well with additional processors, memory, or disk space. System scalability relies on the notion of server farms ”increasing system throughput by adding machines. In that scenario, you must ensure that your application can play well with others and make efficient use of its resources.

Reliability

Reliability can have several meanings. First, and most obviously, it can mean that an application doesn't crash (often). But in a corporate environment, data is king, so reliability also means protection against data loss, regardless of the circumstances. You might include security in this category as well. The notion of security is almost implicit in a "reliable" system. After all, think of all of the electronic cash transactions that circulate on the Internet today. You would not think of them as reliable if some sort of security were not implemented. Various security mechanisms make possible the positive identification of both the source and the recipient of the transaction.

Implementation Technologies and Integration

If there's one thing Visual Basic .NET does not lack, it's choice. Take string concatenation, for example. There are many different ways to perform something as intuitively simple as combining two strings, but your choice can have a significant effect, either positive or negative, on your application. Also, a great many other technologies lie at the heart of the Microsoft .NET Framework. Deciding which classes to use can be difficult, especially given the newness of the platform itself and most people's relative unfamiliarity with it.

With enterprise development, you also face the daunting challenge of integration. Nothing causes greater fear than having to integrate a modern Web application with a 20-year-old mainframe that talks only through an AS-400 terminal. Yet many large companies still have mainframes at the heart of their most important business functions. I won't look at integration issues in this book, unless you count COM. Plenty of other resources are dedicated to this topic.

More Info

If you're interested in what Microsoft has to offer, you might check out Microsoft Host Integration Server 2000. The book Microsoft Host Integration Server 2000 Resource Kit (Microsoft Press, 2000) is loaded with great information about this product and how to make the most of it.

The Distributed Environment

A distributed environment makes specific demands on an application and its architecture. Poorly architected systems will not yield the desired performance or responsiveness. Throw in the possibility that parts of your system might not always be immediately available, and things really start getting complicated. In those situations, dropping transactions or losing data is simply not an option. This mirrors the reliability issue, but a distributed environment presents unique challenges to system reliability.

I l @ ve RuBoard