Selecting Systems

Selecting Systems is the stage where the abstract workflow created in Step 1 becomes a practical blueprint for the platform. Each part of the workflow is mapped to one or more reusable Business Systems from the Innopo Systems Library. This step determines the platform’s functional foundation and ensures the project starts from stable, proven modules rather than bespoke, from scratch features.

System selection is not about choosing templates. It is about identifying which modular capabilities directly support the workflow and which areas require custom logic. The outcome of this step is a clear, version-pinned list of systems that will power the platform’s core behaviours.

Why Selecting Systems Matters

Selecting Systems ensures the platform gains functionality rapidly while maintaining structural consistency. It also prevents unnecessary complexity and avoids rebuilding features that already exist in the library.

Key reasons it matters:

• Accelerates development: Foundational features such as authentication or onboarding are instantly available.
• Ensures architectural consistency: Reusable systems follow shared conventions, making projects cohesive and predictable.
• Reduces engineering effort: Only custom workflow logic is built from scratch.
• Supports modular evolution: System versions can evolve independently over time.
• Creates clarity: Everyone involved knows exactly what the platform consists of and how each part is powered.

What Happens During System Selection

System selection is a structured process that matches workflow needs to modular capabilities. The goal is to cover as much functionality as possible through existing systems while identifying areas that require custom logic.

The process includes:

• Reviewing each step of the workflow and identifying the functional capabilities required.
• Matching workflow requirements to existing Business Systems.
• Identifying new systems that should be created if gaps exist.
• Pinning each selected system to a specific version for stability.
• Confirming how systems will integrate with one another.
• Documenting where custom workflow logic will sit on top of system behaviour.

This creates a clear, actionable map of the platform's foundation.

Version Pinning

Each selected system is pinned to a semantic version at this stage. This ensures that system behaviour remains stable throughout the build and prevents unexpected changes during development.

Versioning rules:

• Patch (x.x.1): Safe bug fixes that introduce no new behaviour.
• Minor (x.1.x): Backward-compatible enhancements or optional features.
• Major (1.x.x): Breaking changes requiring migration steps.

By pinning system versions early, the assembled platform remains stable even as the Systems Library evolves.

Example: Mapping Workflow Steps to Systems

Below is a simplified example showing how workflow steps translate into system selections:

Workflow steps

1. User signs up and verifies email.
2. User completes onboarding questions.
3. Admin reviews submitted information.
4. System generates documents based on answers.
5. Automation notifies user of next steps.

Mapped systems

• Authentication System v1.0.1
• Onboarding System v0.4.0
• Admin Review System v1.1.0
• Document Generation System v0.3.2
• Automation System v1.0.0

Any additional logic, such as approval rules or custom document formats, would reside in the workflow customisation layer.

Identifying Custom Workflow Requirements

Not every part of a workflow will map directly to a reusable system. Workflow-specific logic is documented separately and added later in Step 4. This separation ensures systems remain generic and reusable while custom behaviour remains isolated.

Common examples include:

• Partner-specific pricing models.
• Unique approval flows or escalation rules.
• Branded UI elements and layouts.
• Third-party integrations specific to the partner.
• Internal business logic that cannot be generalised.

Avoiding Overengineering

The goal of this step is not to create the perfect combination of systems, it is to create a practical baseline. Overselecting systems or forcing edge cases into reusable modules can make the architecture more complex than necessary.

Key principles:

• Reuse where possible.
• Customise where necessary.
• Create new systems only when a pattern appears across multiple projects.
• Keep systems generic and workflow logic specific.

Summary

Selecting Systems is the stage where the workflow becomes a functional plan. By mapping workflow steps to modular Business Systems, pinning versions, and identifying custom logic, the platform gains a stable and clearly defined foundation. This ensures that the project is built on proven systems, accelerating development while maintaining architectural clarity.