Sample – Software Architecture Document
February 5, 2013Introduction
The Integration Framework is one part of this strategy. The aim is the rationalization of the current technology portfolio of middle tier and back end business services using a single, non-proprietary, infrastructure-based solution. This will allow Corporate to support a multi-vendor, channel agnostic approach to the development and delivery of business functionality and support the strategy of independent development across the application zones of presentation, middle tier, and back end.
Purpose
This information provides a comprehensive architectural overview of the Integration Framework, using several architectural viewpoints. The main audiences for the information in this document are the Integration team, the Corporate developers and vendor technical resources involved in developing or supporting the Unified Integration Framework and other applications using the Integration Framework.
This information is organized according to the Rational Unified Process (RUP) guidelines and template for a Software Architecture Document artifact. The content of many sections comes from the related Rational Rose model, which is also organized according to the respective RUP templates and guidelines.
The Logical Architecture includes actionable models and engineering blueprints that differentiate approaches and provide a set of product independent architectures for Integration Framework components. It also includes a set of standards for Technology platforms. The Logical Architecture is targeted towards application architects.
The Physical Architecture provides the highest level of detail, and is also called the “implementable architecture”. It includes developer templates, physical implementation diagrams, and recommendations regarding the technology solutions and associated processes and tools. The Physical Architecture is targeted towards contractors, developers and implementers.
The following viewpoints represent the Integration Framework software architecture in the way most appropriate for the particular audience that uses it.
| View | Audience | Description |
| Use-Case View | Integration Framework ArchitectsIntegration Framework DevelopersApplication ArchitectsApplication Developers | The Use-Case View describes the use-cases (or scenarios) from the use-case model that represents the functionality of the software.The Use-Case View elaborates on how the software actually works by elaborating on how each element contributes to the overall functionality. |
| Logical View | Integration Framework ArchitectsIntegration Framework DevelopersApplication ArchitectsApplication Developers | The Logical View decomposes the Use-Case Views into the sub-frameworks and packages.The Logical View presents the classes for each Integration Framework package, introducing the main classes, their responsibilities, as well as the important relationships, operations and attributes. |
| Deployment View | Integration Framework ArchitectsIntegration Framework DevelopersApplication ArchitectsApplication DevelopersInfrastructure Team | The Deployment View describes the physical (i.e. network and hardware) configurations on which the software is deployed and managed. For each configuration, the physical components (e.g. computers, CPUs, LANs) that execute the software are defined. |
| Implementation View | Integration Framework ArchitectsIntegration Framework DevelopersApplication ArchitectsApplication Developers | The Implementation View describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model and any architecturally significant components. |
Scope
The Integration Framework Architecture is intended to be portable across platforms and technology. Consecutively, other than Design Constraints, implementation details are omitted from this document.
The Integration Architecture contains five major components. Each component consists of a service and a framework. The Integration Framework abstracts the backend from the vendor channels and the middle-tier business applications from the middle-tier infrastructure services.
The distinction between a Framework and a Service is that a framework is a description of an application interface to a service, e.g., Security and Connectivity. A framework provides a mechanism to insulate the applications from the many ways a service can be implemented.