Application Architecture deals with how applications are built and interact with each other. Building a suite of applications that communicate across your intranet with a service oriented approach to distributing core business logic and information will utilize a different Application Architecture than a suite of applications that run on the same PC and share common functionality. In either case it makes sense to look at the Application Architecture from two perspectives, namely the functional and integration views. The level of detail you want in either view depends on the type of IT shop you have. If you develop applications in house, then you will want to explore the underlying components of your applications. If you are mostly an integration shop that purchases off-the-shelf software and provide some “integration glue” to allow them to communicate, then you may only need to deal with the applications as “black boxes.”
The Application Architecture is composed of the design of the applications and the use case realizations that depict how projects have used the applications and their components to realize the functional requirements of the use cases. The realizations are archived and maintained in the Application Architecture so they are available to future projects that may need to modify the use cases or want to leverage what has been done on previous projects. Use case realizations for new projects reside in the projects area of the enterprise model until they have been completed. At that time, their results are moved to the Use Case Realization section and the various architecture views will be updated if the project has impacted them.
