Application architecture is the high-level plan for building an application to solve a specific business problem. The Enterprise Application Model is an orderly summation of all the requirements for the implementation of any enterprise application, divided into six specific submodels. Table 2.3 lists the requirements as items to define or deliver within each submodel.
Figure 2.3 shows not only the categories of requirements that an enterprise application must meet, but also the relationships between the various requirements. The arrows show that successful application development begins with determining the business requirements and results in the physical architecture of the completed system. Between these two stages, the user, logical, and technology requirements are fulfilled, with each category depending on inputs from both the business requirements and its neighboring submodels, and with each model's outputs directly contributing to the physical architecture that is finally implemented. The Development Model (the teams and processes applied to developing the application) permeates and coordinates all of the other requirements.
Figure 2.3 Enterprise Application Model
Table 2.3 Submodel requirements of the Enterprise Application Model
|Business||Business goals |
Return on investment
Security and maintenance
Existing infrastructure investment
Business rules and policies
|User||User interface |
Training and documentation
User's desktop configuration and network connection
|Logical||Logical application structure |
Object and data modeling
Business objects and services
|Technology||Component development or reuse |
System and database technologies
Clustering, pooling, and messaging technologies
|Development||Development team |
Source code control
Testing Application milestones and deliverables
|Physical||Physical application architecture |
Distribution and interconnection of components
End product of the iterative inputs of each of the other submodels
The view of the Enterprise Application Model shown in Figure 2.3 immediately provides important insights into the requirements for successful enterprise application development, some of which are listed here:
These insights suggest a development process that is iterative and incremental rather than linear. Such a process involves working on each set of requirements a little bit at a time, pausing at frequent intervals to assess the impact of each model on its neighbors. It helps to identify conflicting requirements early so that necessary design tradeoffs and adjustments can be made before they require re-implemention of major portions of the application.
First and foremost, the Enterprise Application Model is a design tool. It guides application architects through the process of designing and building a large-scale application, by organizing its design requirements into submodels and showing how the submodels fit together. It shows how to balance the competing requirements of every design decision. As a result, the application can be built in small incremental steps, working in any order that seems appropriate, with the confidence that every design choice integrates smoothly with the overall application architecture.
A big advantage of using the Enterprise Application Model as a design guide is that the process can start anywhere. The context and priorities of the project, rather than an arbitrary linear order, determine the correct sequence for traversing from one submodel to another, ultimately fulfilling the requirements of all the submodels. For new projects, the preferred direction is top to bottom, with the needs of the business driving the middle submodels and the needs of the middle submodels driving the physical architecture that is finally implemented. However, good reasons may dictate starting elsewhere—for example, an existing application context that needs re-deployment, or a usability problem that must be fixed.
As the arrows in Figure 2.3 show, the requirements and output from neighboring submodels directly affect each other. These arrows are used to balance and resolve the competing requirements between the submodels while creating the application's Functional Specification.
Regardless of which submodel is worked on first, the general pattern for traversing the model during application design is:
To give a high-level view of how submodels work, the following example uses some concepts of distributed component-based architecture, such as pooling and scalability, that are not covered until later chapters. If necessary, check the definitions of these concepts in the Glossary.
Suppose that the User Model for an online sales system requires the system to accommodate a twenty-fold increase in the number of users during the holiday season compared with the rest of the year. How does this requirement affect the other models? With each arrow in Figure 2.3, the effects of this requirement ripple through the model as follows:
All important submodel output—business requirements, user requirements, business rule logic and algorithms, database schema, performance, and so on—is described in the project's Functional Specification. This is a living document that is continuously changed and updated throughout the development cycle. At each design stage, it's important that any significant change percolate through the other submodels, following the arrows between neighboring submodels until the impact of the change has been fully accounted for throughout the entire Enterprise Application Model. Many iterations of feedback between neighboring submodels might be needed before a change has been completely assimilated.
The Physical Model for an enterprise application is the final outcome of the design process and can be directly derived from the requirements of its neighboring submodels. Because of this, the design process is, to a great extent, a process of balancing the natural contentions between the various submodels.
For example, the Business Model's interest in reducing administration costs might push the Technology Model toward remote processing on central servers. At the same time, the most efficient User Model might suggest local processing on the user's desktop. The process of defining the Physical Model necessarily involves finding an acceptable compromise between these two competing goals.
Understanding these interactions helps determine the order in which design decisions should be made, and can help prevent ill-considered changes to one aspect of the overall design that may unacceptably impact the requirements described in other submodels.
Because the Development Model permeates the entire Enterprise Application Model, this submodel has no "typical" interactions with the other submodels. Every design and implementation decision must be accounted for in the Development Model.
Examples of the common submodel interactions that can occur within the Enterprise Application Model are presented in the following sections. For each submodel, we briefly cover:
The Internet is a major new technology and deployment platform for enterprise applications. For this reason, it is less familiar to many developers than other technologies for component-based design and delivery. Its impact is discussed in these brief summaries. Singling it out in this manner is not meant to imply that the Internet is always, or even usually, the best platform for enterprise applications. It is simply an attractive new option that may be the right choice in some situations.
The Business Model defines the organization's goals and its reasons for funding the application. Questions about the application that this model answers include:
In an ideal scenario, implementing an enterprise application architecture begins by defining the business requirements embodied in the Business Model. If other models are implemented outside the Business Model context, the business goals supported by the project may not be appropriate for the organization.
Figure 2.3 illustrated that the Business Model directly interacts with the User Model, the Logical Model, and the Technology Model. Table 2.4 characterizes these interactions and gives brief examples of each.
Table 2.4 Interactions of the Business Model
|Submodel||How the Business Model relates to it||Example|
|User||Determines who will use the application, their skill levels, and their desktop configuration.||An application that will be used by inexperienced personnel must be highly intuitive and well-documented.|
|Logical||Sets policies about how business assets must be managed. These policies are reflected in logical business rules.||Business policies determine how shipping, inventory, and sales must respond to new orders.|
|Technology||Determines or constrains the technology needed to satisfy business requirements.||A business requirement to directly market the organization's products through electronic commerce mandates Internet technology.|
Each of these interactions works both ways. For example, the cost and capacity of new modems may limit the number of customers an organization will be able to serve with its new Internet-based direct marketing application. In this case, the Technology Model might force a reassessment of the goals and requirements of the Business Model.
Examples of the way the Internet has impacted the Business Model include:
The User Model defines the target user of the application. Questions about the application that this model answers include:
In larger or more formal environments, the User Model itself can be separated into four relatively independent submodels: the Usability Model, the Documentation Model, the Support Model, and the User Security Model.
Figure 2.3 illustrated that the User Model directly interacts with the Business Model, the Logical Model, the Technology Model, and the Physical Model. Table 2.5 characterizes these interactions and gives brief examples of each.
Table 2.5 Interactions of the User Model
|Submodel||How the User Model relates to it||Example|
|Business||The number of users, their skill levels, and desktop configurations determine the cost of training and supporting them.||A retail order-entry application must be fast to accommodate busy clerks. This may require additional hardware or infrastructure investments.|
|Logical||How the user thinks about the tasks and works at them determines how the functionality must be logically encapsulated.||If a customer's credit can be checked while the order is being taken, the credit-checking functionality must be in a separate, asynchronously processed component.|
|Technology||User requirements determine the technology needed to meet them.||An application deployed on the Internet must use platform-independent technology for the user-interface elements.|
|Physical||The number of users and their locations affect the component architecture needed to reach them effectively.||An application that will be used by a rapidly changing number of users must deploy its user-intensive services in an easily scalable configuration, such a component pool or queue.|
Examples of the way the Internet has impacted the User Model include:
The Logical Model defines the business entities that will be rendered by the application, and what policies and rules will be used to operate on those entities. The questions this model answers are very specific to the business for which the application is being developed. Questions about the application that this model answers include:
The Logical Model itself is made up of two relatively independent submodels:
Figure 2.3 illustrated that the Logical Model directly interacts with the Business Model, the User Model, the Technology Model, and the Physical Model. Table 2.6 characterizes these interactions and gives brief examples of each of the interactions.
Table 2.6 Interactions of the Logical Model
|Submodel||How the Logical Model relates to it||Example|
|Business||Determines how business policies can be encapsulated.||An application that must accommodate rapidly changing tax rates and rules must isolate these rules in separate, easily maintainable components.|
|User||Defines the logical entities users act on to perform various business tasks.||Logical customer and order objects and credit-checking services are needed to enable users to carry out typical sales tasks in the application.|
|Technology||Specifies the features and services that must be packaged into the chosen technology's components.||A credit-checking component must use technology capable of interfacing with credit reporting agencies.|
|Physical||Determines the features and services that must be deployable using the chosen physical architecture.||A funds transfer component must be deployed upon an infrastructure that supports reliable security protocols.|
Examples of the way the Internet has impacted the Logical Model include:
For the most part, the Internet is a physical phenomenon. It will not have a significant impact on the Logical Model of those organizations that have already moved to object-oriented, LAN-based development.
The Technology Model defines the technology services that are available to solve the application's requirements. The Technology Model is used to identify, acquire, or create the necessary technical resources that support the requirements. Questions about the application that this model answers include:
Code written and compiled for the project becomes part of the Technology Model, just like controls or operating system services picked up from external sources. Similarly, the source code for the project is part of the Technology Model, in the same way that usability test reports are part of the User Model.
Figure 2.3 illustrated that the Technology Model directly interacts with the Business Model, the Logical Model, the User Model, and the Physical Model. Table 2.7 characterizes these interactions and gives brief examples of each.
Table 2.7 Interactions of the Technology Model
|Submodel||How the Technology Model relates to it||Example|
|Business||Implements the application's business objectives into the physical system.||New Internet technologies create business opportunities that were previously unavailable.|
|Logical||Implements the logical structure of the application as physical components.||Business rules are encapsulated in components that run on the application's infrastructure.|
|User||Delivers application functionality with technology appropriate to the user's skills, desktop configuration, and connectivity.||If an Internet application gives users remote database and business-processing services, the development team must acquire the tools to program, debug, and test multi-user, asynchronous, distributed applications.|
|Physical||Provides the technology to deliver the application functionality on the chosen physical architecture(s).||If an Internet application must run on servers that use different operating systems, the development team may have to use multiple programming languages and tools.|
Examples of the way the Internet has impacted the Technology Model include:
The Development Model defines the process and resources used to develop an application, and is the "glue" that allows all the submodels to work together. Questions about the application that this model answers include:
The Enterprise Architecture Development Model can effectively use two additional MSF models. However, these models can also stand alone and should be considered peers.
Figure 2.3 illustrated that the Development Model permeates all the other submodels, guiding the process of development through them and coordinating their requirements and deliverables. In this respect, there are no "typical" interactions, because every design and implementation decision must be taken into account in the Development Model.
Examples of the way the Internet has impacted the Development Model include:
The Physical Model defines where the physical resources to support the requirements of the other submodels of the application are deployed. It also specifies the process through which competing interests of the submodels are resolved. The completed Physical Model of an enterprise application is the application's architecture. Questions about the application that this model answers include:
An application architecture is a conceptual view of the structure of an application. As shown in Figure 2.4, each application has three distinct layers: the user layer, the business layer, and the data layer. Each application also contains presentation code, business-rule processing code, data processing code, and data storage code. Application architectures differ in how this code is packaged to form a particular application product.
Figure 2.4 Physical Model and its application layers
Many current applications have a two-tier architecture, also known as client/server architecture. In a two-tier architecture, a client process handles the data processing and presentation parts of the application. Data is stored on centrally administered server machines. Clients connect directly to the servers they need, often for the lifetime of the application's use.
Client/server applications work well in controlled environments in which the number of users can be estimated and managed, and resources can be allocated accordingly. However, when the number of users is unknown or very large, the client/server architecture breaks down. Because each client connects to data servers directly, the number of available data connections limits scalability. Opportunities for reuse are limited because the clients are bound to the database formats. Each client application contains data processing logic, making the applications relatively large. (This type of client is sometimes called a fat client.) If the data processing logic ever needs to change, new applications must be distributed to every client computer.
A slight improvement comes from moving parts of the data processing, or business logic, to the data servers—for example, by using Microsoft SQL Server stored procedures. This architecture is sometimes called "two-and-a-half tier." Applications built on this model are somewhat more scalable, but not scalable enough to meet the needs of highly distributed applications. In addition, opportunities for reuse are limited.
Scalability and reuse can be improved significantly by introducing a third tier to the application architecture. With multi-layer architecture, also known as N-tier architecture, the user, business, and data tiers are logically separated, as illustrated in Figure 2.5.
Figure 2.5 Multi-layer application architecture
The three tiers perform the following functions:
It may be slightly confusing to talk about logical architecture as part of the Physical Model. It is important to understand that logical architecture encompasses a wide range of physical architectures and implementations that specify where services are deployed. In other words, applications are constructed as logical networks of consumers and suppliers of services. Services are merely units of application logic that provide well-defined functionality.
The terms multi-layer and N-tier don't imply separate computers. The N-tier application architecture promotes scalable applications. To create highly scalable applications, resources such as database connections must be shared. Instead of each client application consuming resources to access data servers directly, client applications communicate with business services. One instance of a business service can support many clients, reducing resource consumption and improving scalability, as shown in Figure 2.6 and Figure 2.7. Because business services do not manage data directly, it's easy to replicate these services to support even more clients. Services can often be designed and implemented independently of any particular client applications, providing flexibility and the potential for reuse in many applications. By encapsulating application logic behind well-defined public interfaces, developers create a body of reusable services that can easily be combined in new ways to create new applications. In addition, common functionality can easily be updated in response to changing business requirements, without impacting the client applications that rely on the functionality. This reduces the management and deployment costs of changing requirements.
Figure 2.6 Client/server systems
Figure 2.7 N-tier systems
The multi-layer application architecture can also help developers deal with existing, or legacy systems. Developers can "wrap" access to existing systems within business logic, data access, or data store services. Client applications need to worry only about how to access the business logic, not about how to access all the different legacy systems they might rely on. And if the legacy system is modified or replaced, only the wrapper needs to be updated.
Figure 2.3 illustrated that the Physical Model directly interacts with the User Model, the Logical Model, and the Technology Model. Table 2.8 characterizes these interactions and gives brief examples of each.
Table 2.8 Interactions of the Physical Model
|Submodel||How the Physical Model relates to it||Example|
|User||Provides the means by which the application is made available to users.||The physical architecture must be able to support users' desktop configurations and scale efficiently to the number of users and their processing requirements.|
|Logical||Determines the extent to which logical constructs can be mapped to the physical infrastructure.||An application that provides online transaction processing must define components that can interface with a transaction management infrastructure.|
|Technology||Limits the technology that can be supported on the physical infrastructure.||An application deployed to the public on the Internet must use "least common denominator" technology for user-interface elements that must run on a variety of platforms and browsers.|
Examples of the way the Internet has impacted the Physical Model include: