Case Study: Architecting COMSOL for a Managed Engineering Environment

Specialized engineering software creates a different class of architecture problem.

A tool such as COMSOL is not simply another business application. It combines specialist software, engineering models, potentially intensive computation, large datasets, licensing requirements, and a user experience that can depend heavily on the underlying compute environment.

That makes a straightforward cloud architecture difficult.

The starting point was an existing engineering use case that needed to be made more deliberately manageable. The challenge was to determine how the software, users, compute, data and supporting infrastructure should fit together without treating the entire workload as one application component.

The architectural challenge

A first instinct is often:

Put the application in the cloud and give users access.

That skips the important questions.

Where should the application actually run?

Where should computational workloads run?

Where are engineering models and results stored?

How is software licensing handled?

How do users get access?

What happens when compute requirements increase?

Which components need to be persistent, and which can be provisioned only when required?

And who is responsible for operating the environment once it is in use?

For specialist engineering software, these decisions are coupled. A technically valid cloud design can still provide a poor engineering experience if the compute model, storage or user access path does not match the workload.

Separating the concerns

The architecture was therefore considered as several distinct building blocks rather than one “COMSOL environment”:

                Users
                  │
                  ▼
          Managed user access
                  │
                  ▼
        ┌───────────────────┐
        │ Engineering       │
        │ application       │
        │ environment       │
        └─────────┬─────────┘
                  │
          ┌───────┴────────┐
          ▼                ▼
      Compute           Model / data
      resources          storage
          │                │
          └───────┬────────┘
                  ▼
          Supporting cloud
          infrastructure

This separation makes it possible to reason about the workload independently.

The user-access layer answers who can use the environment and how.

The compute layer answers where the engineering workload runs.

The data layer answers where models, inputs and results live and how they are retained.

The supporting infrastructure provides the networking, identity, security and operational controls around it.

That distinction becomes important when one part of the architecture needs to change without unnecessarily changing everything else.

The cloud is not automatically the answer

One of the architectural lessons from specialist software is that cloud adoption should follow workload characteristics rather than the other way around.

An interactive engineering application may have very different requirements from a stateless web application.

Latency, CPU and memory requirements, storage performance, user experience, licensing and workload duration can all influence the design.

That means the architectural question is not:

“How do we put COMSOL in AWS?”

It is:

“Which parts of this engineering workload benefit from cloud infrastructure, and under what constraints?”

That shift in question leads to a much more defensible design.

Designing for controlled use

A second challenge is preventing a specialist environment from becoming an unmanaged exception.

Engineering teams need freedom to work with specialist tooling, but the environment still needs clear boundaries around access, security, data and lifecycle.

The solution therefore needs to be treated as a managed engineering capability, rather than as a server with COMSOL installed on it.

That means explicitly defining:

• who can access the environment;
• what data can enter it;
• what the environment is intended for;
• how resources are managed;
• how the environment is monitored;
• who operates it;
• and how it is eventually changed or retired.

This is where solution architecture connects the engineering requirement to the broader enterprise architecture.

HLD first, technical design second

The High-Level Design establishes the architectural choices and boundaries.

It should answer questions such as:

What is the purpose of the environment? What are its boundaries? Which components are shared and which are dedicated? How is access controlled? Where does data reside? What are the operational responsibilities?

The implementation can then be worked out in one or more Technical Designs.

For example, separate TDs can cover the cloud environment, user-access architecture, networking, or the detailed deployment of the engineering application.

This keeps the HLD at the right level while giving engineers enough freedom to determine the implementation.

The real architecture problem

The hardest part was not selecting a cloud service.

It was creating a design that respected the reality of specialist engineering work while still fitting into a managed enterprise environment.

That requires balancing:

engineering usability with security and governance

and:

specialist workload requirements with standardized cloud and operational management

The result is a pattern that can be reused for other specialist workloads as well. The technology may change, but the architectural questions remain largely the same.

Key insight: Specialist engineering applications should not be architected as isolated software installations. Treat the user experience, compute, data, licensing, security and operations as separate architectural concerns, then connect them through a deliberate HLD.