Skip to main content

Core systems and enterprise solutions

One system that runs the organization's day to day work, connected to everything it needs, and built to last for years.

Two people drawing a diagram on a whiteboard with an orange marker, placeholder photograph

The problem this solves

In a large organization the work spreads across systems built in different eras. Some data sits in an older system, some in spreadsheets that one person maintains by hand, and some at an outside supplier. Every operational process means moving data between places, and every small change gets stuck.

An off the shelf system does not always fix that, because the process the organization works by is what gives it its edge. We build the system around that process and connect what already exists to it.

The second requirement is availability. A core system that goes down stops the work of hundreds of people, so the architecture is built up front to stay up.

How Target runs such projects

We either own the project end to end, or join the client’s existing team and work alongside it. Both ways are fine with us, and we agree on which one at the start.

We begin the specification with the people who actually use the system, not only with management. The architecture follows: separation between components, a permission model, and the way external systems connect. Development moves in versions, with code review, a fixed code standard, and a test environment that mirrors production.

After going live the long part starts: monitoring, incident handling, version upgrades and further development for whatever the organization needs next year.

Example project

For one client we develop and run a system that holds a wide operational activity in one place, with integrations to large institutional bodies and to strategic partners. The system runs in production and keeps growing against new needs every year.

How a project starts

  1. 01 Project ownership

    We either own the project end to end, or join the client's existing team and work alongside it. We agree on which way to work at the start.

  2. 02 Specification and architecture

    The specification is written with the people who actually use the system. The architecture follows: separation between components, a permission model, and the way external systems connect.

  3. 03 Build and production

    Development moves in versions, with code review and a fixed code standard. After going live there is ongoing monitoring, incident handling and further development.

Questions we get asked

Can you take over a system somebody else wrote?

Yes. Much of our work starts inside existing code. We read the system, map its dependencies and its risk points, and make small changes before we touch the core.

How long does it take to get a core system live?

It depends on scope. Specification and architecture usually take a few weeks, and then we go live in stages: a first module in production, then more. A working version early beats one large launch.

What happens after the system goes live?

We stay. Ongoing support, monitoring, incident handling and further development. Our leading clients have been with us for more than 15 years.