- What is Enterprise Software?
- Evolution of Enterprise Software
- Enterprise Software and Component-Based Software
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Evolution of Enterprise Software
Not too long ago, mainframes ruled the world, and all software was tied to this central entity. The advantages of such a centralized approach included the simplicity of dealing with a single system for all processing needs, colocation of all resources, and the like. On the disadvantage front, it meant having to deal with physical limitations of scalability, single points of failure, limited accessibility from remote locations, and so on.
Such centralized applications are commonly referred to as single tier applications. The Random House dictionary defines a tier as "one of a series of rows, rising one behind or above another." In software, a tier is primarily an abstraction and its main purpose is to help us understand the architecture associated with a specific application by breaking down the software into distinct, logical tiers. See Chapter 6 for a more detailed discussion of tiers.
From an application perspective, the single most problematic aspect of a single tier application was the intermingling of presentation, business logic, and the data itself. For instance, assume that a change was required to some aspect of the system. In a single tier application, all aspects were pretty much fused; that is, the presentation side of the software was tied to the business logic, and the business logic portion had intimate knowledge of the data structures. So any changes to one potentially had a ripple effect and meant revalidation of all aspects. Another drawback of such intermingling was the limitations it imposed on the reuse of business logic or data access capabilities.
The client-server approach alleviated some of these major issues by moving the presentation aspects and some of the business logic to a separate tier. However, from an application perspective, the business logic and presentation remained very much intermingled. As well, this two-tier approach introduced some new issues of its own, for instance, the challenge of updating application software on a large number of clients with minimal cost and disruption.
The n-tier approach attempts to achieve a better balance overall by separating the presentation logic from business logic and the business logic from the underlying data. The term n-tier (as opposed to three-tier) is representative of the fact that software is not limited to three tiers only, and can be and indeed is, organized into deeper layers to meet specific needs.
It should be noted that each tier in an n-tier does not imply a separate piece of hardware, although that is certainly possible. A tier is, above all, a separation of concerns within the software itself. The different tiers are logically distinct within the software but may physically exist on the same machine or be distributed across multiple machines.
Some examples of the types of advantages and benefits offered by n-tier computing are
Faster and potentially lower cost development: New applications can be developed faster by reusing existing, pretested business and data access components.
Impact of changes is isolated: As long as interfaces remain unchanged, changes on one tier do not affect components on another tier.
Changes are more manageable: For example, it is easier to replace one version of a business component with a new one if it is residing on a business tier (on one or a few dedicated servers) rather than having to replace hundreds or thousands of client applications around town, or around the globe.
Figure 1-2 illustrates enterprise software organized along these single, two, and n-tiers.
){kind=link}
Figure 1-2 Architectural evolution of enterprise software