Architecture Review Board

Architecture Review Board

What's an Architecture Review?

Architecture design is not a one-time final work under a project, but a continuous job since it has to develop from AS-IS to TO-BE architecture so it also have been called 'Building Evoluationary Architecture'. It's been impacted by many factors, e.g. environments, compliance, technology trends, client requirements, company strategy and etc.

Architecture review is the process to understand the architecture with its context and scope, identify and evaluate risks, gaps between AS-IS and TO-BE, also help to improve the design.

Architecture Deliverables

To describe an architecture blueprint, we need some architecture deliverables to make it clear to reviewer from brief to details:

• Functional & non-functional (technical) requirements can explian the scope of the system or application we're trying to create/enhance.
• Then architectural design principles helps reviewer what the team focus on and need to stick and implement during design, development, testing, deployment and operaiton.
• Architectural Patterns are the most general ways to resolve main problems.
• Capabilities which required by the requirements, this part may not required by architecture review.
• Components
  * Data Architecture
  * Application Architecture
  * Infrastructure/Platform Architecture
• Some other documents maybe required by some specific area like data modeling e.g. Conceptual Data Model, Logical Data Model and Physical Data Model.

Scope and Context

The architecture should evolve items under project scope and system scope. So context should also include project context and system context.
From project scope, we need to understand:

• Stakeholders include clients, end users, and interactive systems, devices. We also need clear with business process. So we can have an end-to-end solution.

• We need to make clear with integration points bewteen our system to others.

• Project Boundary

• System Boundary

Concerns

• Business (Requirements) Concerns
• Technical (Requirements) Concerns
• Data Concerns
• Compliance Concerns
• Cost and Effort Concerns
• Integration Concerns
• Selection Concerns
• Limiation Concerns

Measure

• Sizing
• Concurrency: Peak

Business Concerns

Acutally all technical and architectural designs are trying to implement the business requirements, so we need to have clear scope of business.

Team need to introduce brief business requirements, and also need to clarify how business growth in future. So we can estimate the sizing and understand the bottleneck may block the scalability of the system.
For business pespective, may require:

• Business solution
• Brief business requirements

Technical Concerns

Need to clarify technical requirements with -illities, e.g. security, performance, scalability, flexibility, operability and etc.
From technical requirements:

• Consider if compoents created can afford live volume and future growth

Data Concern

Since most enterprise application is data-driven in the modern days, so data is the very key of some business. Data architeture is about how to get data, process data, store data, use data, and interact with data.

For some application, data architecture is very important since it needs to integrate with amount of other systems, collect and combine data with relationships. And some other data have been used in a wide ways e.g. meta data, key reference data, transactional data.

• How data store
• How data flow, between systems or inside the main system
• How data filtered and processed
• Data Modeling
  • Conceptual Data Model
  • Logical Data Model
  • Physical Data Model

Compliance Concern

If services are certified and can be used in a secured way.
If data operation is compliant
If development, deployment and operation are compliant

Cost and Effort Concerns

If cost-effective has been considered

• Buying or from sketch
• If there's any existing platoform can save effort and time for runtime and operation
• If any part of the architecture may cause high cost and it's not worth

Integration Concerns

• Integraiton type, e.g. REST API, Web Service, Messaging, File Transfer, Data or Service Bus
• Protocol, e.g. HTTPS or HTTP
• Authentication e.g. OAuth v2 or OpenID
• As an I/O model for integration, we also need to understand input/output with data schema, data formats and types for each field
• If it's a consume model, we need to understand how to handle with server errors and client errors

From security pespective
As a downstream, we need to reduce the attack face which need to close useless protocols, HTTP methods, ports and reject invalid media types. Avoid injected attacks e.g. XSS
How to return

As a upstream, we need to understand how to deal with

Selection Concerns

• If technique, platform, language and framework have been compared with modern, existing

Limitation Concerns

• if there's any limitation may cause issue during development, or after deployment/go-live.