Recognizing Application Design Constraints


Each architectural approach discussed in this chapter and detailed in the book has its pros and conslike everything else. Of course, if you consider that your situation might need several applications to meet your needs or a customer's needs, you might have to choose a combination of several approaches. Just keep in mind that not all of these architectures work well togetherif at all. Each of these architectural alternatives deals with security, connectivity, data retrieval, data persistence, user interaction, and many other factors in different ways. Some architectures (like Web Services) have no user interface (UI) component at all. Some permit you to manage server connection state, and others suggest a "stateless" approach that permits a more scalable architecture. Being stateless can mean that you live on a ship sitting offshore because the feds are looking for you, or it can mean that your application does not maintain variables or data structures between invocations of your code. In this case, each time your stateless application is invoked is just like the first time. Sure, there are very few purely stateless applications. Depending on the architecture and what you implement, an application manages its state primarily on the server, on the client, or somewhere in between. In any case, when there's less state to manage, there's more time and resources to support more users. As these architectures are discussed and contrasted in the following chapters, I'll try to show the types of applications each architecture is best suited to handle.

Before you choose one architecture over another based on its scalability or performance characteristics, consider that the vast majority of data application implementations don't have to scale past a few dozen (20100) users. This means the techniques you use don't necessarily have to be that sophisticated or complex. Remember that scalable architectures are usually slower and less interactive, but more clients can be supported.


As you tour this chapter, I'll discuss common application design mistakes, inconsistencies, and outright blunders. Sure, some are more serious than others. For example, we've all seen developers build systems to fetch data from a DBMS Server, process it, and return it to the same DBMS Server. These folks often overlook the fact that it usually makes more sense to process the data directly on the server using a server-side procedure. This approach eliminates one of the most common performance bottlenecks: "round-trips" to and from the server as the data is streamed to and fromoving (too much) data to the client (and back). Sure, there are cases where it's hard to write a server-side procedure to perform some calculations (especially if you're not comfortable with T-SQL programming), but it might be possible to create a CLR server-side procedure to do the work more efficiently in a programming language you understand. I devote Chapters 14, "Creating and Managing Reports," and 15, "Summary and Wintry: Where We Are Now," to writing, testing, and deploying CLR-based executables.

What Makes "Good," "Better," and "Best" Designs?

What factors should be used to determine which architecture is better than another? Frankly, there are a virtually unlimited number of factors to deal with in the decision-making process. The key to success is discovering the critical factors that apply to your specific situation as you formalize your design (not as you implement it), while at the same time filtering out the factors that don't really impact the final productthe "noise." For example, if you build your design around MSDE (the "free" version of SQL Server 2000) or SQL Express (the "free" version of SQL Server 2005), your design will fail if the customer subsequently decides to store 10GB of Word documents and pictures in the databasethese free versions limit the database size to 2 or 4GB. As I've said, you also have to strike a careful balance with the constraints, such as what the customer wants (or thinks they want), the budget, the schedule, and other limited system resources, such as RAM, disk space, CPU, and LAN/WAN capacity.

IMHO

All too often, customers and managers don't know what they want until they don't get it.


Remember, one of the most important factors in a successful implementation is the human element. What skills are in place at the customer site and in your company to implement the design? Does the site have "real" developers or is it overflowing with "paradevelopers" who are not trained in computer science or the languages and tools needed to get the job done? Does your company have what it takes to get the job done? What about the end-usersthe people who will actually use the end-product application? Who are they? Are they random people out on the Internet or company employees? Do these folks need additional training to use your application or computers in general? If so, is this training written into the specification (and contract) or provided online in real time? Who is supposed to write and deliver this training? Will the end-user have sufficient rights to access to the LAN? Why design a connected application if the customer won't have access? Why develop a Windows Forms application if the customer's desktops are Mac-based or they're still running CP/M and 8-bit Challenge 2000 systems?

Let's go over a few goals that can help focus our search for the best architecture for your project. These approaches are designed from the beginning to:

  • Solve the customer's problem today and not be a source of additional problems tomorrow.

  • Make and keep the customer productive and competitive and out of your haireven while you're building a solution to their problems.

  • Be scalable within reasonable growth expectations. Not all applications need to support 10,000 (or even 1,000) users.

  • Build applications that perform quickly and efficiently enough to deal with the expected load, given expected growth.

  • Log and handle exceptions with the least amount of customer interaction or disruption.

  • Build applications that are implemented and maintained by the customer's development and support teams without constant need for outside experts to constantly tune, patch, maintain, and troubleshoot the systems.

  • Use development standards that don't require special training so that replacement developers can easily work with the existing code.

  • Function within the constraints of the customer's resourcesnot requiring the expense of additional systems, staff, or software licenses.

  • Integrate seamlessly with existing systemsor at least tolerate their existence.

  • Document the entire application and its support systems, including end-user instructions, as well as build, maintenance, deployment, and configuration instructions.

  • Incorporate security systems that "sufficiently" protect the customer's data and comply with all government regulationseven the ones you don't know about (yet).

  • Deal seamlessly with backup and disaster recovery issues.

  • Produce a workable solution on time, within budget, that includes rolling progress reports.

IMHO

In today's uncertain times, we all need to be building redundant and carefully protected systems.


What I'm suggesting here is an architecture and design with which both you and your company can be satisfied and where a developer can walk away in good conscience when the contract is done. That is, the customer is happy and secure with the implementation and doesn't need to call you on Saturday afternoon just as you push off from the dock for a cruiseeven when there is a crisis and it's not a design where you feel that you need to leave the country to avoid prosecution.

I cannot overemphasize the importance of adequate securitysecurity that's built into a system, not tacked on like plywood duct-taped to the sides of a Humvee. Because of more stringent government regulations and threats of prosecution (and because it's the right thing to do), most of us strive to design systems that don't make it easy for hackers, "evil-doers," Veteran's Administration employees, or anyone else who would compromise the data our applications are designed to store and protect. I (generally) never know what my customers store in their databasessometimes I don't want to know (or I should not know). I do know that the data should not be exposed to just anyone without the appropriate rights and credentials. For example, in the U.S., if your application deals with healthcare information (patient data), you're going to have to comply with HIPPA (a.k.a. HIPA) regulations. In other countries, there are similar, if not more stringent, security requirements. It's beyond the scope of this book to describe these laws and how to show you how to make sure your code complies with these laws. In any case, your application must be built around a DBMS engine capable of implementing these fairly rigid security requirements. This is another reason I can't recommend JET/Access databases for professional implementations where security is a factorit simply can't be adequately protected. While single-user JET databases can be protected (to some extent) by Access/JET security and the file system ACLs, these are not that hard to crackno, I'm not going to tell you how.

IMHO

I don't recommend JET/Access databases for any professional implementation where security is a factorit simply can't be adequately protected.


Designing Before Implementing

Ideally, when I sign a consulting or mentoring contract, I stipulate what's expected of the customer and what they expect of me. I also like to work up a pre-written specificationa detailed description of the application to be built. It's like the blueprints for a house that includes everything from a detailed drawing of the finished house to the electrical, plumbing, foundation, ventilation, and other detailsright down to the color of the carpet and the kind of toilet fixtures. Some customers know exactly what they want you to do and can provide detailed instructions. Unfortunately, we all have worked with customers that don't know what they want until they don't get it. All too often, customer demands are fairly vague. "Make it better" or "Make it faster, cooler, more competitive, easier to use; do it in the next two days; and be sure to use XML" are typical demands. This means that it's our job as consultants, developers, and mentors to help the customer take this first (big) step and figure out what he or she really wants, what the company wants, and what resources are available to make it all happen or constrain what can ultimately be done.

It's the systems architect's job to create this specification and do so with the customer so both parties know what's to be built. Detailed specifications make it easier to estimate how long the project should take and (more importantly) know when you're done. It's only by experience that consultants and developers learn how long a project will/should take. If the customer comes in halfway through the project (or a week before it's supposed to be done) and asks for something new, it's also easier to say, "Sure, but that's not in the specification, so it will take N more hours/days/weeks/months to make that change and it will cost X bucks more. Is that in the budget?" If the project specification is written as you do the project, it's not a specit's documentation. Yes, of course, this is an idealistic assessment of how things work, but if you're not prepared for this (very typical) eventuality, you won't be in a position to do anything but bend over and take it.

IMHO

If the project specification is written as you do the project, it's not a specit's documentation.


A specification is the end-result of the design phase, which (in my opinion) is far more important than the coding or implementation phases. Lack of an adequate design is the cause for many a project to fail, run over budget, or be unable to sustain the live production workload. Was it inadequate design and testing that caused the Boston tunnels to fall apart? I expect so. The project specification should be written before or as you build proof-of-concept routines that implement and test application components that have not been tried before. How many of you have seen production applications deployed from the prototype proof-of-concept code? Many of us are guilty of this blunder. Building a prototype is akin to testing a new type of siding or roof for a new home under actual weather conditions before committing your customer to something that might melt after the first hail storm. Two weeks after you go to production is not the time to discover that the chosen architecture does not have the needed performance for a scaled-up production application. Sure, as you gain experience, you'll know what parts and techniques you can depend on to perform when the load increases.

Tip

Be careful. Don't let your customer take the proof-of-concept application and take it into production thinking the prototype (held together with wax and chewing gum) is the real thing.





Hitchhiker's Guide to Visual Studio and SQL Server(c) Best Practice Architectures and Examples
Hitchhikers Guide to Visual Studio and SQL Server: Best Practice Architectures and Examples, 7th Edition (Microsoft Windows Server System Series)
ISBN: 0321243625
EAN: 2147483647
Year: 2006
Pages: 227

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net