When you are in rush trying to reach a certain project milestone, you might forget important architecture aspects that can dramatically influence the solution in late project’s phases. To mitigate this risk, I developed a architecture checklist that I use to validate that all architecture aspects were addressed. The OpenGroup architecture checklist is a good starting point.
Not every criteria is required for each project. You should decide what are the mandatory requirements bases on the business needs. The list is non exhaustive, please feel free to send me comments on it.
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 realizability
- Are all revelevant 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?
- How componentized is your application? 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 serveless 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 tradeoffs 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?
More detailed checklists:
- Presentation layer checklist
- Web application checklist
- Mobile application checklist
- Rich client application checklist
- Rich internet application checklist
- Service architecture
- Service layer architecture
- Business layer architecture
- Design checklist
- Data access layer checklist
- Communication checklist
- Detailed architecture checklist
Useful artefacts from codeplex.com App Arch 2.0 Figures – ALL.
Sources: opengroup.org, win.tue.nl, apparch.codeplex.com