http://www.microsoft.com/TechNet/dbdev/foxpro/technote/cls100a.htm (PC Press Internet CD, 03/1996)
| Updated: March 13,1996 |  Go To TechNet Home Page |
This document is reprinted from the Microsoft DevCon 95 Speaker materials and is provided "as-is." Slides are not included due to space limitations. Demos, if included, are not necessarily fully-functional samples. This document and any associated demo files were created using a beta version of Visual FoxPro 3.0. There may be differences between the beta version used to create these materials and the release version of Visual FoxPro 3.0.
Introduction
Business Process Reengineering
Client-Server
Visual FoxPro and Client-Server
Client-Server-A Server Application
Conclusion
Over the past few years, businesses have seen two major revolutions taking place: the quality and reengineering movements, and the rise of client-server databases. This session will discuss how the two revolutions have fed off of one another, and will discuss why Visual FoxPro 3.0's object orientation, database connectivity and front end tools make it an excellent platform for the critical applications that these changes engender. This session will show how a three layer model of application development will allow you to properly scale applications as a company grows and as the business environment changes.
Over the past decade, the business world has been disrupted. Competition is no longer the company down the street but the company an ocean away. Customers are more sophisticated and began to expect products that work right every time and for a long time. With advances in information technology, customers also expect that we will respond faster than ever before to their concerns, suggestions and requests. Finally, our own colleagues value professional growth as much as any other aspect in their job.
Our "standard" business structures do not support this new world. Spreading tasks throughout an organization through a large "organizational chart" means that we can't react quickly enough as input bubbles up and down large management structures. It also limits the professional growth and skills of our professionals. Organizations aren't set up to focus on the customer; they are set up to focus on a task. We aren't able to plan particularly well because nobody has control of enough of the pieces of a problem, and we certainly can't be creative in problem solving.
Enter Business Process Reengineering. BPR is defined as "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvement in critical, contemporary measures of performance such as cost, quality, service and speed." Put simply, it is a change in the way we approach evaluating what needs to be reviewed. We no longer look at business tasks but at business processes. Processes are a collection of activities that takes one or more kinds of inputs and creates an output that is of value to the customer.
As a simple example, you no longer have a person that simply screws one bolt onto an engine. You have an engine team, which is given the latitude to put together the entire engine in the most efficient way that they deem possible. They can ensure that quality is built into the engine. It is very hard to ensure that quality is built into a bolt of an engine.
Technology has helped to drive this radical redefinition of business. In order to empower these teams, we must make sure that the information that they require is available to them when they need it. If a team that builds machinery can see the upcoming week's orders, they can reset the schedule to create similar machines in a larger batch, rather than simply filling orders in a first in/first out manner. With this power, they can actually produce more machines in a shorter span of time, since they have saved the set up work.
American business has become a more nomadic place. "You have to be where your customers are" is a common refrain. Salespeople are going out of the office, laptops in hand, and placing orders on the spot. Software consultants are using Rapid Prototyping to create samples of applications in client offices. This nomadic lifestyle, in concert with an effort to reduce IS costs, has helped to push the client-server market to the forefront.
According to its proponents, this type of application will:
reduce network overhead
enhance security of user access
enhance data reliability
run faster
In actuality, the truth isn't so simple. Query optimizers like Rushmore and engine enhancements have been made to products like Visual FoxPro which drastically lower network overhead, the new Database Container has added stored procedures and triggers to the DBF format, improving its data reliability, and Visual FoxPro has been shown to be faster than various client-server DBMS's at various querying operations.
The truth also shows that on the average, less network overhead will take place when using a client-server back end like Microsoft SQL Server, although it is at a cost of putting more work on one process. Therefore, in many cases involving remote access, a back end like Microsoft SQL Server does make sense, but it doesn't necessarily make sense in every setting.
Business is a constantly changing being. The hardware platforms of today may not be the hardware platforms of tomorrow. The business that we're in today may be very different from the business we were in yesterday and it may be different from tomorrow's business. What we require is an application development approach that allows us to change front ends, back ends, and most importantly, business rule enforcement, whenever we need to.
What does this require? Let's take a look at this issue from all three angles:
To properly do front end development, we need a prototyping tool that can lead to our finished front-end. It should preferably be cross-platform so that we can leverage other hardware and software platforms. Finally, it should be extensible so that we can enhance it ourselves to provide front ends that our users expect.
This portion of our application requires that we have a language syntax that is geared towards solving business problems and that is fairly straightforward and "English-like", if you will. The capability of quickly understanding and modifying a rule is the most important need for this portion of an application. It is necessary that every front end use this layer in order to enforce the rules, so it would be nice if the rules could be automatically accessed instead of the back end data. Failing that capability, storing the business rules with the back end data is the next best option.
The database administration portion must have the capability of enforcing its own rules with the data. To this end, the capability of triggering a stored procedure is a must. For instance, it may be necessary to automatically create a summary view of an invoice as it is added (for use in a decision support database). This is a database rule, and has nothing to do with the business as such. It is simply used for database throughput enhancements.
Client-Server is a means of separating the three main portions of a business application: Front End (GUI), Business Rules and Back End (Database); so that the three can run on a combination of platforms as is dictated by the business requirements. It can run on one machine, based on one product, or run on three, based on various development languages. All are client-server. The main differentiator is the capability of rapidly scaling and changing the application as the business requires it.
Visual FoxPro makes a fairly ideal client-server development environment from this perspective. Its object orientation and visual development environment allow us to quickly create a customized front end for the client, the Xbase language syntax is English-like and has been one of the overwhelming business definition languages in use over the past ten years, and the addition of the database container with its stored procedures and triggers have made it a wonderful back end environment as well. Finally, the upsizing wizard allows one to quickly move much of an application to another back end, as is called for in our model.
The one piece that isn't native to Visual FoxPro (and indeed, is only beginning to be available at all) is the separate definition and implementation of a business rule layer. For now, we must use the native stored procedures in the database container, and store the name of a business rule, its description and its associated stored procedure in our analysis documentation which should be kept up to date.
ABC Groceries is a single grocery store that installs a point of sale and decision support system based on our model. All three levels of our solution are initially installed using Visual FoxPro. The front end is prototyped and delivered using the visual development tools, the business rules are kept as stored procedures (and are documented in the analysis) and the database container is used to give the database long field names and maintain referential integrity. Data access is done through local views defined in the database container.
As the store prospers, a decision is made to move the back office and management staff to another location and open two more stores across town. These stores install the same application as the first, which has been modified to include some database rules that automatically put summaries of every transaction in a file as they are added. This summary is sent nightly to the back office location where it is used for decision support.
Joan, the manager of Store #2 decides that she wants to offer a new service: home delivery. She begins to offer this service and subclasses the data entry form to allow the addition of the customer address. Her store prospers.
Fred, the manager of Store #3 decides to offer the same service, but requires that his clerks capture the local subway stop as well (he is in a more urban part of town). Joan's form is subclassed and used by Store #3.
As more stores are opened, the back office decides that they need to track people's credit better (a local con artist has been passing bad checks at different stores). They install a SQL Server application that contains the name of anyone that has passed a bad check. The local stores database containers have the credit check validation modified to send the check writer's name to the main office and approves the purchase if no rows are returned.
What can we learn from this simple example?
Each local store has been given the freedom to capture the information that they need to serve their customers better. One can capture addresses, the other subway stops. The main office doesn't care-they've given their locations the authority to be the best grocery stores in their neighborhood-whatever it takes.
The back office gets the information that they require. They don't need to know that Mr. Johnson buys a dozen eggs every Wednesday (though the local stores may). They do want to know how many eggs are purchased daily so that they can do their calculation. By standardizing on what is sent to them by each store, they have the information that they need.
FoxPro and SQL Server are used in concert to get the information that is required to the store, quickly and efficiently. Since credit information is the only current requirement for a centralized system, that is when the information is requested. If the main location decides at a later date that they want all of the employee's Ids in their location for validation before entry into the application, that can be easily added.
As we can see, Visual FoxPro's Object Orientation, in concert with its native client-server capabilities allow for a powerful business solution to be crafted. If one store grows and decides that they need a wireless capability, or wants to allow "shoppers" to go to client homes and do the ordering for them, they may scale up to a store-wide SQL Server solution without having to change their actual code base.
I hope that this session has helped to explain how client-server application development and Business Process Reengineering are really two sides of the same coin and why Visual FoxPro 3.0's object orientation, database connectivity and front end tools make it an excellent platform for the critical applications that will be created in the next decade. If you have any questions, feel free to contact me via CompuServe at 71541,3150, or at my office at 201-489-2500.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |