Architectural Review Package
Architectural Review Package
Before purchasing enterprise software, large companies conduct an internal architectural review: the business-side customer, together with the corporate architect and the information security department, presents the solution to a committee. To present the solution, a set of artifacts is required β typically, an article in the company's internal wiki describing the system, diagrams, and requirements.
This section compiles everything usually required for such a presentation in a ready-to-copy format. The materials are the same for all customers: they describe the system itself, not a specific installation. Anything pertaining to your organization β installation size, data classification, target recovery metrics β is to be filled in by you; for each such item below, the source of the initial data is indicated.
How to use this section
Copy the necessary pages to your wiki and supplement them with data from your installation. Diagrams are provided in SVG format β you can insert them into the document as is or redraw them in your accepted notation, relying on the data flow tables.
What is included in the package
| Artifact | Page | What it covers in the review |
|---|---|---|
| Processes within the system and Data Flow Diagrams (DFD) | Processes and Data Flows | "What the user does in the system", Dataflow Diagram |
| Role model, privilege matrix, RACI | Role Model and RACI | Access control, RBAC, RACI |
| Account lifecycle | User Management | User and access management processes |
| Catalog of functional requirements | Functional Requirements | Functional Requirements, scope of implemented functionality |
| Solution summary card and non-functional requirements | System Design and NFRs | System Design, Non-Functional and Support Requirements |
| Component diagram | below | Application Components Diagram |
System Overview
Ready-to-use text for the "System Overview" section β can be copied without changes.
Stormbpmn is a platform for describing, approving, and maintaining the currency of an organization's business processes. Users model processes in BPMN 2.0 notation and other supported notations, maintain a process registry with attributes and statuses, link processes to the org structure, roles, and IT architecture elements, approve models with stakeholders, and publish approved versions for read-only access.
The solution is delivered as a web application in a container and deployed on the customer's infrastructure (on-premise or in a private cloud). Users work through a browser; no separate client is installed. The system uses external customer components: a PostgreSQL relational database, an S3-compatible object storage, a corporate authentication server using the OIDC/OAuth2 protocol, and a mail server.
Additional information for the application card β deployment model, license type, component composition, and version β is provided on the System Design and NFR page.
Component diagram
| No. | Component | Purpose | Requirement |
|---|---|---|---|
| 1 | nginx load balancer | HTTPS termination, HTTP and WebSocket proxying to the application | Required in production installation |
| 2 | StormBPMN application | Core service: interface, REST API, business logic, background jobs | Required |
| 3 | Storm DES simulation module | Process simulation modeling | Optional, separate license |
| 4 | PlantUML, Gotenberg, ListMonk | UML diagram generation, document conversion to PDF, templated email campaigns | Optional, by feature |
| β | PostgreSQL 14+ (16β17 recommended) | Storage of all platform data | Required |
| β | S3-compatible storage | Files, attachments, model previews | Required |
| β | Redis | Collaborative editing with multiple application instances | Required only for multiple instances |
| β | Corporate IdP | User authentication via OIDC/OAuth2 | Recommended; built-in authentication available |
| β | SMTP server | Emails: invitations, approvals, notifications | Required for notifications |
| β | Prometheus, Grafana | Metrics and alerts | Recommended |
| β | SIEM or log collector | Receiving action logs via syslog | Recommended |
| β | LLM provider | AI assistant functionality | Only when using the AI module |
Detailed requirements for each component are provided in the Installation and External services sections.
Compliance with the standard application card structure
In internal company wikis, the application card is typically built using the same schema. Below is where to source the content for each of its sections.
| Application card section | Source |
|---|---|
| Brief description | Above |
| Functional requirements | Functional requirements |
| Non-functional requirements | System design and NFRs |
| Support and maintenance requirements | System design and NFRs |
| Application component diagram | Above |
| Data flow diagram | Processes and data flows |
| System design (table "category β solution") | System design and NFRs |
| Infrastructure diagram | Built by the customer for their own environment; source data β Architecture diagram and Installation |
| Service accounts | System design and NFRs |
| Constraints | System design and NFRs |
| Installation instructions | Installation, Quick start |
| Backup and restore | Maintenance, Monitoring and backups |
What to Request from the Vendor
Some data for the review depends on the contract and cannot be published in advance. This information is provided by your project manager β write to help@stormbpmn.com:
- a letter specifying the license scope and validity period, as well as the renewal procedure;
- support details: mode, channels, and target response times;
- confirmation of the composition of personal data processed for your use case;
- access parameters for the container registry and the procedure for verifying image signatures (Cosign);
- if necessary β completion of your information security departmentβs questionnaire.
Pre-Review Preparation Checklist
- Copy the brief description and the catalog of functional requirements, and cross out the features that you are not implementing in the first iteration.
- Take the diagrams from DFD that correspond to your scenario, and redraw them in the adopted notation if necessary.
- Fill in the system design card with the values of your installation: OS version, size, authentication method, integrations.
- Determine the data classification and the composition of personal data for your environment β see processed data.
- Agree on the target RTO and RPO and the backup schedule with the operations service.
- Assign roles according to RACI and agree on who in the organization grants permissions in the system.
- Attach the infrastructure diagram of your site and the list of service accounts.