Enterprise Application Model

   

Today's enterprise applications are too complex for anyone to grasp completely. No one can hold all the requirements, option, and design choices in mind at one time, much less understand how each requirement affects all the others. Designing large-scale distributed applications calls for a way to simplify all this complexity, and the best approach to managing complexity is through abstraction. By grouping similar requirements together into a small number of abstract categories, you can approach them in a more orderly way. These groups can be arranged to show how they affect and depend on one another, allowing you to break the overall enterprise application development problem into a small set of more manageable tasks. When you understand the interactions between groups of requirements, you can tackle them in a systematic manner, balancing and adjusting each requirement as you go.

The Enterprise Application Model presented here is such an abstraction. The model is an orderly summation of all requirements that contribute to implementing every enterprise application, divided into six specific "sub-models." The following table lists these requirements as items to define or deliver within each model.

Model	Requirements
The development model	Development team Development process Project management Source code control Testing Application milestones and deliverables
The business model	Business goals Development cost Return on investment Resources needed Time constraints Security and maintenance Existing infrastructure investment Business rules and policies
The user model	User interface Ease-of-use requirements Training and documentation Application support User’s desktop configuration and network connection
The logical model	Logical structure of the application Object and data modeling Business objects and services Interface definitions
The technology model	Component development or reuse Development tools Deployment platforms System and database technologies Clustering, pooling, and messaging technologies
The physical model	Physical application architecture Distribution and interconnection of components End product of the iterative inputs of each of the other sub-models

The following illustration shows not only the categories of requirements an enterprise application must meet, but also the relationships among the various requirements. By following the arrows, you can see the business requirements as the starting point for application development, and the physical architecture of the completed system as the final output. Between these two categories, the user, logical, and technology requirements are fulfilled, with each category depending on inputs from both the business requirements and its neighboring sub-models, 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.

The Enterprise Application Model

This view of the model immediately provides important insights into the requirements for successful enterprise application development.

• Understanding the relationships among the different requirements gives you a way to move through the process of designing and building the application without neglecting the many dependencies that each design task has on other parts of the overall design. We’ll explore this iterative development style at length in "Enterprise Development Teams and Processes."
• All of the requirements embodied in each of the sub-models are a part of the overall Enterprise Application Model and contribute to the success or failure of your application, whether or not they are consciously addressed in the development process.
• Each sub-model can be treated in a relatively stand-alone manner, much like software components. Each sub-model has its own set of concepts, requirements, techniques and process, tools, state storage, and input/output (deliverables). In most cases the output of each sub-model will become a critical part of the overall functional specification for the project, and this specification will in turn be used to define the project’s physical architecture and to produce the project test plan.

These insights suggest a development process that is iterative and incremental rather than linear. Such a process lets you work on each set of requirements a little bit at a time, and pause at frequent intervals to assess the impact of each model on its neighbors. This helps to identify conflicting requirements early, so you can make design tradeoffs and adjustments when necessary, before they require re-implementing major portions of your application.

For more information   For more information about the iterative method of development, see Chapter 2, "Enterprise Development Teams and Processes."