Spread the love

The following review checklists provide a wide range of typical questions that may be used in conducting Architecture Compliance reviews, relating to various aspects of the architecture. The organization of the questions includes the basic disciplines of system engineering, information management, security, and systems management. The checklists are based on material provided by a member of The Open Group, and are specific to that organization. Other organizations could use the following checklists with other questions tailored to their own particular needs.

The checklists provided contain too many questions for any single review: they are intended to be tailored selectively to the project concerned (see 48.6 Architecture Compliance Review Guidelines). The checklists actually used will typically be developed/selected by subject matter experts. They are intended to be updated annually by interest groups in those areas.

Some of the checklists include a brief description of the architectural principle that provokes the question, and a brief description of what to look for in the answer. These extensions to the checklist are intended to allow the intelligent re-phrasing of the questions, and to give the user of the checklist a feel for why the question is being asked.

Occasionally the questions will be written, as in RFPs, or in working with a senior project architect. More typically they are expressed orally, as part of an interview or working session with the project.

The checklists provided here are designed for use in individual architecture projects, not for business domain architecture or for architecture across multiple projects. (Doing an architecture review for a larger sphere of activity, across multiple business processes and system projects, would involve a similar process, but the checklist categories and their contents would be different.)

Detailed Checklist

Hardware and Operating System Checklist

  • What is the project’s life cycle approach?
  • At what stage is the project in its life cycle?
  • What key issues have been identified or analyzed that the project believes will drive evaluations of hardware and operating systems for networks, servers, and end-user devices?
  • What system capabilities will involve high-volume and/or high-frequency data transfers?
  • How does the system design impact or involve end-user devices?
  • What is the quantity and distribution (regional and global) of usage, data storage, and processing?
  • What applications are affinitized with your project by similarities in data, application services, etc.? To what degree is data affinitized with your project?
  • What hardware and operating system choices have been made before functional design of key elements of the system?
  • If hardware and operating system decisions were made outside of the project’s control:
    • What awareness does the project have of the rationale for those decisions?
    • How can the project influence those decisions as system design takes shape?
  • If some non-standards have been chosen:
    • What are the essential business and technical requirements for not using corporate standards?
    • Is this supported by a business case?
    • Have the assumptions in the business case been subject to scrutiny?
  • What is your process for evaluating full life cycle costs of hardware and operating systems?
  • How has corporate financial management been engaged in evaluation of life cycle costs?
  • Have you performed a financial analysis of the supplier?
  • Have you made commitments to any supplier?
  • Do you believe your requirements can be met by only one supplier?

Software Services and Middleware Checklist

  • Describe how error conditions are defined, raised, and propagated between application components.
  • Describe the general pattern of how methods are defined and arranged in various application modules.
  • Describe the general pattern for how method parameters are defined and organized in various application modules. Are [in], [in/out], [out] parameters always specified in the same order? Do Boolean values returned by modules have a consistent outcome?
  • Describe the approach that is used to minimize the number of round-trips between client and server calls, particularly for out-of-process calls, and when complex data structures are involved.
  • Describe the major data structures that are passed between major system components.
  • Describe the major communication protocols that are used between major system components.
  • Describe the marshaling techniques that are used between various system components. Describe any specialized marshaling arrangements that are used.
  • Describe to what extent the system is designed with stateful and stateless components.
  • Describe how and when state is saved for both stateful and stateless components.
  • Describe the extent to which objects are created, used, and destroyed versus re-used through object pooling.
  • Describe the extent to which the system relies on threading or critical section coding.
  • Describe the approach and the internal documentation that is used internally in the system to document the methods, methods arguments, and method functionality.
  • Describe the code review process that was used to build the system.
  • Describe the unit testing that has been used to test the system components.
  • Describe the pre- and post-condition testing that is included in various system modules.
  • Describe the assertion testing that is included with the system.
  • Do components support all the interface types they need to support or are certain assumptions made about what types of components will call other components either in terms of language bindings or other forms of marshaling?
  • Describe the extent to which big-endian or little-endian data format problems need to be handled across different platforms.
  • Describe if numbers or strings need to be handled differently across different platforms.
  • Describe whether the software needs to check for floating-point round-off errors.
  • Describe how time and date functions manage dates so as to avoid improper handling of time and date calculation or display.
  • Describe what tools or processes have been used to test the system for memory leaks, reachability, or general robustness.
  • Describe the layering of the systems services software. Describe the general number of links between major system components. Is the system composed of a lot of point-to-point interfaces or are major messaging backbones used instead?
  • Describe to what extent the system components are either loosely coupled or tightly coupled.
  • What requirements does the system need from the infrastructure in terms of shared libraries, support for communication protocols, load balancing, transaction processing, system monitoring, naming services, or other infrastructure services?
  • Describe how the system and system components are designed for refactoring.
  • Describe how the system or system components rely on common messaging infrastructure versus a unique point-to-point communication structure.

Applications Checklists

Infrastructure (Enterprise Productivity) Applications

  • Is there need for capabilities that are not provided through the enterprise’s standard infrastructure application products? For example:
    • Collaboration
      1. Application sharing
      2. Video conferencing
      3. Calendaring
      4. Email
    • Workflow management
    • Publishing/word processing applications
      1. HTML
      2. SGML and XML
      3. Portable document format
      4. Document processing (proprietary format)
      5. Desktop publishing
    • Spreadsheet applications
    • Presentation applications
      1. Business presentations
      2. Image
      3. Animation
      4. Video
      5. Sound
      6. CBT
      7. Web browsers
    • Data management applications
      1. Database interface
      2. Document management
      3. Product data management
      4. Data warehouses/mart
    • Program management applications
      1. Project management
      2. Program visibility
  • Describe the business requirements for enterprise infrastructure application capabilities that are not met by the standard products.

Business Applications

  • Are any of the capabilities required provided by standard products supporting one or more line-of-business applications? For example:
    • Business acquisition applications
      1. Sales and marketing
    • Engineering applications
      1. Computer-aided design
      2. Computer-aided engineering
      3. Mathematical and statistics analysis
    • Supplier management applications
      1. Supply chain management
      2. Customer relationship management
    • Manufacturing applications
      1. Enterprise Resource Planning (ERP) applications
      2. Manufacturing execution systems
      3. Manufacturing quality
      4. Manufacturing process engineering
      5. Machine and adaptive control
    • Customer support applications
      1. Airline logistics support
      2. Maintenance engineering
    • Finance applications
    • People applications
    • Facilities applications
    • Information systems applications
      1. Systems engineering
      2. Software engineering
      3. Web developer tools
      4. Integrated development environments
      5. Lifecycle categories
      6. Functional categories
      7. Specialty categories
    • Computer-aided manufacturing
    • e-Business enablement
    • Business process engineering
      1. Statistical quality control
  • Describe the process requirements for business application capabilities that are not met by the standard products.

Application Integration Approach

  • What integration points (business process/activity, application, data, computing environment) are targeted by this architecture?
  • What application integration techniques will be applied (common business objects [ORBs], standard data definitions [STEP, XML, etc.], common user interface presentation/desktop)?

Information Management Checklists

Data Values

  • What are the processes that standardize the management and use of the data?
  • What business process supports the entry and validation of the data? Use of the data?
  • What business actions correspond to the creation and modification of the data?
  • What business actions correspond to the deletion of the data and is it considered part of a business record?
  • What are the data quality requirements required by the business user?
  • What processes are in place to support data referential integrity and/or normalization?

Data Definition

  • What are the data model, data definitions, structure, and hosting options of purchased applications (COTS)?
  • What are the rules for defining and maintaining the data requirements and designs for all components of the information system?
  • What shareable repository is used to capture the model content and the supporting information for data?
  • What is the physical data model definition (derived from logical data models) used to design the database?
  • What software development and data management tools have been selected?
  • What data owners have been identified to be responsible for common data definitions, eliminating unplanned redundancy, providing consistently reliable, timely, and accurate information, and protecting data from misuse and destruction?

Security/Protection

  • What are the data entity and attribute access rules which protect the data from unintentional and unauthorized alterations, disclosure, and distribution?
  • What are the data protection mechanisms to protect data from unauthorized external access?
  • What are the data protection mechanisms to control access to data from external sources that temporarily have internal residence within the enterprise?

Hosting, Data Types, and Sharing

  • What is the discipline for managing sole-authority data as one logical source with defined updating rules for physical data residing on different platforms?
  • What is the discipline for managing replicated data, which is derived from operational sole-authority data?
  • What tier data server has been identified for the storage of high or medium-critical operational data?
  • What tier data server has been identified for the storage of type C operational data?
  • What tier data server has been identified for the storage of decision support data contained in a data warehouse?
  • What Database Management Systems (DBMSs) have been implemented?

Common Services

  • What are the standardized distributed data management services (e.g., validation, consistency checks, data edits, encryption, and transaction management) and where do they reside?
Access Method
  • What are the data access requirements for standard file, message, and data management?
  • What are the access requirements for decision support data?
  • What are the data storage and the application logic locations?
  • What query language is being used?

Security Checklist

  • Security Awareness: Have you ensured that the corporate security policies and guidelines to which you are designing are the latest versions? Have you read them? Are you aware of all relevant computing security compliance and risk acceptance processes? (Interviewer should list all relevant policies and guidelines.)
  • Identification/Authentication: Diagram the process flow of how a user is identified to the application and how the application authenticates that the user is who they claim to be. Provide supporting documentation to the diagram explaining the flow from the user interface to the application/database server(s) and back to the user. Are you compliant with corporate policies on accounts, passwords, etc.?
  • Authorization: Provide a process flow from beginning to end showing how a user requests access to the application, indicating the associated security controls and separation of duties. This should include how the request is approved by the appropriate data owner, how the user is placed into the appropriate access-level classification profile, how the user ID, password, and access is created and provided to the user. Also include how the user is informed of their responsibilities associated with using the application, given a copy of the access agreement, how to change password, who to call for help, etc.
  • Access Controls: Document how the user IDs, passwords, and access profiles are added, changed, removed, and documented. The documentation should include who is responsible for these processes.
  • Sensitive Information Protection: Provide documentation that identifies sensitive data requiring additional protection. Identify the data owners responsible for this data and the process to be used to protect storage, transmission, printing, and distribution of this data. Include how the password file/field is protected. How will users be prevented from viewing someone else’s sensitive information? Are there agreements with outside parties (partners, suppliers, contractors, etc.) concerning the safeguarding of information? If so, what are the obligations?
  • Audit Trails and Audit Logs: Identify and document group accounts required by the users or application support, including operating system group accounts. Identify and document individual accounts and/or roles that have superuser type privileges, what these privileges are, who has access to these accounts, how access to these accounts is controlled, tracked, and logged, and how password change and distribution are handled, including operating system accounts. Also identify audit logs, who can read the audit logs, who can modify the audit logs, who can delete the audit logs, and how the audit logs are protected and stored. Is the user ID obscured in the audit trails?
  • External Access Considerations: Will the application be used internally only? If not, are you compliant with corporate external access requirements?

System Management Checklist

  • What is the frequency of software changes that must be distributed?
  • What tools are used for software distribution?
  • Are multiple software and/or data versions allowed in production?
  • What is the user data backup frequency and expected restore time?
  • How are user accounts created and managed?
  • What is the system license management strategy?
  • What general system administration tools are required?
  • What specific application administration tools are required?
  • What specific service administration tools are required?
  • How are service calls received and dispatched?
  • Describe how the system is uninstalled.
  • Describe the process or tools available for checking that the system is properly installed.
  • Describe tools or instrumentation that are available that monitor the health and performance of the system.
  • Describe the tools or process in place that can be used to determine where the system has been installed.
  • Describe what form of audit logs are in place to capture system history, particularly after a mishap.
  • Describe the capabilities of the system to dispatch its own error messages to service personnel.

System Engineering/Overall Architecture Checklists

General

  • 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?
  • What computing resources are needed to provide system service to users inside the enterprise? Outside the enterprise and using enterprise computing assets? Outside the enterprise and using their own assets?
  • How can users outside the native delivery environment access your applications and data?
  • What is the life expectancy of this application?
  • Describe the design that accommodates changes in the user base, stored data, and delivery system technology.
  • What is the size of the user base and their expected performance level?
  • What performance and stress test techniques do you use?
  • What is the overall organization of the software and data components?
  • What is the overall service and system configuration?
  • How are software and data configured and mapped to the service and system configuration?
  • What proprietary technology (hardware and software) is needed for this system?
  • Describe how each and every version of the software can be reproduced and re-deployed over time.
  • Describe the current user base and how that base is expected to change over the next three to five years.
  • Describe the current geographic distribution of the user base and how that base is expected to change over the next three to five years.
  • Describe how many current or future users need to use the application in a mobile capacity or who need to work off-line.
  • Describe what the application generally does, the major components of the application, and the major data flows.
  • Describe the instrumentation included in the application that allows for the health and performance of the application to be monitored.
  • Describe the business justification for the system.
  • Describe the rationale for picking the system development language over other options in terms of initial development cost versus long-term maintenance cost.
  • Describe the systems analysis process that was used to come up with the system architecture and product selection phase of the system architecture.
  • Who besides the original customer might have a use for or benefit from using this system?
  • What percentage of the users use the system in browse mode versus update mode?
  • What is the typical length of requests that are transactional?
  • Do you need guaranteed data delivery or update, or does the system tolerate failure?
  • What are the up-time requirements of the system?
  • Describe where the system architecture adheres or does not adhere to standards.
  • Describe the project planning and analysis approach used on the project.

Processors/Servers/Clients

  • Describe the client/server Application Architecture.
  • Annotate the pictorial to illustrate where application functionality is executed.

Client

  • 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.
  • Describe data volumes being transferred to the client.
  • What are the additional requirements for local data storage to support the application?
  • What are the additional requirements for local software storage/memory to support the application?
  • Are there any known hardware/software conflicts or capacity limitations caused by other application requirements or situations which would affect the application users?
  • Describe how the look-and-feel of your presentation layer compares to the look-and-feel of the other existing applications.
  • Describe to what extent the client needs to support asynchronous and/or synchronous communication.
  • Describe how the presentation layer of the system is separated from other computational or data transfer layers of the system.

Application Server

  • Can/do the presentation layer and application layers run on separate processors?
  • Can/do the application layer and data access layer run on separate processors?
  • Can this application be placed on an application server independent of all other applications? If not, explain the dependencies.
  • Can additional parallel application servers be easily added? If so, what is the load balancing mechanism?
  • 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

  • Are there other applications which must share the data server? If so, identify them and describe the data and data access requirements.
  • 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?

COTS (where applicable)

  • Is the vendor substantial and stable?
  • Will the enterprise receive source code upon demise of the vendor?
  • Is this software configured for the enterprise’s usage?
  • Is there any peculiar A&D data or processes that would impede the use of this software?
    • Is this software currently available?
  • Has it been used/demonstrated for volume/availability/service-level requirements similar to those of the enterprise?
    • Describe the past financial and market share history of the vendor.

System Engineering/Methods & Tools Checklist

  • Do metrics exist for the current way of doing business?
  • Has the system owner created evaluation criteria that will be used to guide the project? Describe how the evaluation criteria will be used.
  • Has research of existing architectures been done to leverage existing work? Describe the method used to discover and understand. Will the architectures be integrated? If so, explain the method that will be used.
  • Describe the methods that will be used on the project:
    • For defining business strategies
    • For defining areas in need of improvement
    • For defining baseline and target business processes
    • For defining transition processes
    • For managing the project
    • For team communication
    • For knowledge management, change management, and configuration management
    • For software development
    • For referencing standards and statements of direction
    • For quality assurance of deliverables
    • For design reviews and deliverable acceptance
    • For capturing metrics
  • Are the methods documented and distributed to each team member?
  • To what extent are team members familiar with these methods?
  • What processes are in place to ensure compliance with the methods?
  • Describe the infrastructure that is in place to support the use of the methods through the end of the project and anticipated releases.
    • How is consultation and trouble-shooting provided?
    • How is training coordinated?
    • How are changes and enhancements incorporated and cascaded?
    • How are lessons learned captured and communicated?
  • What tools are being used on the project? (Specify versions and platforms). To what extent are team members familiar with these tools?
  • Describe the infrastructure that is in place to support the use of the tools through the end of the project and anticipated releases?
    • How is consultation and trouble-shooting provided?
    • How is training coordinated?
    • How are changes and enhancements incorporated and cascaded?
    • How are lessons learned captured and communicated?
  • Describe how the project will promote the re-use of its deliverables and deliverable content.
  • Will the architecture designs “live” after the project has been implemented? Describe the method that will be used to incorporate changes back into the architecture designs.
  • Were the current processes defined?
  • Were issues documented, rated, and associated to current processes? If not, how do you know you are fixing something that is broken?
  • Were existing/planned process improvement activities identified and associated to current processes? If not, how do you know this activity is not in conflict with or redundant to other Statements of Work?
  • Do you have current metrics? Do you have forecasted metrics? If not, how do you know you are improving something? – Load and Stress Testing results maybe?
  • What processes will you put in place to gather, evaluate, and report metrics?
  • What impacts will the new design have on existing business processes, organizations, and information systems? Have they been documented and shared with the owners?

Summary Checklist

General

  • What are the main stakeholders of the system.
  • Is the organisation ready for the transformation? TOGAF recommends you can check this with the Business Transformation Readiness Assessment.
  • What are the main actors that interact with the system?
  • What are the major business scenarios and the important requirements. Did you cover the:
    • regulatory & compliance requirements
    • security requirements
    • reporting requirements
    • data retention requirements
  • What other applications and/or systems require integration with yours? Does it require integration with:
    • Ordering system
    • CRM, Loyalty &  Commissioning
    • Billing (In case you have a new service, decide how you will bill it)
    • ERP
    • POS
    • BI & Analytics
    • Reporting & Data warehouse
    • Channels (Online, Mobile, wearables, APIs for partners,  IVR, Contact center, Store/Branch GUI, Partners/Resellers/Suppliers GUI, etc)
    • User behavior tracking (web & mobile analytics, UX tracking)
    • Operational & Performance monitoring
    • Audit & forensic investigation
  • Describe the integration level and strategy with each.
  • What are the SLAs and OLAs? What are the up-time requirements of the system? Does it need high availability?
  • How geographically distributed is the user base?
  • What is the strategic importance of this system to other user communities inside or outside the enterprise?
  • What computing resources are needed to provide system service to users inside the enterprise? Outside the enterprise and using enterprise computing assets? Outside the enterprise and using their own assets?
  • How can users outside the native delivery environment access your applications and data?
  • What is the life expectancy of this application?
  • Describe the design that accommodates changes in the user base, stored data, and delivery system technology.
  • What is the size of the user base and their expected performance level?
  • What performance and stress test techniques do you use?
  • What is the overall organization of the software and data components?
  • What is the overall service and system configuration?
  • How are software and data configured mapped to the service and system configuration?
  • What proprietary technology (hardware and software) is needed for this system?
  • Describe how each and every version of the software can be reproduced and re-deployed over time.
  • Describe the current user base and how that base is expected to change over the next 3 to 5 years.
  • Describe the current geographic distribution of the user base and how that base is expected to change over the next 3 to 5 years.
  • Describe the how many current or future users need to use the application in a mobile capacity or who need to work off-line.
  • Describe what the application generally does, the major components of the application and the major data flows.
  • Describe the instrumentation included in the application that allows for the health and performance of the application to be monitored.
  • Describe the business justification for the system.
  • Describe the rationale for picking the system development language over other options in terms of initial development cost versus long term maintenance cost.
  • Describe the systems analysis process that was used to come up with the system architecture and product selection phase of the system architecture.
  • Who besides the original customer might have a use for or benefit from using this system?
  • What percentage of the users use the system in browse mode versus update mode?
  • What is the typical length of requests that are transactional?
  • Do you need guaranteed data delivery or update, or the system tolerate failure?
  • Describe where the system architecture adheres or does not adhere to standards.
  • Describe the project planning and analysis approach used on the project.
  • Do you need to migrate users’ data from other systems? Does it require initial loads?
  • What is the licensee schema? What are the costs associated with system commissioning , both CAPEX and OPEX.
  • Are the component descriptions sufficiently precise?
    • Must allow independent construction.
    • Are interfaces and external functionality of the high-level components described in detail.
    • Avoid implementation details; do not describe each class in detail.
  • Are the relationships between the components explicitly documented? You can use a (sequence) diagram to represent the interaction between components.
  • Is the proposed solution realizable?
    • Can the components be implemented or bought, and then integrated together.
    • Possibly introduce a second layer of decomposition to get a better grip on realiability
  • Are all relevant architectural views documented?
    • Logical view (class diagram per component expresses functionality).
    • Process view (how control threads are set up, interact, evolve, and die).
    • Physical view (deployment diagram relates components to equipment).
    • Development view (how code is organized in files; could also be documented in SCMP appendix).
  • Are cross-cutting issues clearly and generally resolved?
    • Exception handling.
    • Initialization and reset.
    • Memory management.
    • Security.
    • Internationalization.
    • Built-in help.
    • Built-in test facilities.
    • Migration & Initial load
  • Have alternative architectures been sketched and has their evaluation been documented?
  • Have non-functional software requirements also been considered
  • Negative indicators:
    • High complexity: a component has a complex interface or functionality.
    • Low cohesion: a component contains unrelated functionality.
    • High coupling: two components have many (mutual) connections.
    • High fan-in: a component is needed by many other components.
    • High fan-out: a component depends on many other components.
  • Is the flexibility of the architecture demonstrated?
    • How can it cope with likely changes in the requirements?
    • Document the most relevant change scenarios.
  • What is the deployment approach. In case you have clients/mobile application how do you handle version and control diversity.
  • Areas of concern are separated.
  • Every component has a single responsibility.
  • Components do not rely on the internal details of other components.
  • Functionality is not duplicated within the architecture.
  • Components are grouped logically into layers.
  • Abstraction is used to design loose coupling between layers.

Cloud Architecture

When you design a new application or when you make an important update, please take into consideration if your application can be deployed/moved into cloud. Please evaluate if your application can benefits of cloud:

  • Distribution of your user base (are they located to a restricted territory or do you have global/regional usage)
  • Is your application capable of horizontal scaling?
  • Can you split your application in stateless or independent components?
  • How easy can you automate your infrastructure on the cloud (automatic scaling, self healing, etc)
  • Do you use containers?
  • Did you first consider the serverless architecture? Why your solution cannot run on this type of architecture?
  • Do you use edge caching or CDNs to distribute the content?
  • Did you address the security aspects of the services? How they are protected? Do you make use of a API GW and Access Manager capability to standardize the API security?
  • Do you want to focus less on the infrastructure and more on the application developments? Let the cloud providers manage the infrastructure and apply the world class security to it and start focusing on things that matters to your business and your application/product.

Application architectures and tiers/layers

  • Describe the application architecture;
  • Annotate the pictorial to illustrate where application functionality is executed.
  • Can the application tiers be separated on different machines?
  • Layers represent a logical grouping of components. For example, use separate layers for user interface, business logic, and data access components.
  • Components within each layer are cohesive. For example, the business layer components should provide only operations related to application business logic.
  • Authentication
    • Trust boundaries have been identified, and users are authenticated across trust boundaries.
    • Single sign-on is used when there are multiple systems in the application.
    • Passwords are stored as a salted hash, not plain text.
    • Strong passwords or password phrases are enforced.
    • Passwords are not transmitted in plain text.
  •  Authorization
    • Trust boundaries have been identified, and users are authorized across trust boundaries.
    • Resources are protected with authorization on identity, group, claims or role.
    • Role-based authorization is used for business decisions.
    • Resource-based authorization is used for system auditing.
    • Claims-based authorization is used for federated authorization based on a mixture of information such as identity, role, permissions, rights, and other factors.
  • Concurrency and Transactions
    • Business-critical operations are wrapped in transactions.
    • Connection-based transactions are used in the case of a single data source.
    • Transaction Scope (System.Transaction) is used in the case of multiple data sources.
    • Compensating methods are used to revert the data store to its previous state when transactions are not used.
    • Locks are not held for long periods during long-running atomic transactions.
  •  Caching
    • Volatile data is not cached.
    • Data is cached in ready to use format.
    • Unencrypted sensitive data is not cached.
    • Transactional resource manager or distributed caching is used, if your application is deployed in Web farm.
    • Your application does not depend on data still being in cache.
  • Coupling and Cohesion
    • Application is partitioned into logical layers.
    • Layers use abstraction through interface components, common interface definitions, or shared abstraction to provide loose coupling between layers.
    • The components inside layers are designed for tight coupling, unless dynamic behavior requires loose coupling.
    • Each component only contains functionality specifically related to that component.
    • The trade offs of abstraction and loose coupling are well understood for your design. For instance, it adds overhead but it simplifies the build process and improves maintainability.
  • Validation
    • Validation is performed both at presentation and business logic layer
    • Trust boundaries are identified, and all the inputs are validated when they cross the trust boundary.
    • A centralized validation approach is used.
    • Validation strategy constrains, rejects, and sanitizes malicious input.
    • Input data is validated for length, format, and type.
    • Client-side validation is used for user experience and server-side validation is used for security.
  • Configuration Management
    • Least-privileged process and service accounts are used.
    • All the configurable application information is identified.
    • Sensitive information in the configuration is encrypted.
    • Access to configuration information is restricted.
    • If there is a configuration UI, it is provided as a separate administrative UI.

Client/Presentation tier

  • 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.
  • Describe data volumes being transferred to the client.
  • What are the additional requirements for local data storage to support the application?
  • What are the additional requirements for local software storage/memory to support the application?
  • Did you consider caching on client device?
  • Are there any known hardware / software conflicts or capacity limitations caused by other application requirements or situations, which would affect the application users?
  • Describe how the look and feel of your presentation layer compares to the look and feel of the other existing applications.
  • Describe to what extent the client needs to support asynchronous and / or synchronous communication.
  • Describe how the presentation layer of the system is separated from other computational or data transfer layers of the system.
  • Are the wireframes/mockups available?
  • Can it access static content from other locations? Can it access data from CDN?

Business logic layer

  • Can/does the presentation layer and business logic layers run on separate processors?
  • Can/does the business logic layer and data access layer run on separate processors?
  • Can this business logic be placed on an application server independent of all other applications? If not, explain the dependencies.
  • Can additional parallel application servers be easily added? If so, what is the load balancing mechanism?
  • Has the resource demand generated by the business logic been measured and what is the value? If so, has the capacity of the planned server been confirmed at the application and aggregate levels?
  • Does it require shared storage across nodes?

Data Access Layer

  • Database schema is not coupled to your application model.
  • Connections are opened as late as possible and released quickly.
  • Data integrity is enforced in the database, not in the data access layer.
  • Business decisions are made in the business layer, not the data access layer.
  • Database is not directly accessed; database access is routed through the data access layer.
  • Resource gateways are used to access resources outside the application.

Data layer

  • Are there other applications, which must share the data server? If so, please identify them and describe the data and data access requirements.
  • 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?
  • Does the database support collocation on a DB cluster?
  • What relational database management system does your application support: Oracle, MS SQL, MySQL, DB2, Sybase, etc
  • Does your application use/require NoSQL?

 Hardware, Network & OS requirements

  • What are the hardware requirements? Machines, CPU, RAM, Storage;
  • What environments are required, for example: Testing, Development, etc;
  • Does it support virtualization? What virtualization technology can be used, e.g. VMWare.
  • Does the architecture be deployed in cloud? Private or Public cloud? Is there a legal requirement to host and process data in certain territories?
  • What are the OS requirements?
  • What are the 3rd party software requirements? Do they require licensees?
  • Do you need agents to monitor the machine/application?
  • Does it require balancing?
  • Does it require session persistence?
  • Do we have enough network capacity (ports, bandwidth) for all network elements: switches, routers, etc

COTS (where applicable)

  • Is the vendor substantial and stable?
  • Will the enterprise receive source code upon demise of the vendor?
  • Is this software configured for the enterprise’s usage?
  • Is there any peculiar A&D data or processes that would impede the use of this software?
    • Is this software currently available?
  • Has it been used/demonstrated for volume/availability/service level requirements similar to those of the enterprise?
    • Describe the past financial and market share history of the vendor.

Business readiness

  • Are the internal policies updated?
  • Are the Customer Supports Agents & Sales Agents trained on the new solution?
  • Is the documentation updated?
  • In case of a new system, is it formally handover to the Ops team?
  • Are all the compliance/requirements requirements met?

Hits: 31