Architecture Review Process Goals: - - - - Projects are reviewed in the L123 on a Bi-Weekly basis. During the Project review, a process for managing issues that are technical or architectural in nature is required. A more technically focused meeting should be created to meet on alternating weeks to allow those issues identified in the L123 Project Review to be resolved in an appropriate forum. The creation of a bi-weekly (alternating with L123 Mtg) should be scheduled with an audience of technical resources solutions managers and appropriate project resources to resolve the identified issues. Additionally, a high-level framework and agenda for an Architectural review as a component of the PMO Intake is recommended. This could be dovetailed with the Architectural Review processes and manage technical issues for Portfolio / Project Review Meetings, L123 Reviews and PMO Intake reviews. Deliverables: - Project referral to Architecture Review o High level summary of the technical issue/s o Priority / Impact Assessment (High/Med/Low) o Solution Architect assigned. o Completed Architecture Questionnaire Output from Architecture Review Committee: - - Completed Architecture Review Summary o Proposed Solution o Impact to Project Resources, Schedule Analysis o Impact to Budget Analysis o Proposed timeline to implement proposed Solution Architecture changes. Architecture Review Meeting Minutes with Summary of Reviews Context for Architectural Summary: The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use: A deliverable is a work product that is contractually specified and in turn formally. reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation for m will typically be archived at completion of a project or transitioned into an Architecture Repository as a reference. model, standard, or snapshot of the Architecture Landscape at a point in time. An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository. A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to ‘‘architectures’’ or ‘‘solutions’’. Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer ser vices capability may be required within an enterprise, supported by many SBBs, Overview Introduction such as processes, data, and application software. — Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then use to realize solutions for the enterprise. General Architectural Review Questions (we will only need a subset of these): 1. 2. 3. 4. What other applications and/or systems require integration with yours? Describe the integration level and strategy with each. How geographically distributed is the user base? What is the strategic importance of this system to other user communities inside or outside the enterprise? 5. What IT resources are needed to provide system service to users inside the enterprise? Outside the enterprise and using enterprise IT assets? Outside the enterprise and using their own assets? 6. Will external users access this environment, applications or data? 7. What is the life expectancy of this application? 8. Describe the design that accommodates changes in the user base, stored data, and delivery system technology. 9. What is the size of the user base and their expected performance level? 10. What performance and stress test techniques do you use? 11. What is the overall organization of the software and data components? 12. What is the overall service and system configuration? 13. How are software and data configured mapped to the service and system configuration? 14. What proprietary technology (hardware and software) is needed for this system? 15. Describe how each version of the software can be reproduced and re-deployed over time. 16. Describe the current user base and how that base is expected to change over the next 3 to 5 years. 17. Describe the current geographic distribution of the user base and how that base is expected to change over the next 3 to 5 years. 18. Describe the how many current or future users need to use the application in a mobile capacity or who need to work off-line. 19. Describe what the application generally does, the major components of the application and the major data flows. 20. Describe the instrumentation included in the application that allows for the health and performance of the application to be monitored. 21. Describe the business justification for the system. 22. Describe the rationale for picking the system development language over other options in terms of initial development cost versus long term maintenance cost. 23. Describe the systems analysis process that was used to come up with the system architecture and product selection phase of the system architecture. 24. Who besides the original customer might have a use for or benefit from using this system? 25. What percentage of the users use the system in browse mode versus update mode? 26. What is the typical length of requests that are transactional? 27. Do you need guaranteed data delivery or update, or the system tolerate failure? 28. What are the up-time requirements of the system? 29. Describe where the system architecture adheres or does not adhere to standards. 30. Describe the project planning and analysis approach used on the project. Processors/Servers/Clients 1. Describe the Client/Server application architecture. 2. Annotate the pictorial to illustrate where application functionality is executed. Client 1. 2. 3. 4. 5. 6. Are functions other than presentation performed on the user device? Describe the data and process help facility being provided. Describe the screen-to-screen navigation technique. Describe how the user navigates between this and other applications. How is this and other applications launched from the user device? Are there any inter-application data and process sharing capabilities? If so, describe what is being shared and by what technique / technology. 7. Describe data volumes being transferred to the client. 8. What are the additional requirements for local data storage to support the application? 9. What are the additional requirements for local software storage/memory to support the application? 10. Are there any known hardware / software conflicts or capacity limitations caused by other application requirements or situations, which would affect the application users? 11. Describe how the look and feel of your presentation layer compares to the look and feel of the other existing applications. 12. Describe to what extent the client needs to support asynchronous and / or synchronous communication. 13. Describe how the presentation layer of the system is separated from other computational or data transfer layers of the system. Application Server 1. Can/does the presentation layer and application layers run on separate processors? 2. Can/does the application layer and data access layer run on separate processors? 3. Can this application be placed on an application server independent of all other applications? If not, explain the dependencies. 4. Can additional parallel application servers be easily added? If so, what is the load balancing mechanism? 5. Has the resource demand generated by the application been measured and what is the value? If so, has the capacity of the planned server been confirmed at the application and aggregate levels? Data Server 1. Are there other applications, which must share the data server? If so, please identify them and describe the data and data access requirements. 2. Has the resource demand generated by the application been measured and what is the value? If so, has the capacity of the planned server been confirmed at the application and aggregate levels? Commercial Off The Shelf software (COTS) - where applicable 1. Is the vendor substantial and stable? 2. Will the enterprise receive source code upon demise of the vendor (Code Escrow)? 3. Is the software configured for the enterprise's usage? 4. Is there any peculiar Analysis & Design data or processes that would impede the use of this software? o Is this software currently available? o What is the refresh lifecycle? o Where is the current version that will be implemented in its lifecycle? 5. Has it been used/demonstrated for volume/availability/service level requirements like those of the enterprise? o Describe the past financials and market share history of the vendor support a decision to adopt this product?
