Business software objectives: priorities and trade-offs

Software systems are vital in businesses - little works without them - but we don't always stop to think about their objectives. Systems often have multiple objectives as the recent issues at NATS illustrate. This article explores business system objectives and their importance, particularly during the design phase.

Software systems are the oil that enables modern business to work smoothly. Often, it’s when things go wrong that we realise just how important they are. Only last month the UK headlines were dominated by air traffic control problems. Queues in airports, people sleeping on the floor, questions in the House. It wasn’t good.

Any mention of NATS in the news catches my attention. We built a system for NATS and worked closely with some of their engineers. The people we worked with were dedicated and thoughtful about how to improve systems and information flow.

Whilst all software can contain defects, not all software has to manage safety in quite the way that air traffic control must. The preliminary investigation report from NATS revealed a defect in a legacy system, hidden until a very specific timing issue caused data corruption. This resulted in systems behaving as they should under these circumstances, requiring air traffic controllers to manually undertake some tasks. This reduced the air traffic service that could be delivered, resulting in cancelled flights, delayed flights, and headlines across the news.

They had procedures in place to manage the situation. These had already been practised and were followed when needed. In an imperfect world, safety was maintained, which was the key objective. 

Although businesses use many different systems, they all have objectives. Whilst the UK’s air traffic control system might be atypical, it too has objectives, including safety. But safety isn’t the only objective. Their systems also have to be efficient and accurate. 

Software systems can help you to get things done faster, cheaper, and better than your competitors, and understanding a system’s objectives is part of that. Had NATS prioritised efficiency and cost over safety, the headlines could have been very different.

When we stress the importance of thinking carefully about the business objectives for a new system, it is with good reason. Objectives may not be obvious, but careful thought in the early stages will pay dividends later.

Seven system objectives

1. Time. Reducing the length of time a process takes. 
2. Cost. Reducing the resources consumed, such as staff time or money. 
3. Quality. Improving accuracy and reducing errors and omissions.
4. Consistency. Making sure the process is carried out the same way every time. 
5. Visibility. Consider who needs information, how current and accurate the information needs to be, and how it should be presented. 
6. Risk/safety. The definition of risk or safety depends on the business. 
7. Flexibility. Accommodating exceptions, unexpected circumstances and planned changes. The degree of flexibility required can affect other system objectives.

Systems may have more than one objective, and sometimes objectives conflict. Being clear about what is most important can have a bigger impact on the success of a system than many people realise. 

Recognising that trade-offs are sometimes required helps everyone understand the impact of their decisions, particularly during the design phase of a new system. For example, increasing the flexibility of a system can add to costs and complexity. Improving consistency may reduce flexibility. This depends on how a system is designed, of course, but still needs to be considered.

In the age of AI, understanding risk, safety, automation, and when people need to intervene will only become more important. Drop your ideas in the comments about systems objectives, and when they support business goals. Or not.

And if you think one of your systems needs some attention, get in touch for a preliminary chat. It costs nothing but might make a difference. 

Who is to blame?

When someone makes an expensive mistake, it’s easy to react. 

“Who is to blame?” 
“Who do they report to?” 
“How did you let this happen?"

Blaming someone isn’t difficult. Sometimes the person themselves thinks it’s their fault. 

But a more useful question might be:

“Which system allowed this to happen?”

Quite often we already know there are flaws in the system. Or there’s no system where there should be one. Yes, there are always exceptions, but dig deep enough and often there’s a sub-optimal system somewhere.

What is a system?

Systems are everywhere. Some we recognize as systems, such as the accounts payable system, or the payroll system. They have names and often have software to make them work. 

Other systems are less obvious, or even invisible.

Think about how you start your day. Is that a system? 

It doesn’t have a name and may or may not involve software. You might start by switching on your computer, scanning your email for important messages, figure out what’s urgent or outstanding, then decide what you want to achieve that day. 

That’s a system, just not an obvious one. 

Systems thinker Daniel Kim defines a system as:

“Any group of interacting, interrelated, or interdependent parts 

that form a complex and unified whole that has a specific purpose.”

That definition gives us four things:

• Parts – different elements within the system, including people.
• Relationships – how the parts interact and depend on one another. 
• A unified whole – a recognizable system with boundaries and outcomes. 
• Purpose – its reason for existing.

It’s a decent starting point when figuring out whether something is a system or not. Not whether it’s a good system, just whether it’s a system.

Identify the system that’s to blame

Once you can identify and recognize a system, you can start to improve it. You can optimize it, fix it, or create a system. 

Preventing the same mistake happening again may be more important than playing the blame game. Well-designed systems help people do a good job, not just once but every time. Which is worth a lot.

Poorly designed systems make mistakes possible or inevitable.

Start with objectives

A system that delivers the intended business benefits starts by understanding the system you're trying to improve. Only then do you decide whether the answer is new software, better data, improved reporting, applying AI, or a better way of working.

That's how we've always approached projects, and it's why we start every discussion with the same question:

“What are you trying to achieve?”

We are software engineers who specialize in implementing Microsoft technologies. Only by understanding what you are trying to achieve can we design a system that is right for your objectives and your organisation. For us this is fundamental, and in the long run will be a major factor in the success of the system. 

If you are concerned that some aspect of your systems is letting you down, get in touch. It costs nothing to find out if our skills could help.

Small bets, big wins

The most successful systems we’ve developed began with a Visionary.

Not always someone with a grand title, just someone doing their job who saw a better way. Not just better for themselves, but for their team, and the organisation.

We call them Visionaries because plenty of people notice problems, but very few actually do something.  But then a lot of ideas aren’t worth the effort. The hard part is knowing when one is.

From idea to system: the process

When a Visionary comes to us with an idea, we follow a simple discipline:

1. We understand what they want to achieve — and whether we’re the right people to help. Not every problem needs a system, and not every system needs us.
2. We design a high-level architecture. A good system with a poor architecture will almost always fail.
3. Then we build a prototype — a deliberately small part of the system. This is often to test out a high-risk area, but it could also be part of the UI so people can see how it would work. But it’s always limited, and always designed to move the thinking forward.

The power of the prototype

Today this is often called a proof of concept. Sometimes it’s just “let’s see if this works”.

Names don’t matter. What matters is that the prototype tests whether something actually works — technically, operationally, or commercially. (In theory there’s no difference between theory and practice. In practice, there is.)

Because it’s a small bet, it can be thrown away. We often throw several prototypes away, because each one is small. But each time, we’ve learned something and the next step is clearer. We might refine a prototype or build something else. Each is a small bet, designed to reduce risk and build confidence.

Eventually, the prototype stops being a prototype and becomes a system. The Visionary can get budget to develop it further because everyone can see how it will work. 

Do you have a visionary idea?

Many of the systems we’ve built have gone on to have long, productive lives. Mostly well after the original Visionary has moved on. They didn’t know at the start whether their idea was large or small; they only found out by making small bets.

If you have an idea that might be a better way, and want to explore it further, let’s have a conversation.

A light-weight way to solve heavy data problems

Most people want more from their data, but knowing how best to use it can be difficult. There’s always a question mark over whether the development effort will have a big enough pay-back. Smart leaders know that everything has a cost – in management attention and budget.

But doing nothing is not the answer. Data-driven organisations are out-performing those less skilled in data analysis. So, what’s the answer? 

At Anatec AI we are big fans of the proof of concept or prototyping. The idea is to do a relatively small amount of work that does a lot of heavy lifting. It might focus on analysing a limited amount of data to assess the data quality. Or it might be to test out a theory on how two data sources could identify patterns. Or it might be a difficult interface that absolutely has to work for the solution to be a success. Each project will be different, because each problem is different. The approach, however, is consistent: do a small amount of high-risk work that tells you whether or not you are on track. 

The cloud provides a great way of doing light-weight small projects – you don’t need to buy servers or install operating systems. You don’t need to commit up-front. You can just use the cloud’s in-built flexibility to do just as much as you need to do, then decide what to do next. This is a lot safer, and easier to justify than ambitious projects that can end in mediocre results.

Azure containers are a great fit for that way of working. They are reliable, whether running locally or in the cloud. And they can securely access data that’s held in databases, cloud storage, queues or APIs. Of course, containers are just one example of a light-weight approach to our small-project ethos, but they are a good example of how smart Azure technology can produce big results at a small cost. 

The Anatec AI design approach underpins everything we do when architecting modern cloud systems. Our solutions need to be reliable, portable, and consistent across environments - and developed one bit-sized step at a time. Because our clients need to be in charge of the direction of the project and the budget, not the technology.

Do you want to get more from your data without breaking the bank? As qualified Microsoft developers, we’ve got a whole toolbox full of Azure tools to engineer data-driven solutions. If you’ve got an idea for your data that might be a game-changer, get in touch to find out more about how we work.

Keywords: Azure, containers, proof-of-concept, cloud native, data analytics, Azure AI

Three steps to optimising learning at work

Whilst everyone agrees that learning at work matters, not all organisations are good at knowing whether their learning programs actually work. That’s because optimising learning is messy. It needs data from multiple systems, departments, and stakeholders.

Historically, L&D hasn’t rushed toward that complexity. But that’s changing.

Three things have shifted the landscape:

1. Learning management systems (LMS) are now widespread, and they hold large amounts of learning data.
2. Cloud platforms enable data to be combined and analysed without the need for huge data warehouses. That makes learning analytics projects much more cost effective.
3. AI tools are available off the shelf and viable for small, focused experiments.

The result is that learning analytics is no longer theoretical or reserved for large enterprises. It’s affordable, practical, and increasingly hard to ignore.

So where do you start?

What is learning analytics?

It’s always useful to start with a definition, and learning analytics is pretty straight forward:

Learning analytics improves learning outcomes by analysing data.

It may not be complicated, but it’s still useful. And it also gives you the correct order to do things - an order many organisations still get wrong.

Step 1: Define what “better” looks like

You don’t start with data. You start with outcomes. What are you actually trying to improve?

• Fewer errors?
• Higher sales?
• Faster onboarding?
• New skills that are being used in day-to-day work?

There is no universal answer. It will depend on the business context and the problems you’re trying to solve. But until you can clearly describe what success looks like, analytics will only produce dashboards, not insight.

Step 2: Decide how you’ll measure improvement

If you can’t agree on a measure, you can’t tell whether learning made any difference.

Choose metrics that reflect the outcome you care about, and that you can actually measure. That might include:

• Knowledge gained
• Reduced error rate
• Skills demonstrated
• Business performance indicators

Your metrics don’t need to be perfect they just need to be useful. The goal is better decision-making, based on data.

Step 3: Identify the data that supports those metrics

Most organisations already collect far more data than they use: LMS activity, course attendance, assessment results, feedback surveys, HR data, performance metrics. The problem isn’t that the data doesn’t exist, it’s that it’s siloed. 

When data from multiple systems is brought together, patterns start to emerge. Training volume alongside retention. Learning pathways alongside performance. Timing of learning alongside error rates.

Putting it into practice

This approach works best when treated as iterative. Small proof-of-concept projects using modern business intelligence tools and AI can deliver fast feedback on existing learning initiatives.

You don’t need a multi-year transformation. You need a focused question, a clear metric, and enough data to test whether your learning is actually helping.

If you are looking at getting more from your learning data, and improving learning outcomes, get in touch for a no-obligation chat. 

Keywords: learning analytics, data analytics, learning management system, LMS, Power BI, L&D dashboard, Azure AI