Designer

You know where you want to go.
Now you need to know what to build.

You have requirements, constraints and a direction. We turn them into a concrete cloud infrastructure design that can actually be implemented.

For new environments, migrations and substantial changes to existing infrastructure.

Different starting points

You may already know the destination without knowing the route.

◇

We need somewhere to run this

A new application, service or business needs its first production environment.

◌

We have chosen cloud, but not the architecture

The strategic decision has been made. The practical infrastructure choices have not.

→

We need to move what we already have

Existing systems need a new home without unnecessarily disrupting what already works.

≋

Our current setup needs substantial change

The requirement is no longer a small operational adjustment. The environment needs to be reconsidered and redesigned.

⚑

We only need to get this far — for now

A migration or transformation does not have to reach some theoretical final state. We can design the next agreed destination.

From requirements to design

From requirements to something you can build.

We work out what the environment actually needs to look like.

That can include decisions about compute, storage, networking, databases, availability, scaling, security, backup, recovery, connectivity and other infrastructure concerns relevant to the environment.

But the objective is not to produce the most elaborate architecture possible. It is to produce an infrastructure design that fits the actual requirement.

Enough architecture to make good implementation decisions.
No architecture for architecture’s sake.

Requirements & constraintsBusiness needsConstraintsDependenciesPreferences

→

Concrete infrastructure design

ComputeContainersStorageDatabases NetworkingDNSIdentityScaling AvailabilityRecoveryMonitoringSecurity

How Designer works

From question to design.

Understand

What are you building or changing, and why?

We look at the problem, its context and what already exists.

Define

What must the environment do?

We establish the requirements, constraints and dependencies that matter.

Design

Make it concrete.

We translate those requirements into concrete infrastructure choices and architecture.

Validate

Does the design hold together?

We check whether the proposed setup is coherent, implementable and appropriate for the requirement.

Decide

What happens next?

You now have enough information to decide how implementation should proceed.

A deliberate decision point

First design.
Then decide who builds it.

Before enough design work has been done, it may be impossible to responsibly estimate the implementation.

We don’t hide an insufficiently understood build behind an attractive fixed price. We first design deeply enough to understand what needs to be realized.

Then you decide what happens next.

Option A

Build it yourself

You receive a sufficiently concrete design for a competent implementation team to understand what is intended and implement it.

That may be your own team or another provider.

The design can be the completed engagement.

Option B

Have us build it

If you want us to implement the design, we can scope and propose that work based on what is now actually known.

The engagement can then continue through implementation to a working environment ready for its intended use.

No predetermined stack

The design follows the workload.

Depending on what the environment needs, the design may include:

Compute Containers Storage Databases Networking DNS CDN Identity & access Scaling Availability Backup & recovery Logging & monitoring Connectivity Security controls

We select the services and infrastructure components that make your infostructure work better.

Different problems

Starting fresh or moving something existing.

Starting fresh. There may be no legacy infrastructure to preserve. The important questions concern requirements, expected use, growth, resilience, cost and sensible operational complexity.

Moving. Existing systems introduce dependencies, continuity requirements, sequencing and migration risk.

The destination is the place we agree to reach — not necessarily some imagined final state of the entire infrastructure.

Already started?

That’s fine.

You may already have architecture diagrams, technical preferences, partial implementation work or decisions that cannot reasonably be changed.

We don’t require an empty page.

We start with what exists and determine what is still needed to reach an implementable design.

Adjacent needs

Design rarely exists in isolation.

Not sure about the direction yet?: We can help establish that too.
Specific compliance requirements?: We can incorporate them as design inputs and help assess and evidence them.
Something in the existing environment needs improving?: We can investigate what is actually worth changing.
Need practical changes afterwards?: We can handle the cloud infrastructure work too.