Project Architecture Statement

Project Architecture Statement

   In order to improve the proposal / concept level architectural definition, we have created the Project Architecture Statement Approach. The goal of this approach is to describe the problem and solution with complete breadth, limiting detail to what is sufficient only to support problem definition and the resulting proposal or concept level architecture. This approach packages multiple work products into a single document to build a proposal or concept level architecture in a timely fashion. It delivers value by starting at the highest level and "peeling the onion" one layer at a time. At the proposal or concept phase, the key to a successful architectural initiation is to balance the breadth vs. depth of solution definition. Our approach positions the architect for success by focusing on the breadth of the architecture by (1) limiting the Statement to several key work products, and (2) sequencing the work products so the outputs of one work product become inputs to the next.

The system context model identifies all of the potential items within the scope of the problem and the solution. It defines the breadth of the problem / solution. By its own definition the system context diagram "represents the entire system as a single object or process and identifies the interfaces between the system and external entities. It "defines the system and identifies the information and control flows that cross the system boundary." By starting with this diagram the architect is positioned to define the breadth of the system and postpone any depth discussions until later. At this point, the breadth of the system is defined. Our approach now begins to dissect the problem / solution using discrete views. By using discrete views, the architect is able to concentrate on one aspect of the architecture (i.e. business function, application, data, operational, organizational) to gain an understanding and definition of that architecture independent of other aspects. This focus enables speed in defining the problem / solution. After all the aspects are defined, the architect then correlates these definitions together via matrices to understand the system as a whole. Once the system context diagram is complete, the components it contains can be used to define the next level of definition in the use case diagram. The use case model is used to define and understand the business interactions / triggers / needs of the system. By identifying the actors involved with the system from the system context diagram, the architect can now dive into the problem / solution by defining the actors interaction with the system, still treating the system as a black box. Now that the use case model has been built to define the business function aspect of the architecture, the architect can change their discrete view from business function to application components. The entire hierarchy of components may be described in terms of their responsibilitie...