Know What You Need Before Choosing the Technology

A technology decision is a commitment to a way of working: how work is handed over, which decisions are centralised, what data is trusted and where controls sit.

Ask first: “What must the business be able to do, for whom, and under what conditions?”

Business architecture gives executives, operational leaders, technology teams and procurement a shared view of outcomes, required capabilities, operating-model choices and constraints. For Australian organisations facing platform renewal, ERP change, service redesign, merger integration or procurement transformation, it creates a clearer path from ambition to an informed decision.

What should be decided before selecting technology?

Before inviting vendors in, agree the business problem, the intended outcomes, the scope of the change and the decisions that are not open for a software product to make on your behalf.

Start with a short, testable statement of intent. It should describe the result required, the people or customers affected, the reason it matters now and the measures that will show whether the change has worked. “Replace the legacy system” is an activity. “Reduce the time and rework required to resolve customer cases while maintaining accountable approvals” is a business intent.

Then establish the boundaries. Which services, business units, channels, products, jurisdictions, suppliers and data domains are in scope? What must continue without disruption? What policies, regulations, contractual commitments, security obligations and architectural standards apply? Ambiguity here does not disappear during selection. It returns later as change requests, exclusions or unresolved ownership.

The Australian Government’s procurement guidance starts value-for-money consideration with a clear expression of the procurement’s goals and purpose, and recognises scope, resourcing and market capacity as relevant considerations.[1] The same logic applies in private-sector procurement.

How does business architecture improve technology selection?

Business architecture connects strategy to execution without starting from an application catalogue. Its core question is capability: what must the organisation be able to do consistently, regardless of who performs the work or which system currently supports it?

A capability is not a team name, a process step or a piece of software. “Supplier management”, “case resolution”, “workforce planning”, “customer identity management” and “financial close” are capabilities. Each may involve people, policies, data, processes, partners and technology. That distinction matters because an organisation can change its structure or replace a platform without changing the capability it needs to perform.

A practical capability view identifies where investment is required, where existing assets can be extended, where standardisation is sensible and where differentiation is worth protecting. APQC describes a model linking objectives and capabilities to process, information, applications, services and infrastructure, so investments can be governed against requirements rather than isolated features.[2]

The output need not be an architecture repository. For a selection, a useful minimum is often:

• a one-page outcome and scope statement

• a capability map at a level executives can debate

• a view of current pain, performance and dependency by priority capability

• a target operating model sketch covering roles, decision rights, service hand-offs and control points

• a list of information, integration, security, privacy, resilience and reporting needs

• clear principles for what should be standard, configurable, customised or left unchanged

This is enough to turn a product comparison into a fit assessment.

What is the difference between requirements and vendor features?

Requirements describe what the organisation needs to achieve and the conditions under which it must operate. Features describe what a product says it can do. They are related, but they are not interchangeable.

A feature-led approach tends to produce long checklists: “Does the product support workflow X?” “Can it generate report Y?” Vendors can often answer yes, partially, through configuration, through a partner, or on a roadmap. The apparent precision can hide the question that matters: will this solution support the required outcome in the organisation’s actual operating environment?

Good requirements start higher. They express the business capability, user need, rule, volume, service level, decision, data obligation or risk that must be addressed. They also state acceptance criteria: what evidence will demonstrate fit? A requirement for “role-based approvals with traceable delegation across business units” is more useful than a generic request for “approval workflow”. It lets the evaluation consider governance, identity, auditability, exceptions, user experience and implementation effort together.

Discovery should also challenge assumptions. The Digital Transformation Agency’s service standard calls for teams to understand users, conduct research, test designs and revisit user needs as knowledge of the problem grows.[3] Even where the work is not a public digital service, the principle is sound: discovery is for learning, not for defending the first solution idea.

What should an executive ask before buying enterprise technology?

Before buying enterprise technology, an executive should confirm the business outcome, priority capabilities, operating model decisions, non-negotiable constraints and evidence of solution fit. Define the customer, employee, regulatory or commercial problem in plain language; identify which capabilities must improve and which should remain stable; then agree how work, decisions, data ownership, controls and accountability will operate after the change. Translate that design into measurable requirements covering functional needs, integration, information, security, privacy, resilience, reporting, change and ongoing ownership. Assess existing technology before assuming replacement is necessary. Only then ask vendors to demonstrate how their solution meets the requirements in realistic scenarios, including exceptions and transition. Evaluate total cost, delivery assumptions, lock-in, vendor dependency and the organisation’s capacity to adopt the change. This order prevents a product demonstration from becoming the organisation’s de facto strategy.

How do you define a target operating model without overdesigning it?

A target operating model should be detailed enough to make technology choices testable, not so detailed that it becomes a theoretical exercise.

Start with the moments that matter: demand intake, customer or supplier interaction, decision-making, service delivery, exception handling and compliance. For each, decide who owns the outcome, who can make which decision, what information is authoritative, which hand-offs are required and how issues escalate. Include partners and shared services, not just the organisation chart.

The important questions are often uncomfortable. Should a decision be centralised or local? Is a single standard process essential, or are local variants legitimate? Who may change master data? Which controls must be preventative and which can be detective? What happens when the digital path fails? A platform can help execute these choices, but it cannot make them responsibly.

Treat transition as part of the model. The desired future state may be right, while the organisation lacks the capability, data quality, governance maturity or change capacity to operate it immediately. That should shape the roadmap, sequencing and procurement scope. A solution that fits only the final-state picture can still be a poor choice if the path to get there is unworkable.

How should procurement test solution fit?

Procurement should make fit observable. The evaluation should not rely on a generic demonstration, a feature score or a price comparison alone.

Use a small number of high-value scenarios drawn from the agreed architecture. Ask suppliers to show how the solution handles a normal case, a difficult exception, a cross-team hand-off, an integration failure, a change in policy, an audit request and a reporting need. Require clarity about what is standard capability, configuration, custom development, partner product, manual workaround or future roadmap.

Score the response across business fit, operating fit, technical and data fit, delivery credibility, commercial fit and risk. Weight the criteria before supplier engagement. Document assumptions and dependencies. Ensure the people who will run the future process can challenge the proposed approach, not merely observe the demonstration.

Price is necessary but incomplete. The Commonwealth Procurement Rules state that price is not the sole value-for-money factor and identify fitness for purpose, flexibility, whole-of-life costs and other financial and non-financial costs and benefits as relevant.[1] For enterprise technology, whole-of-life thinking includes licences, implementation, integration, migration, controls, training, support, enhancement, exit and the internal effort needed to sustain the platform.

Architecture should also inform the contract. Confirm responsibilities for data, interfaces, service levels, security, change control, documentation, knowledge transfer, portability and exit. These are not legal footnotes. They are the operational conditions that determine whether a solution remains fit after go-live.

When is a capability map enough, and when is deeper analysis needed?

A capability map is often enough to set direction, prioritise investment and frame an initial market scan. It is especially valuable where the organisation needs a shared vocabulary, has a crowded application landscape or is deciding where to focus discovery. Mapping applications to capabilities can reveal redundancy and support decisions about consolidation, modernisation or retention.[4]

Go deeper when the decision has high cost, high risk, broad operational impact or hard-to-reverse consequences. Examples include core platform replacement, major outsourcing, regulated services, substantial data migration, complex integrations, multi-jurisdiction operations and changes to accountable decision rights.

Deeper analysis may include service blueprints, process and exception analysis, information models, integration architecture, security and privacy assessment, non-functional requirements, transition planning and financial modelling. The point is proportionality. Do enough work to understand the decision you are making; do not produce artefacts that have no bearing on it.

What questions should executives and procurement leaders ask together?

• What business outcome are we funding, and what would count as evidence of success?

• Which capabilities must improve, and which are core to differentiation or control?

• What operating model choices have we made before technology constrains them?

• Which requirements are mandatory, and which are preferences or potential future options?

• What can the current estate support, retire, simplify or integrate?

• What will the organisation need to change in people, data, process, governance and partner arrangements?

• How will we test supplier claims against realistic scenarios, exceptions and whole-of-life cost?

These questions reduce the chance that a persuasive demonstration, a familiar brand or a narrow cost comparison substitutes for a considered choice.

What are common questions before technology selection?

Do we need business architecture for a smaller selection?

Use a proportionate version. A clear outcome, scope, capability view and decision criteria can prevent avoidable rework even in a focused procurement.

Should we select a platform before finalising the target operating model?

No. Define the key operating choices first. Otherwise a product’s default configuration can make those choices accidentally.

How many requirements are enough?

Enough to distinguish fit, risk and delivery effort. Prioritise outcome-critical, control-critical and integration-critical requirements over exhaustive feature lists.

Can existing technology be part of the answer?

Yes. Assess retain, simplify, integrate and retire options before treating replacement as the default response to a business problem.

Who should evaluate vendor demonstrations?

Include accountable executives, operational owners, technology, security, data, finance and procurement. Future users should test realistic scenarios and exceptions.

What should happen after a technology decision?

Selection is a decision point, not proof of value. Reconfirm the architecture before implementation begins: intended outcomes, scope, target operating model, principles, requirements, success measures and ownership. Keep the traceability from capability to requirement to design choice to test evidence. It makes trade-offs visible when time, budget or product constraints appear.

The strongest implementation governance asks the same question throughout delivery: are we still building the business change we intended, or are we adapting the business to an unexamined product constraint? There will be compromises. The aim is to make them deliberate, understood and owned.

If your organisation is approaching a material technology decision, start with the business architecture needed to frame it. 3NT Advisory can help leaders clarify the outcomes, capabilities, operating model and decision criteria before the market process begins.

Sources

[1] Australian Government Department of Finance — Value for money — https://www.finance.gov.au/government/procurement/commonwealth-procurement-rules/value-money

[2] APQC — How Should Business Processes Connect To Technology And Enterprise Architecture? — https://www.apqc.org/How-Should-Business-Processes-Connect-To-Technology-And-Enterprise-Architecture

[3] Digital.gov.au — Digital Service Standard — https://www.digital.gov.au/policy/digital-experience/digital-service-standard

[4] LeanIX — The Definitive Guide to Business Capabilities — https://www.leanix.net/hubfs/2024-Website/content/white-paper/WP-Definitive-Guide-Business-Capabilities/EN/EN-WP-Definitive-Guide-Business-Capabilities.pdf