It isn't a new idea and it isn't an approach specific to Microsoft, but the division of application code into distinct layers, each with distinct functional roles, is generally seen as a good approach. Recently, I worked on a project that gave me the opportunity to see how beneficial this approach is. The setup I was chosen to lead a project in the controlling department of a financial institution in New York City. Every month, the department heads in the bank were responsible for reconciling their individual departments' transaction ledgers to the corporate general ledger. Any discrepancies were identified, investigated, and logged. They had no standard for how to do this, and every department had developed its own methods and systems to accomplish the task. Because of these multiple methods and a lack of management oversight, many discrepancies between the systems had cropped up and hadn't been investigated. In addition, there was no accountability and no central system for the controlling department to monitor these monthly activities. The head of the controlling department wanted a system built to standardise the monthly reconciliation process. The system would provide a simple, Web-based interface that would allow each department head to view the corporate general ledger information, input the ledger entries from the department's transaction ledger, identify the differences, and investigate the missing transactions. The completed reconciliation would be recorded and the controlling department could then monitor compliance. Gathering the requirements I assembled a team and held the first requirements gathering session with the users. The problems I was going to face quickly became very apparent: None of the key department heads showed up. Apparently, the only sponsorship for this project was from controlling. The individual department heads were content going on the way they had been. I ran the meeting as best I could but the users were giving me a lot of "I see your lips moving but all I hear is blah, blah, blah." The head of controlling saw this too. His solution was to appoint a single person to be in charge of defining the functionality. Unfortunately, even though the person assigned knew a lot about accounting, he wasn't a department head and had never done a monthly reconciliation before. He also had very definite ideas about how the application should function and he wasn't taking suggestions from anyone else. The manager thought that if we wrote the perfect system, we could force the users to adopt it. I had seen too many projects fail because applications were developed without input from the key users and support from the stakeholders. This project was starting down that path. I did a quick risk assessment. The system's goal was a good one. It added value and it would make the reconciliation process more efficient. But without the users' input into defining the functionality, we were going to fall far short on the details necessary to make this system work. Whatever my team built, it was going to have to be very flexible. Once the users did get involved, there were going to be a lot of changes. We had to develop the application in such a way that we could react to the changes quickly and minimise the amount of additional development each change would entail. Defining the architecture Being able to adapt to changing requirements meant architecting the system with distinctly defined components and adhering to some strictly defined programming standards. Once we finished the system use cases defining the requirements, we started developing the object models and class diagrams using Visual Modeler. Because we were using Microsoft technologies (Active Server Pages and Visual Basic), we used the Windows DNA architecture as a framework. Our software layers would be defined this way (see Figure A):

Figure A

Data access layer At the data access layer, our approach was primarily one object per "functional object." For example, the use cases defined the concept of a general ledger account. The account had properties such as account number, associated department, account owner, and current monthly balance. We created a database table for all account description data. There was a foreign key relationship to the user table for account owner. There was also another foreign key relationship to the monthly balances table. A simplified version of these tables is diagrammed in Figure B.

Figure B

The data layer Account object (aptly named AccountDL) was responsible for database SELECT, INSERT, UPDATE, and DELETE actions. A simplified Account object looked like this:AccountDL-----------Properties:AccountNumberTitleOwnerNameDepartmentLedgerBalance Methods:AddNewAccountLoadAccount(AccountNumber, Month)DeleteAccount
There was a very close association with the information stored in the database and the information available in the AccountDL object. But the implementation of the database structure was hidden from developers by this object. This meant that any database changes that might be required in future application revisions would only require code changes to the methods of the AccountDL object. As long as the interface stayed the same, the objects of the business logic and presentation layers would be unaffected.