Breaking it down further (Integration/Data Tier)

As mentioned in my earlier posts, the logical tiers that make up "Application Architecture" are (in my mind) the Client Tier, Application Tier, and the Integration (or Data) Tier. Some of the application architecture tiers can be further broken down into logical layers. The Integration/Data Tier generally doesn't fall into that category, so I'll just spend a little time talking about what I mean when I refer to the Data Tier (from now on, I'll generally refer to this as the "Data" tier, as that is what is most often used in business applications).

Integration/Data Tier
The Data Tier is generally responsible for managing the persistent application data. This data management typically includes:

• Storage/retrieval of data
• Managing updates to the data
• Allowing simultaneous, or concurrent access (by more than one middle-tier process)
• Providing security for, and ensuring the integrity of the data

In most business applications, these services are provided by a RDBMS. However, the Integration/Data Tier is used to refer to whatever back-end repository is being used as a persistence mechanism for the relevant application data (ERP system, image repository, web service, etc.).
Frequently (but not always), the database is separated physically onto its own tier. However, the performance of an application can suffer greatly if this physical separation from the application tier is too great. When planning the application, work with the appropriate teams (e.g., enterprise architecture, DBA, etc.) to determine the appropriate physical server location and configuration for your Data Tier - taking into account the Application Tier (which will be discussed next).