Conceptual Architecture Checklist

Conceptual Architecture Checklist from the Observations from a Tech Architect: Enterprise Implementation Issues & Solutions Blog. Original author: Craig Borysowich

General

• The applicable analysis and design principles have been applied.
• The Formal Deliverables that have been produced are consistent with those defined in the knowledge base.
• A Current Situation Assessment has been produced, if this was not produced in the previous phase/stage. The scope of the proposed architecture has been controlled to ensure that the estimated build cost falls within the budget constraints of the customer.
  A review of the proposed architecture was conducted by the senior technical designate, before presentation to the customer.

Requirements Satisfaction

• All of the requirements stated in the Requirements Definition have been traced to components of the architecture (or their feature/functions) that satisfy the requirement.
• All items in the proposed architecture (hardware, software, communications, etc.) are necessary to meet the customer's requirements.
• Desirable and recommended aspects of the architecture are identified as optional with associated costs.

Architecture Costs

• Estimated system costs include:
  Capital cost of hardware and software,
  Cost of runtimes on Client workstations,
  Annual software support fees,
  Annual hardware maintenance fees,
  Software upgrade costs (of existing software (e.g., personal productivity tools) and of proposed software),
  Upgrades and installation of power and wiring,
  Upgrades to equipment[Note: This list is not intended to be exhaustive, but representative of items to consider, and does not include personnel costs for such things as development, deployment, training and operation which must also be considered when preparing cost estimates.]
• The proposed components are price competitive.
• The prices from suppliers are assured (in writing) with maximum prices established for the duration of the project.

Application Architecture

• Functionality has been collected and encapsulated so that Client and Server performance can be tuned.
• There is a clear split between presentation, business logic, data management, and application management services.
• The architecture exhibits an object-oriented design.

Performance

• All the assumptions on which performance commitments are based have been documented.
• Modelling or a benchmark of the design has been used to demonstrate that performance requirements (data traffic, throughput, response times) will be met.
• A proof-of-concept with the proposed hardware and communications network has been built to demonstrate that the system will actually work together as designed and with adequate response times.
• The architecture provides sufficient bandwidth for database access from node to node for the critical transactions at peak rates [this is backed up with calculations].
• The architecture provides sufficient bandwidth to meet required response rates for user interface devices communicating with Servers (e.g., through X Windows) at peak loads.
• Key access paths (the ones which will be used 80 percent of the time) have been identified and I/O performance estimated.
• The proposed tools and SDE produce application code which meets performance requirements on a typical end-user's workstation, and at anticipated system loads and database volumes (and proof of this is available).
• The architecture has sufficient printing capacity for peak batch printing demand.
• Potential performance bottlenecks/problems have been highlighted.
• Cost-effective paths for performance improvements have been provided for these problem areas.

Platforms

• All the selected platforms are scalable to accommodate the anticipated growth for n years after the system goes live (or the expected life of the system).
• This includes such things as processor, memory, disk, and communications.
• The proposed architecture conforms to industry standards and de-facto standards.
• The company has experience in developing on, developing for, and operating on, these platforms.
• The proposed components are reasonably mature or based upon mature products.

User Interface

• The user interface provides the appropriate and required mechanisms for accessing and entering data (e.g., GUI, command line, Interactive Voice Response).
• The user interface supports the customer's requirements for integrated training and on-line user aids (e.g., help facilities).
• An accelerated (fast-path) user interface has been considered for experienced users and the proposed development tools support it.
• The architecture has been designed to support a single point of entry (with common access) for all data.
• The GUI tools produce applications which are consistent with the CUA (or similar) standards and consistent with style guides (e.g., Microsoft).
• The GUI tools produce applications which are consistent with the customer's corporate user interface standards (if any).
• The GUI tools support multi-lingual applications, where applicable.
• The proposed tools provide support for interfaces (e.g., transparent support for 3270 emulation, LU6.2, screen scraping) to legacy systems if required (at least as an interim solution).
• Versions of all the customer's standard personal productivity tools are available on the selected workstation.
• A horizontal prototype of the user interface was produced, where feasible.

External Interfaces

• All external interfaces are addressed by the architecture.
• Interfaces and access to legacy systems have been addressed by the architecture.
• Commercial third party tools (e.g., EDI, e-mail) are used for external interfaces.

Connectivity

• The communication architecture is flexible in that it can adapt to various physical media between the Client and Server.
• The communication architecture is flexible in that it can adapt to various communication protocols between the Client and Server.
• The application makes use of standards-based communication protocols, i.e., protocols that have a network layer such as TCP/IP.
• Alternative network configurations have been considered and reasonable justification has been provided for the recommended configuration.
• The network provides extra reliability (if required by the customer) through redundant or alternate routes.
• When networking components are being included, potential future improvements are being accommodated in the design (for example, if UTP is being installed, 100 Mbps-capable cable is being used, or the WAN routers are upgradeable to utilize emerging, improved telecommunications services such as frame relay).
• Maintainability and expansion are adequately considered in the local area and wide area network design and component selection (for example, intelligent hubs and a physical star topology are being used to facilitate fault isolation, or routers are equipped with network management agent software).
• Physical feasibility of providing the chosen WAN has been verified with the carriers for the architecture's geography.
• The risks of the network not being delivered on time have been considered and managed.

Databases

• The architecture supports the use of multiple commercial databases transparently.
• Alternative database technologies (relational, object oriented, hierarchical) have been considered for the application, and reasonable justification has been provided for the recommended alternative.
• The architecture uses a generic database layer (e.g., ODBC, SAG CLI, ODAPI).
• The selected database products provide (as required) tools for:
  Ad-hoc reporting,
  Database diagnostics and performance monitoring,
  Database administration (for a distributed data environment).
• All required database utilities (e.g., backup, query optimization, roll-back, recovery, restore, reorganization, usage statistics, security, audit, transaction logging) are supplied with the proposed database products.
• The proposed products have sufficient capacity (e.g., no limits on number of tables, views, users).
• The proposed products support the requirements for such things as:
  Compiled queries,
  Stored procedures,
  On-line queries,
  Batch queries,
  Query-by-example,
  Bulk data loading,
  Import/export,
  Security (e.g., add/query/delete, record, view, column, data field/value),
  Record locking,
  Triggers and events,
  Replication, two-phase commits, and synchronization,
  Query optimization,
  Declarative referential integrity,
  Updating integrity.
• The data files have been allocated for optimum access (e.g., non-volatile tables on the client for rapid look-up, related tables on a common server).
• Data clustering requirements have been considered to support customer requirements (e.g., geographic level look-up, common queries).
• C. J. Date's Rules for Distributed Data are satisfied by the proposed data architecture:
  Local autonomy,
  No reliance on a central site,
  Continuous operation,
  Independence for: - Data location - Data fragmentation - Replication - Hardware - Operating System - Network - DBMS · Distributed: - Query processing and - Transaction management.

Technology Vendors

• All the products selected for the architecture are from approved technology partners.
• The risks associated with the chosen vendors have been reviewed with, and are understood by, the Customer.
• Contingencies are in place to mitigate the risk of delivery failure.
• The vendors provide adequate support (e.g., telephone hot-line, training, documentation, user group, provisioning logistics for initial rollout or subsequent delivery of software and hardware systems to multiple destinations).
• Sufficient quantities of the proposed components are available today (i.e., the proposed components are not subject to back-order and manufacturing delays).

Software Development Tools

• The tools selected provide:
  A highly productive development environment,
  Low cost deployment.
• Appropriate tools have been chosen for each application (e.g., transaction oriented systems are not being built with a groupware tool, text retrieval systems are not being built with database access tools).
• The proposed tools have been used before within the company and that experience has been considered in the selection of the tools.
• There is a sufficient depth of expertise in the proposed tools available to the team.
• There is sufficient training available locally for the chosen tools and within the project schedule.
• The proposed tools produce software which will operate well on all platforms and integrate with all other (especially communication) components.
• The proposed tools support any customer portability requirements.
• The tools build applications which can be integrated with personal productivity tools on the user's workstation.

Third Party Tools

• Wherever possible, the architecture includes third party tools rather than building applications.
• The proposed third party tools integrate with the rest of the application, in terms of such things as:
  Look and feel,
  Use of user common interface standards,
  Data(base) sharing,
  Data networking,
  Import/export.
• The tools architecture supports integration with personal productivity tools on the user's workstation.

Systems Development Environment

• The proposed SDE tools support:
  the applicable methodology,
  logical and physical modelling,
  data and process model integration,
  normalization,
  data distribution modelling,
  DDL (database schema) definition and generation,
  software version control.
• An existing SDE is being ported from elsewhere in the company and will be used on the project.
• An SDE for the proposed tools is in place, available from the customer or elsewhere in the company.
• The SDE can be customized to suit the particular project environment (e.g., interface to electronic mail, working models and skeletons, standards and procedures).
• The costs for setting up the SDE are reasonable given the size and duration of project.

Systems Management Environment

• The proposed architecture meets customer availability requirements (including fault tolerance if required).
• Each of the FCAPS (Fault, Configuration, Accounting, Performance, and Security) functional areas has been addressed in both the distributed components and the central NOC through inclusion of a commercial network management system using a standard network management protocol (e.g., SNMP, WMI).
• Third party software has been included in the architecture to satisfy SME requirements.
• Tools will be provided (if required) for software distribution.

Provisioning and Logistics

• If the architecture is geographically dispersed, the provisioning logistics have been defined. For example, delivering workstations to multiple locations may require vendor and delivery team planning and management of procurement, warehousing, burn-in, delivery, installation, training, and other activities at every geographical location, both in the initial rollout and later for maintenance and support.
• Business resumption systems (disaster recovery) have been considered in the architecture.