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