Skip to content
Contact
Architecture and operations

Built to last, and kept that way.

Architecture and operations, at Codedesign, means designing the structure of critical systems — security, data, integration, hosting — and then running them: monitoring, maintenance, continuous releases and documentation that stays true.

  • Architecture design and review
  • Single sign-on, roles and audit by design
  • Azure or on-premises, observable
  • Maintenance and documented releases

Most failures are decided early and noticed late

The decisions made in the first weeks — how people sign in, where data lives, how services talk — determine what a system will cost to change for years. When they are made implicitly, nobody remembers why, and nobody dares to touch them.

Operations is where software shows how well it was built. A system that nobody monitors, updates or documents slowly becomes a legacy system, however recent its code.

What we do

Design at the start, care for as long as the system runs.

  • 01

    Architecture design

    The structure of a new system — modules, data, integration, hosting — designed around its load, its risks and the team that will maintain it.

  • 02

    Architecture review

    An independent review of an existing system, with the risks ranked by impact and a plan you can act on.

  • 03

    Security by design

    Single sign-on, roles and permissions, audit trails, secrets management, and a security baseline mapped to recognised references such as ISO/IEC 27001 controls and OWASP guidance.

  • 04

    Cloud and on-premises

    Hosting on Microsoft Azure — App Service, Azure SQL, Blob Storage, Service Bus — or on your own Windows servers with IIS and SQL Server, chosen for the system, not for fashion.

  • 05

    Observability

    Logs, metrics and traces, with OpenTelemetry where it fits, that show how the system behaves in production and where it fails.

  • 06

    Maintenance and continuous releases

    Updates, fixes and new features released in small versions, each described in a changelog.

  • 07

    Documentation

    Architecture decision records, operating guides and technical documentation kept current with every release.

How we work

  1. 01

    Assess

    We read the code, the infrastructure and the incident history, and talk with the people who run the system.

  2. 02

    Decide and record

    Each architectural choice is written down as an architecture decision record: context, options, decision, consequences.

  3. 03

    Automate

    Builds, releases and checks are automated, so that a release is routine rather than an event.

  4. 04

    Run

    We monitor, update and release, and report what changed and why.

Principles

  • Decisions in writing

    An architecture decision record for every significant choice, so the reasoning outlives the meeting where it was made.

  • Security by design

    Identity, roles and audit are part of the first design, not a checklist before go-live.

  • Proven where it matters

    Established technologies for the core of the system; newer ones only where they earn their place.

  • Observable by default

    If it runs in production, it produces logs, metrics and traces that someone reads.

  • Small releases

    Frequent, documented releases are safer than rare, large ones.

In practice

An industrial fan manufacturer's production and shipping application runs on Azure with single sign-on and has reached 68 releases, each documented in a changelog. Read the case study. For a luxury cruise line we built a platform of 36 back-end services on Windows Server, IIS and SQL Server, with scheduled jobs and Microsoft Entra ID sign-in with two-factor authentication. Read the case study.

Further reading

Questions we are asked

What is an architecture decision record?

An architecture decision record (ADR) is a short document that captures one significant technical decision: the context, the options considered, the choice made and its consequences. Kept alongside the code, ADRs let a team understand years later why a system is built the way it is. One of Codedesign's current projects has 25 of them.

What does an architecture review include?

An architecture review examines the code structure, data model, integrations, security, hosting and operations of an existing system, based on the code itself and on conversations with the team. The result is a written report with the risks, their likely impact and a prioritised plan.

Do you work on Azure or on-premises?

Both. Codedesign delivers systems on Microsoft Azure (App Service, Azure SQL, Blob Storage, Service Bus) and on clients' own Windows servers with IIS and SQL Server. The choice depends on data, integration and cost, not on preference.

What does security by design mean in practice?

Security by design means that identity, permissions, audit trails and data protection are designed into a system from the start. In practice: single sign-on with two-factor authentication, roles defined by function, every sensitive action logged, and a security baseline mapped to references such as ISO/IEC 27001 controls and OWASP guidance.

Can you maintain software you did not build?

Yes, after an initial assessment. Codedesign reviews the code and the infrastructure, documents what it finds, sets up monitoring, and then takes over maintenance and releases step by step.

Architecture and operations

Is there a system nobody dares to touch?

That is usually the right place to start. Tell us about it, and we'll propose how to assess it.

Request a private meeting

Email

info@codedesign.it