How the Sub-Models Help You Design

  • Article

aa266917(v=vs.60).md    

A big advantage of using the Enterprise Application Model as a design guide is that it lets you start anywhere. The context and priorities of the project, rather than an arbitrary linear sequence, determine the correct sequence for traversing from one sub-model to another — and ultimately fulfilling the requirements of all of the sub-models. For new projects, the preferred direction is top to bottom: the needs of the business drive the middle sub-models, and the needs of the middle sub-models drive the physical architecture that is finally implemented. However, you may have good reasons to start elsewhere — for example, an existing application context that needs re-deployment, or a usability problem that must be fixed.

The Enterprise Application Model

As the arrows in the Enterprise Application Model show, the requirements and output from neighboring sub-models directly affect each sub-model. The application architect uses these arrows to balance and resolve the competing requirements between the sub-models while creating the application’s functional specification.

Regardless of which sub-model you work on first, the general pattern for traversing the model during application design is:

  1. Make some design choices in any sub-model.

  2. See what effect those design choices have on the neighboring sub-models, and make any necessary design adjustments in those models.

  3. Repeat step 2 until the change has been fully accounted for through the entire Enterprise Application Model.

For example, if you are designing an online sales system you might find that the user model requires the system to accommodate a twenty-fold increase in number of users during the holiday season compared to the rest of the year. Following the arrows in the diagram, you could see this requirement ripple through the model as shown in the following description.

Note   To give you a high-level view of how the model works, this description uses some concepts of distributed component-based architecture — such as pooling and scalability — that you may not yet have read about in this material. These terms are defined clearly in later chapters (an incremental approach to documentation!). In the meantime, you can look them up in the glossary if the examples are not clear.

  • The physical model needs to accommodate scaling quickly to a much greater number of users without degrading performance. This requirement will most likely mean a clustering or pooling strategy so that more instances of the critical components can be made available to the system simply by adding additional servers.
  • The logical model must respond by encapsulating the services that interact directly with the user and defining interfaces for them, so that they can be implemented as components that can be easily pooled.
  • The business model must provide the time and budget for these changes to be implemented, the acquisition of any technology required to support them, and must assess the impact of such a design on the existing corporate network infrastructure.
  • The technology model is affected by these changes in the physical, logical, and business models by having to build the pooled components and choosing an appropriate scaling technology, such as Microsoft® Transaction Server, to coordinate them.
  • The development model, of course, needs to organize the teams that will build and test the pooled components, allocate resources and schedule the development milestones. In the Enterprise Application Model, the development model is the glue that ties together the sub-models, specifying the overall project resources and defining how the work and deliverables flow from one sub-model to another.

At each design stage it’s important to percolate any significant change through the other sub-models in this way, following the arrows between neighboring sub-models until the impact of the change has been fully accounted for throughout the entire Enterprise Application Model. You might need many iterations of feedback between neighboring sub-models before a change has been completely assimilated.

The functional project specification is a straightforward compilation of all important sub-model output: business requirements, user requirements, business rule logic and algorithms, database schema, performance, and so on. It is a living document that you change and update throughout the development cycle. Whenever you make design changes to any aspect of the application, it is important to follow these guidelines to fully account for the change through all of the sub-models.

For more information   For more information about the functional specification and its role in iterative application design, see Chapter 2, "Enterprise Development Teams and Processes."

Balancing interactions between sub-models

The physical (architecture) model for an enterprise application is the final outcome of the design process. You directly derive the physical model from the requirements of its neighboring sub-models. Therefore, the design process is, to a great extent, a process of balancing the natural contention between the various sub-models.

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 must be able to find an acceptable compromise between these two competing goals.

Understanding these interactions helps you to determine the order in which design decisions are made, and can help prevent ill-considered changes to one aspect of the overall design that may unacceptably impact the requirements described in other sub-models.

Examples of the common sub-model interactions that occur within the Enterprise Application Model are presented in the topics that follow this one. Each sub-model is briefly introduced, showing:

  • The major application design questions the model answers.
  • The major relationships between it and other models.
  • Examples of how it is affected by the Internet.
  • Reference to more complete information later in this material.

Note   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.