Discipline 01

Software Engineering & Enterprise Systems

We design and engineer business applications around the way organizations operate.

The challenge

What this discipline addresses.

Operational software most often fails because it was built around a feature list rather than the way the work happens. We begin with the operation, including its exceptions, and engineer the application around it.

  • Records are spread across registers, spreadsheets and individual knowledge.
  • Off-the-shelf software forces a process the organization does not follow.
  • A legacy system remains critical to the business but is risky to change.
  • Management information is available only at month-end.
  • Changes to records cannot be traced to a person or a time.
Services

What we deliver.

  • Custom software development
  • Enterprise resource planning systems
  • Business management applications
  • Workflow management platforms
  • Web application development
  • Mobile application development
  • Database-driven applications
  • Legacy system modernization
  • Software maintenance and enhancement
OperationData modelIncrementsHandoverFEEDBACK
Reference architecture, for illustration.
Engineering approach

How we do it.

  1. Map the operation

    We document how work moves today, who owns each step and where it breaks, before proposing any screen.

  2. Model the data

    Data outlives code. We settle entities, ownership and audit requirements early.

  3. Deliver in increments

    Working software reaches your staff in stages, so errors in understanding surface while they are cheap to fix.

  4. Migrate and hand over

    Existing records move with reconciliation. Staff are trained and the system is documented.

Typical engagements

Where we usually start.

  • A college moving admissions, attendance and grading off paper.
  • A retail operation that needs stock, sales and reporting in one system.
  • An organization replacing an unsupported application without stopping work.
Related case studies

This discipline in practice.

Questions

Frequently asked.

Should we buy software or build it?

Buy when your process is standard and a product fits it. Build when the process is what sets you apart, or when adapting a product would cost more than the product. We will tell you if an off-the-shelf option is the better answer.

Who owns the software?

Ownership of code and intellectual property is set out in the agreement for each engagement. Agree it before work begins, and we will put the terms in writing.

Can you take over a system someone else built?

Usually. We start with a code and infrastructure review so you know its condition before committing to further work.

Discuss your software engineering requirement.

Describe the requirement and the constraints you are working within. We will assess it and advise candidly on whether and how we can help.

Discuss a Project