The assurance that a service/resource is always accessible. This aspect of a system is often coupled with measures of its performance.
(time available) / (time possible)
Example – 201 seconds down/week.
The ability to run a number of jobs per unit time.
The ability to economically modify or add functionality.
The ability to support architectural and hardware configuration changes.
The ability to change architecture to meet new requirements in a cost-efficient manner.
Is the key to an available, reliable, and scalable application.
Can be improved through location independence of application code:
Allows you to change what is affected by changing the presentation language (for example, English to German) ?
What must change to add a "fat client" for intense use ?
The effect of flexibility:
The ability to manage the system to ensure the continued health of a system with respect to the other capabilities.
Metric example – Number of staff hours per month to perform normal upgrades.
The ability to ensure the integrity and consistency of the application and all of its transactions.
Example – Users will experience failed sessions no more than 1 time in 1000 attempts (99.9 percent reliability).
Assume a web server has a Mean Time Between Failures (MTBF) of 100,000 hours.
What is the reliability of the following ?
The ability to execute functions fast enough to meet performance goals.
Response time is important to an application.
Identify and control expensive calls.
State performance goals before implementing.
Example — first visible response in browser under maximum specified load occurs in less than 3 seconds, 95 percent of the time. Measurement is made at company external firewall.
Identify and control access to expensive process and network boundaries:
The ability to support the required quality of service as load increases:
Vertical scalability comes from adding capacity (memory, CPUs) to existing servers.
Makes fewer demands on the architecture
Is constrained by resource limits
Horizontal scalability comes from adding servers:
Distributed state, load balancing
All Web servers or all application servers must fail for a system failure to occur
The ability to ensure that information is neither modified nor disclosed except in accordance with the security policy.
The ability to determine what the expected results should be.
Two Tier Software Architectures
Two tier architectures consist of three components distributed in two layers: client (requester of services) and server (provider of services). The three components are:
User System Interface (such as session, text input, dialog, and display management services)
Processing Management (such as process development, process enactment, process monitoring, and process resource services)
Database Management (such as data and file services)
The two tier design allocates the user system interface exclusively to the client. It places database management on the server and splits the processing management between client and server, creating two layers.
In general, the user system interface client invokes services from the database management server. In many two tier designs, most of the application portion of processing is in the client environment. The database management server usually provides the portion of the processing related to accessing data (often implemented in store procedures). Clients commonly communicate with the server through SQL statements or a call-level interface. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services.
Two tier software architectures are used extensively in non-time critical information processing where management and operations of the system are not complex. This design is used frequently in decision support systems where the transaction load is light. Two tier software architectures require minimal operator intervention. The two tier architecture works well in relatively homogeneous environments with processing rules (business rules) that do not change very often and when workgroup size is expected to be fewer than 100 users, such as in small businesses.
The most important limitation of the two-tier architecture is that it is not scalable, because each client requires its own database session. The two tier design will scale-up to service 100 users on a network. It appears that beyond this number of users, the performance capacity is exceeded. This is because the client and server exchange "keep alive" messages continuously, even when no work is being done, thereby saturating the network.
Implementing business logic in stored procedures can limit scalability because as more application logic is moved to the database management server, the need for processing power grows. Each client uses the server to execute some part of its application code, and this will ultimately reduce the number of users that can be accommodated.
The two tier architecture limits interoperability by using stored procedures to implement complex processing logic (such as managing distributed database integrity) because stored procedures are normally implemented using a commercial database management system's proprietary language. This means that to change or interoperate with more than one type of database management system, applications may need to be rewritten. Moreover, database management system's proprietary languages are generally not as capable as standard programming languages in that they do not provide a robust programming environment with testing and debugging, version control, and library management capabilities.
System administration and configuration
Two tier architectures can be difficult to administer and maintain because when applications reside on the client, every upgrade must be delivered, installed, and tested on each client. The typical lack of uniformity in the client configurations and lack of control over subsequent configuration changes increase administrative workload.
The two tiered architecture is not effective running batch programs. The client is typically tied up until the batch job finishes, even if the job executes on the server; thus, the batch job and client users are negatively affected.