Technology should be the result of the strategy. 
Not the starting point.

Most technology projects don’t begin with a blank sheet of paper.

There is usually already an idea of the answer: A platform someone has seen advertised. A system used elsewhere. A manufacturer already within the estate. A specification inherited from an earlier project.

Sometimes that instinct will be right. But what happens if the solution is chosen before the problem has been fully understood?

An organisation can procure exactly what it asked for and still not achieve what it wanted.

That distinction matters because the strongest technology strategy rarely starts with the technology itself. It starts with the organisation: its people, its environment, its objectives, its risks, the technology it already owns and the way all of those things need to work together.

The technology should be the result of the strategy, not the starting point.

When ‘working’ isn’t the same as ‘working well’

Technology rarely becomes ineffective overnight. More often, the organisation gradually grows around it.

A new system is introduced to solve one requirement. Another platform follows a few years later. Teams change. Buildings change. Working practices evolve. A manual process appears here. Another interface is added there. People learn which systems don’t communicate and find ways to compensate for them.

Over time, those compromises become normal. Nothing necessarily feels broken.

Doors still open. Meetings still happen. Cameras still record. Networks still connect. Buildings continue to operate.

But “not broken” and “working as well as it could” are very different standards.

The more useful question is not simply whether the technology works. It’s whether it is helping the organisation work better.

That might mean asking whether:

• Teams could have greater visibility across the organisation
• Manual processes could be reduced or automated
• Information held in separate systems could become more useful when considered together
• People could have a simpler and more intuitive experience
• Existing technology could deliver more value as part of a better connected environment
• Today’s technology decisions leave enough flexibility for what the organisation may need tomorrow

Sometimes an organisation becomes accustomed to what it has because it’s never had reason to consider what might be possible instead.

That gap between current capability and potential outcome is where technology strategy becomes valuable.

Start with the outcome, not the specification

A specification can tell us what someone believes they need. It doesn’t always reveal the problem they’re trying to solve.

If that distinction is missed, an organisation can make a perfectly competent purchasing decision without necessarily making the best strategic one.

Before deciding on products, platforms or manufacturers, the questions need to become broader:

• Who will use the technology?
• What needs to become easier, safer or more efficient?
• What information would help people make better decisions?
• Which existing systems are performing well?
• Where are the gaps or frustrations?
• What needs to communicate with what?
• What does success actually look like?
• How might the organisation, its people or its environment change?

A solution designed solely around today’s requirement can become tomorrow’s constraint.

This is where taking a more holistic approach to workplace technology can help shift the conversation away from individual products and towards the wider operational and technical requirement.

The discovery process may ultimately confirm the original specification.

But it may also challenge it.

A request to replace a system might reveal that the technology itself is perfectly serviceable and the real problem sits elsewhere. A standalone requirement might create greater value if connected to another system. An ambitious integration might sound impressive but add complexity without delivering enough operational benefit to justify it.

The purpose of technology strategy isn’t to make the solution bigger. It’s to make the outcome better.

Vendor agnostic does not mean multi-vendor

This is where vendor choice becomes interesting.

At iwGROUP, we’re vendor agnostic. But for us, that doesn’t mean recommending multiple manufacturers for the sake of remaining vendor agnostic.

It means something much more useful: the freedom to determine the right architecture before determining the manufacturer.

The value of that approach is not measured by how many manufacturers appear in the final design. It’s the ability to assess the requirement without being constrained by one product or portfolio before the wider architecture has been determined.

In some environments, selecting the strongest technology for different requirements can create a more capable overall solution. It may allow an organisation to retain systems that continue to perform well while introducing new capabilities where they add real value.

In others, a single manufacturer’s ecosystem may be the better strategic choice.

A unified platform can simplify management, reduce the number of interfaces teams need to navigate, provide greater consistency and create a clearer view across multiple systems. Native integration may also reduce complexity and make ongoing support more straightforward.

Neither should become an ideology. The strategic decision is being able to choose between them.

That means resisting two equally limiting assumptions: that one ecosystem must always be simpler and better, or that combining best-in-breed technologies must always produce the right solution.

Both can be right | Both can also be wrong | The requirement has to decide.

Integration should make something better

Integration is another word that can sound inherently positive, but connecting two systems doesn’t automatically create value.

The more important question is:

What is improved if they work together?

Connecting an access event with relevant video might provide useful context. Sharing occupancy information with building systems might help the environment respond more intelligently to how space is used. Data that previously existed in isolation might help facilities teams identify patterns or make better operational decisions.

Those are outcomes.

Integration is simply the mechanism that helps deliver them.

That distinction becomes particularly important as interoperability, open architecture, third-party integrations and accessible APIs create more opportunities for technologies from different manufacturers to exchange information or trigger actions.

The UK Cabinet Office’s architecture principles advocate interoperability and open standards while also recognising that different vendors can offer advantages from which organisations should be able to benefit.

It’s an important balance.

Open architecture can provide greater flexibility. Third-party integrations can extend capability. APIs can create possibilities for systems that were not developed by the same manufacturer to communicate.

But possibility is not the same as suitability.

An available API doesn’t guarantee meaningful interoperability. The depth, security and reliability of an integration depend on what the respective systems expose, how information is exchanged, how the integration is implemented and supported, and whether it serves the operational requirement.

Technical compatibility doesn’t automatically equal strategic suitability.

So rather than asking only:

“Can these systems integrate?”

The better question may be:

“What becomes better if they do?”

That keeps integration focused on the outcome rather than the technical achievement.

This thinking can also be applied specifically to integrated workplace security, where the value often comes not from individual security technologies in isolation, but from how effectively they work within the wider environment.

One pane of glass or the right technology for each requirement?

The appeal of a single pane of glass is easy to understand.

One environment. One interface. Greater visibility. Fewer disconnected systems for teams to navigate.

Where a single ecosystem meets the requirement well, those benefits can be significant. This is precisely why vendor-agnostic and integrated should not be treated as opposites.

A genuinely vendor-agnostic process may conclude that one manufacturer’s integrated ecosystem is the right solution.

Equally, it may conclude that different technologies should be brought together because the organisation gains more from their individual capabilities than it would from standardising around one portfolio.

The danger comes when either decision is made too early.

A single interface shouldn’t become the objective if achieving it means compromising an important capability, unnecessarily replacing technology that continues to perform well or creating a dependency that restricts future choice.

But choosing multiple best in breed technologies isn’t automatically the answer either. If the result requires complex or poorly supported integrations, several management environments and disproportionate support, the theoretical advantage of choosing each component independently can quickly disappear.

Our recent Insight on physical AI in the built environment explored the other side of this question: the potential advantages of bringing multiple capabilities together within a unified environment.

The same principle applies here.

The question isn’t:

“One vendor or many?”

It’s:

“What architecture will deliver the right outcome for this organisation?”

Your existing technology is part of the answer

Technology strategy is often discussed as though every project starts from scratch. In reality, almost none do.

Organisations already have networks, security platforms, AV systems, building controls, devices, software, contracts, data and established ways of working.

And somewhere within that estate will usually be technology that is performing extremely well.

A strategic approach should recognise its value.

Replacing functioning systems simply to achieve uniformity can introduce unnecessary cost, disruption and environmental impact. Keeping everything indefinitely can create the opposite problem: technical debt, unsupported systems, security exposure and an increasingly fragmented estate.

The answer sits between those extremes. A useful assessment should establish:

• What is performing well and should be retained
• What is limiting the organisation or its people
• What can integrate effectively
• What is approaching the end of its useful or supported life
• Where security, resilience or compatibility may create risk
• What should be connected, upgraded or replaced
• Where investment will create a meaningful improvement in outcome

This is where the difference between the technology an organisation has and the environment it could have becomes clearer.

The individual systems may all work. The question is whether the environment works as a whole.

And that can be difficult to see from inside an environment people have become accustomed to using every day.

Technology introduced at different points in time may never have been considered collectively. The organisation may have changed considerably since those original decisions were made. People may be working around limitations that have become so familiar they are no longer recognised as limitations.

That doesn’t necessarily mean an entire technology refresh is required. Sometimes the most valuable change isn’t replacing more technology. It’s understanding how to make more of what is already there.

Change the order and you change the decision

There will always be another platform, another feature and another technology promising to transform the way organisations operate.

The challenge is no longer simply accessing capability. It’s knowing which capabilities deserve a place in your environment.

The iwGROUP approach can be distilled into four stages:

1. Understand the requirement
Begin with the organisation, its people, environment, objectives, existing estate, risks and constraints.

2. Decide what needs to work together
Identify where integration will create meaningful operational value rather than connectivity for its own sake.

3. Determine the best architecture
Consider what should be retained, what should change and whether the right solution is a unified ecosystem, an interoperable multi-vendor environment or a combination of both.

4. Select the technology
Only once the first three questions have been answered should the conversation narrow to individual products, platforms and manufacturers.

Putting the product decision last changes the conversation.

It allows people and experience to be considered alongside technical performance. Existing infrastructure becomes part of the strategy rather than an inconvenience to work around. Integration is considered because it creates value, not simply because it is technically possible. The advantages of a unified ecosystem can be assessed alongside the flexibility of a more open architecture.

And importantly, it creates space to discover opportunities that may not have been visible when the conversation began.

Sometimes the biggest limitation in a technology project isn’t the capability of the products being considered.

It’s the assumption that the answer is already known.

Better technology decisions begin with better questions

The next time a technology decision begins with a product, platform or manufacturer, it may be worth moving the conversation back one step.

Ask:

• What are we actually trying to achieve?
• What already works?
• What isn’t working as well as it could?
• What have people simply learned to work around?
• What needs to work together?
• What would a better outcome actually look like?

Only then does the technology question become useful.

The eventual answer might be one integrated ecosystem. It might bring together technologies from several manufacturers. It might retain far more of the existing estate than originally expected.

The important thing is that the solution wasn’t decided before the questions were asked.

The strongest technology decisions don’t begin with choosing the answer…

They begin with asking better questions.

If this has prompted you to look differently at your own technology strategy and environment, talk to the iwGROUP team. The conversation doesn’t need to begin with a product or a specification. It can simply begin with what you’re trying to achieve.

Author: Khalid Khan, Head of Projects, iwGROUP