11 July 2026
NVIDA is morphing from a GPU supplier on steroids into IBM's heartland, the enterprise compute space. Their Trojan Horse is the appetite businesses have for game changing artificial intelligence.
Our previous article explained IBM Spectrum Symphony and its role in managing demanding distributed workloads. This article asks a more consequential question: why has IBM technologist Kevin D. Johnson spent months applying Symphony to BrainChip’s Akida neuromorphic processor across such an extensive series of demonstrations?
I have been trying to make sense of this and have come-up with the following theory.
The likely answer is that Johnson is testing more than Akida’s performance on individual AI tasks. His work appears to examine whether neuromorphic processing can fit into a heterogeneous computing environment in which CPUs, GPUs, edge devices, storage, mainframes and other specialized processors are coordinated according to their strengths.
Although Johnson’s work is heavily technical, the deeper issue may be category ownership.
As enterprise AI transformation becomes the organizing theme for major technology investment, NVIDIA is expanding from GPU supplier into a full-stack enterprise solutions provider; that's IBM's heartland.
IBM may therefore be seeking to ensure that the orchestration, data and governance layer - not the accelerator vendor - defines the broader architecture and leads the customer relationship.
The unexpected beneficiary of that contest could be BrainChip. But to earn a seat in the orchestra, it may need to tune-up its product strategy and go-to-market: positioning Akida as a harmonious, low-power, event-driven member of an orchestrated heterogeneous compute fabric. Not abandoning the edge but redefining what "The Edge" means.
IBM may not be betting on Brainchip - it may be betting on orchestrating heterogeneous enterprise AI
Heterogeneous computing is an architecture in which different types of processing work together, with each assigned the tasks it performs most efficiently. Orchestration software coordinates those resources so applications can use them as part of one managed computing environment.
IBM may be “betting” on heterogeneous computing because, in a heterogeneous market, it does not need to manufacture the dominant processor to lead the overall enterprise architecture.
The bet is not merely that enterprises will deploy several kinds of chips—that is already happening. The deeper proposition is that the most durable strategic value will sit in the layer that discovers, schedules and governs those resources, connects them to data, and integrates their outputs with business systems.
IBM may be seeking to advance a new narrative: enterprise AI will not remain under the control of one processor or one supplier. It will require a hardware-agnostic orchestration and integration layer—and IBM may be positioning itself to lead that layer.
Kevin D. Johnson’s work illustrates how IBM’s mature workload-management technologies could support that proposition. IBM Spectrum Symphony is designed to distribute and virtualise compute-intensive services across heterogeneous IT resources. Johnson has applied it repeatedly to BrainChip’s Akida and, in one closed-loop demonstration, used it to coordinate Akida with IBM Quantum, Granite and vLLM, and z/OS.
The point is not that Akida replaces the GPU. It is that GPUs are not the optimal resource for every stage of every workload. Different processors can be assigned the work best suited to their particular strengths, while orchestration software makes the resulting system manageable.
IBM’s advantage is not ownership of every processor. It is more than a century of experience integrating and operating complex enterprise systems—and a portfolio that may allow it to occupy the strategically important layer above the silicon.
Why the heterogeneous computing proposition suits IBM
IBM is not the dominant GPU supplier. It is also not the largest hyperscale cloud provider or the owner of every leading AI model. If enterprise AI becomes centred on one vertically integrated GPU stack, IBM risks becoming a supporting supplier of storage, software, consulting and legacy-system integration inside an architecture defined by NVIDIA.
Heterogeneous computing gives IBM a different competitive field. Instead of arguing that IBM has the best chip for every workload, IBM can argue that no single chip is best for every workload:
- GPUs handle dense AI training and large-model inference.
- CPUs handle general-purpose processing and control.
- Akida or other neuromorphic processors handle sparse, event-driven and low-power workloads.
- Edge systems handle local sensing and response.
- Mainframes continue to handle trusted transaction processing and systems of record.
- Other specialized processors address particular workloads.
Once that premise is accepted, the critical customer question changes from:
Which processor platform should we standardise on?
to:
Who will make all these different systems work together securely, efficiently and reliably?
That second question is much more favourable to IBM.
IBM is effectively betting on the layer above the silicon
Processors will change. The leading model architectures will change. New accelerator classes will emerge. Some will disappear.
IBM does not have to predict every winner if it can provide the mechanisms that:
- Identifies the available resources;
- Understands what each resource is capable of doing;
- Places workloads appropriately;
- Maintains models, data and state;
- Applies security and organizational policy;
- Monitors cost, latency, energy and utilization;
- Recovers failed services;
- Connects AI outputs with operational business systems.
Symphony is one part of that layer, particularly for persistent, service-oriented compute and inference. LSF contributes batch and training workload management. Storage Scale or GPFS contributes the shared data and state layer. Red Hat and IBM’s broader integration and consulting capabilities help connect this compute environment to the enterprise.
That qualification is important: IBM’s bet is broader than Symphony alone. Symphony does not govern the whole enterprise or replace OLTP systems. It manages compute-intensive services within the larger IBM-led architecture.
Heterogeneity turns IBM’s apparent weakness into a strength
If the market assumes that one full-stack AI vendor (like NVIDIA) will supply the accelerator, software, orchestration and architecture, IBM appears to have a portfolio gap.
But if the market assumes that enterprises will deliberately use multiple processors, clouds, models and existing systems, IBM can present its lack of dependence on one accelerator as:
- Vendor neutrality;
- Customer choice;
- Protection against lock-in;
- Adaptability as technologies change;
- Preservation of existing enterprise investments.
In other words, heterogeneity allows IBM to say:
We do not need to manufacture every component. We can provide the architecture through which every component is selected, governed and used.
That is a plausible route to the prime-contractor role.
It is also a response to NVIDIA’s expansion
NVIDIA’s strategic movement
NVIDIA is expanding from GPU supplier into enterprise AI software, networking, orchestration, infrastructure management and complete AI-factory architecture.
If customers allow NVIDIA to define the entire system, IBM may still participate - but as a component or implementation partner inside an NVIDIA-centred environment.
IBM’s heterogeneous proposition counters that by treating the GPU as one highly important resource among several, rather than as the organizing centre of the enterprise.
IBM is saying, GPU's are great but that depends on the compute task:
When all you have is a hammer, every problem starts to look like a nail. Heterogeneous compute offers the full tool kit.
IBM does not need NVIDIA to lose. It needs NVIDIA to remain inside an IBM-led or genuinely multi-vendor architecture rather than becoming the architect of the whole environment.
That is why the contest is simultaneously cooperative and competitive:
IBM wants NVIDIA technology in the system, but it does not necessarily want NVIDIA to define the system.
Energy efficiency strengthens the bet
The increasing power and infrastructure demands of AI also support the heterogeneous thesis.
The argument is not that Akida or another low-power processor will replace GPUs:
It is that expensive, power-intensive processors should be used only for workloads that require them.
A heterogeneous system can assign:
- Continuous sensing and filtering to low-power processors;
- Control logic to CPUs;
- Dense model execution to GPUs;
- Transactional execution to systems of record.
This can potentially reduce unnecessary data movement, GPU use, storage, latency and power consumption. The strategic value lies in system-level workload placement, not simply in comparing the efficiency of two individual chips. That gives IBM another reason to favour orchestration: the more important workload placement becomes, the more valuable the layer making those placement decisions becomes.
Akida is a test case, not necessarily the bet itself
IBM is not necessarily betting specifically on BrainChip. Akida is useful because it is meaningfully different from a conventional CPU or GPU. It tests whether IBM’s software can recognize and manage a genuinely specialized processor with different workload characteristics, metrics and operating constraints.
If that works, IBM can claim more than compatibility with another accelerator. It can claim that its architecture can absorb new kinds of computing.
Therefore:
BrainChip is the test case; heterogeneity is the bet; orchestration is the strategic prize.
Even if another neuromorphic technology ultimately succeeds, much of the IBM architectural proposition still holds. That is what makes the strategy relatively low-risk for IBM.
The discussion that supports my thesis
Here is how I concluded that Kevin D. Johnson's work is both technical validation but likely more about business strategy.
==================================
QUESTION:
Now that we have explained what IBM Spectrum Symphony is, and its more usual use cases - why has Kevin D. Johnson spent the last 7 months applying Symphony to Brainchip's Akida as described in this extensive catalogue of his work?
==================================
ANSWER:
Why has Kevin D. Johnson applied IBM Spectrum Symphony to BrainChip Akida?
The likely answer is that he is not simply testing whether Akida can run AI workloads. He appears to be testing whether neuromorphic processing can be integrated into a larger, heterogeneous compute fabric alongside CPUs, GPUs, storage and other specialised resources.
That moves the question beyond chip capability and into operational capability. A conventional accelerator demonstration asks whether a device can run a model, how accurate it is, how quickly it responds and how much power it consumes. Johnson’s work asks a different set of questions: can Akida be discovered, scheduled, monitored, shared, scaled, recovered and coordinated as a first-class enterprise resource?
No single public statement proves that this is his only objective, so the conclusion is partly interpretive. However, it is strongly supported by the architecture repeated across his demonstrations.
Symphony turns Akida from a device into a managed service
An application connected directly to one Akida board is tied to that particular device and host. Under Symphony, Akida inference can instead be exposed as a service. An application submits a request, Symphony locates a suitable service instance, the selected physical chip or simulator performs the work, and the result is returned without the application needing to know where it ran.
This allows Symphony to manage matters that become important once Akida moves beyond the laboratory: model residency, variable demand, multi-user access, workload priority, failure recovery and scaling across additional nodes. A model can remain loaded rather than being reloaded for every request, while applications can use the same service interface as the underlying hardware changes.
The workload shape also suits Symphony. Training is usually a long-running batch process, while inference is request-driven and benefits from persistent services that are already loaded and ready. Johnson’s wider architecture therefore gives different roles to different IBM products: LSF manages batch and training workloads, Symphony manages service-oriented inference, and GPFS or Storage Scale provides the shared layer for models, observations, state and provenance.
Symphony can also be supplied with Akida-specific information rather than treating every server as interchangeable. Scheduling may depend on which Akida generation is installed, whether a required model is resident, whether physical silicon or simulation is acceptable, and whether measured power, latency or utilisation suits the request. The aim is not to hide the differences between processors, but to make those differences usable by the orchestration layer.
Why so many demonstrations?
The variety of Johnson’s work can look eclectic: sensing, infrastructure, finance, defence, language models, satellite systems, cybersecurity and other domains. Viewed architecturally, however, these are different test cases for the same proposition.
The important result is not necessarily the performance of any single classifier. It is whether one managed fabric can absorb new models, devices, sensor types, users and applications without requiring a separate infrastructure island for each one. The breadth of the catalogue tests whether the architecture is general, configurable and reusable.
It also tests a complementary model of heterogeneous computing. CPUs provide control and general processing. GPUs perform dense training and large-model work. Storage maintains data and state. Akida handles low-power, sparse, event-driven sensing, classification and adaptation. Other specialised resources can be invoked when their characteristics fit the task.
In that architecture, Akida does not need to replace the GPU. It can continuously monitor a sensor or data stream, discard routine inputs and escalate only meaningful events to a CPU, GPU, language model or operational platform. Its value can therefore include the computation, data movement and energy consumption it prevents elsewhere in the system.
Bottom line
Johnson appears to be investigating the gap between a working neuromorphic chip and a deployable neuromorphic computing platform.
The question is not only:
Can Akida classify this image, sound, signal or event?
It is:
Can Akida operate as a shared, measurable, scalable and resilient resource within a real heterogeneous system, with each part of the workload routed to the processor best suited to perform it?
Symphony is central because it supplies the scheduling, service management, resource governance, scaling and failure handling required to test that proposition. Akida supplies the specialised neuromorphic capability, while GPFS supplies the persistent data and coordination layer.
This is not evidence of an announced IBM–BrainChip product or formal commercial partnership. It does, however, explain why Symphony appears so consistently in Johnson’s work: he is testing not merely whether Akida works, but where neuromorphic computing fits within enterprise architecture.
==================================
QUESTION:
Assuming Johnson’s work has IBM’s approval, or at least IBM’s awareness, given the volume and sophistication of the output, what purpose might IBM be pursuing through this extensive project? Possible interpretations include:
- Demonstrating the capabilities of IBM’s enterprise solutions team and its suite of high-performance compute orchestration products;
- Running a freewheeling skunkworks-style programme to discover what emerges through experimentation;
- Responding to global concerns about the power demands of AI data centres by exploring more efficient architectures and potential technology advantage;
- Pursuing a broader strategic response to NVIDIA’s expansion into enterprise solutions, as NVIDIA is no longer merely a “GPU on steroids” hardware vendor but is increasingly presenting full-stack, end-to-end enterprise AI platforms;
- or, something else entirely. Discuss.
==================================
ANSWER:
What is IBM’s purpose in pursuing the Akida–Symphony project?
An important qualification comes first. The volume and visibility of Johnson’s work make IBM awareness plausible, but they do not prove a formally funded IBM–BrainChip programme. IBM Community content is not automatically an IBM endorsement, and the project’s internal status is not public.
On that basis, the strongest interpretation is this:
IBM may be using Akida as a demanding test case for a larger proposition—that IBM’s orchestration, storage and governance software can become the neutral control plane for heterogeneous enterprise AI.
Akida matters because it is genuinely different from a CPU or GPU. If IBM software can discover, schedule, monitor and coordinate a neuromorphic processor alongside conventional resources, it demonstrates more than compatibility with one device. It demonstrates an architecture intended to absorb new forms of computing without surrendering control of the overall system to any one silicon vendor.
Demonstrating and repositioning IBM’s enterprise portfolio
This is probably the most immediate purpose.
Spectrum Symphony, Spectrum LSF and Storage Scale were established in financial computing, engineering, research and high-performance computing. Johnson’s work recasts them for the AI era: LSF manages long-running training and batch workloads, Symphony manages persistent inference services, and GPFS coordinates models, data and state across the environment.
That gives IBM’s enterprise teams a more coherent story. Customers do not buy an accelerator alone; they buy a system involving data, compute, security, monitoring, resilience, integration and support. The demonstrations show IBM products acting together as an operating fabric rather than appearing as separate items in a catalogue.
A directed skunk-works program
The work also resembles a skunk-works, but not a random one.
The applications vary widely, while the architectural question remains consistent: can IBM’s existing infrastructure software govern a radically heterogeneous computing environment? Rapid experimentation is an efficient way to discover technical gaps, promising applications and customer interest before committing to a formal product programme.
The useful outputs may therefore be broader than any single demonstration. They could include reusable reference patterns, product requirements, partner discussions, customer demonstrations and evidence about which industries respond most strongly to heterogeneous AI.
Exploring a more efficient AI architecture
The power demands of AI make workload placement increasingly important. The strategic opportunity is not simply to replace GPUs with low-power neuromorphic chips; GPUs will remain essential for dense training, large-model inference and highly parallel numerical work.
The more credible architecture is to use Akida for persistent, sparse and event-driven work—monitoring, filtering, anomaly detection and classification—and invoke central GPU or language-model capacity only when the event justifies it.
Symphony provides the mechanism for making that choice across a managed system. It could route work according to capability, latency, cost, availability and energy use. The demonstrations do not yet prove an end-to-end energy saving; that would require controlled measurement. They do show why IBM would want to investigate the architecture.
Responding to NVIDIA’s expansion up the enterprise stack
NVIDIA is no longer only a chip supplier. Its enterprise proposition increasingly includes software, networking, orchestration, infrastructure management and validated AI-factory designs. Those functions move NVIDIA toward the role of system architect and into territory traditionally occupied by enterprise infrastructure and middleware vendors.
IBM’s response is likely to be cooperation and competition at the same time. IBM needs NVIDIA technology inside customer solutions, but it also has a strategic interest in ensuring that NVIDIA does not become the only meaningful control point for enterprise AI.
Akida strengthens IBM’s argument because it is not another NVIDIA resource. Integrating neuromorphic processors alongside GPUs, CPUs, mainframes, storage, edge systems and quantum services demonstrates genuine heterogeneity. IBM can support NVIDIA while arguing that the enterprise control plane should remain above the accelerator layer.
The larger purpose: owning the layer above the silicon
This is the interpretation that unifies the others.
Different processors may dominate different workloads, and those positions will change over time. IBM does not need to predict every winning chip if it can provide the system that identifies resources, understands their capabilities, applies policy, routes work, maintains data and state, recovers failed services and connects computational results to business operations.
That is the strategic attraction of Johnson’s “compute ontology” idea. The scheduler is no longer merely finding an idle processor. It is being asked to understand what each resource is, what it is good at, how it is behaving and how it should participate in a governed business process.
From this perspective, IBM does not need to be making a corporate bet on BrainChip. It may be making a bet on heterogeneity. If BrainChip succeeds, IBM has early knowledge of how to manage neuromorphic resources. If another technology becomes more important, much of the architectural work still transfers.
Conclusion
The four proposed explanations are not competing theories so much as parts of one program.
- The commercial objective is to reposition IBM’s orchestration, storage, cloud, mainframe, AI and consulting capabilities as one heterogeneous enterprise platform.
- The skunkworks method allows IBM to explore that proposition quickly.
- The energy problem gives the work urgency.
- NVIDIA’s movement into full-stack enterprise AI provides the competitive setting.
The larger strategic proposition is that orchestration, data management and governance, not the accelerator itself, may become the durable centre of enterprise AI.
Johnson’s project may therefore be less about IBM choosing BrainChip than about IBM demonstrating that, whatever specialized processors enterprises choose, IBM intends to manage the system in which they operate.
==================================
QUESTION:
The rapid growth of AI workloads, and their increasing value in enterprise computing, has created a new business category: enterprise solutions now commonly include a substantial AI component, even when AI remains integrated with traditional computing rather than separate from it. This changes the basis of competition for major enterprise vendors such as IBM. As enterprise solutions combine transaction-centric data centres, AI-focused infrastructure, orchestration layers, connectivity, hardware, software and service management, the procurement question becomes: which vendor should act as head contractor for the overall system? This is a business strategy question. Discuss the proposition by interpreting Johnson’s work as more than technical exploration.
==================================
ANSWER:
Johnson’s work as a claim to the prime-contractor role in enterprise AI
On the working hypothesis that IBM is aware of or encouraging Johnson’s work, the strongest business interpretation is that the program is not principally about BrainChip, or even neuromorphic computing. It is about IBM’s claim to be the lead architect, integrator and accountable contractor for the heterogeneous enterprise environment emerging around AI.
IBM does not need Akida to become the dominant AI processor for this to be strategically valuable. It needs to demonstrate that, whatever combination of processors, models, clouds, data platforms and operational systems a customer chooses, IBM can make them function as one governed system.
AI has changed what the enterprise is buying
Production AI rarely operates as a separate island. A fraud model connects with payments. Predictive maintenance connects with asset management and work orders. A customer agent connects with CRM, billing, inventory and fulfillment. AI draws from systems of record, shapes decisions and writes outcomes back into operational processes.
The procurement unit therefore expands beyond an AI model or GPU cluster. It includes transaction systems, training and inference infrastructure, storage, edge devices, networking, orchestration, security, governance, applications, integration and ongoing service management.
The customer’s larger question becomes:
Who will design, integrate, govern and remain accountable for the complete environment in which AI and the existing enterprise must work together?
That is the prime-contractor question.
The strategic prize is the right to draw the system boundary
The head contractor is not necessarily the company that manufactures the most expensive or largest component - it is the company that defines the architecture, selects or certifies suppliers, controls interfaces and standards, manages implementation risk and accepts responsibility for the result.
That position influences the approved vendor ecosystem, support model, security architecture, upgrade path and long-term customer roadmap. Most importantly, it determines which technologies are treated as platforms and which are treated as components.
If NVIDIA defines the architecture, IBM software and services may participate inside an NVIDIA-defined AI factory. If a hyperscaler leads, IBM and NVIDIA may both become services inside a cloud platform. If an operational software vendor leads, infrastructure may become a supporting layer beneath its workflow and data model.
If IBM defines the architecture, GPUs, Akida processors, public clouds, models and operational platforms can all become resources inside an IBM-governed enterprise environment.
The prime contractor does not need to supply everything. It decides how everything else participates.
Vendors are competing to define what the customer is buying
- NVIDIA’s preferred category is the AI factory: an integrated stack of accelerated computing, networking, software and operations.
- Hyperscalers prefer a cloud operating environment.
- Operational software vendors frame the purchase around workflow, data ontology and decision-making.
IBM’s strongest category is different: a governed, hybrid, multi-vendor enterprise operating model that connects AI with existing systems of record and preserves operational continuity.
Each definition favours a different head contractor. The competition is therefore partly a contest over category ownership.
Johnson’s work helps define the category in IBM’s favour
Johnson’s “heterogeneous compute ontology” describes the enterprise as a coordinated system of different resources rather than as a GPU cluster with other systems attached.
In that model:
- GPUs handle dense training and large-model work.
- Neuromorphic processors handle sparse, event-driven and always-on workloads.
- CPUs provide control and general processing.
- Mainframes provide trusted transaction processing.
- Edge devices provide local sensing and action.
- Storage maintains models, data, state and provenance.
- Orchestration assigns each workload to the appropriate resource.
The applications may vary, but IBM’s products repeatedly occupy the integrating layers. LSF manages training and batch work. Symphony manages service-oriented inference. GPFS or Storage Scale carries shared models and state. Red Hat platforms support application portability and operational consistency.
This is strategically powerful because it lets IBM seek the prime-contractor role without owning every component. IBM can argue that no single processor, model or cloud is optimal for every workload, so the customer needs an architect capable of making diverse technologies work together securely and predictably.
IBM’s lack of ownership across the full stack can then be positioned as neutrality and customer choice rather than as a portfolio gap. The proposition is commercial, not altruistic: IBM would still monetise orchestration, data, infrastructure, automation, consulting and support.
The customer is buying risk transfer
Prime contractors are usually selected according to the risk the customer most wants transferred. A buyer focused on maximum accelerator performance may prefer an NVIDIA-centred design. A cloud-native buyer may prefer a hyperscaler. A regulated or asset-intensive enterprise may prioritise integration with existing systems, data sovereignty, auditability, service continuity, model flexibility and long-term accountability.
That is the risk profile IBM wants to own.
Johnson’s work helps by reframing the central problem. The difficulty is not merely obtaining an AI accelerator. It is governing a changing collection of accelerators, data stores, edge devices and operational systems over time.
What would make the proposition commercially credible?
Demonstrations can support IBM’s claim, but they are not enough. A repeatable prime-contractor offering would require supported reference architectures, validated integrations, security and compliance evidence, lifecycle procedures, measurable cost and energy benefits, clear support responsibility, service-level commitments and production customer references.
This is where vertically integrated competitors retain an advantage: simplicity. IBM wins only if it hides the complexity of heterogeneity, preserves choice and accepts accountability for the outcome. Customers will not pay IBM merely to coordinate complexity that IBM has introduced.
Conclusion
Johnson’s Akida–Symphony programme can be read as a practical case for IBM occupying the prime-contractor role in enterprise AI.
Its strategic purpose is not simply to prove that Akida works. It is to show that IBM can govern an environment in which neuromorphic processors, GPUs, CPUs, mainframes, cloud resources, edge systems, storage, enterprise data and operational platforms all contribute without any one technology controlling the full stack.
NVIDIA wants the customer to buy an AI factory. Hyperscalers want the customer to buy a cloud environment. Operational software vendors want the customer to buy a decision and workflow platform. IBM wants the customer to buy a governed hybrid-enterprise operating model—and to appoint IBM to integrate and manage it.
The larger prize is not ownership of every component. It is ownership of the architecture, accountability and customer relationship that determine how the components are bought and used.
==================================
QUESTION:
Is this fundamentally a corporate positioning exercise? The technical question is how to design the best architecture and tool-set for enterprise AI, but the commercial question is how customers perceive technology leadership. If executives believe future competitive advantage will depend on AI, they may assume the vendor with the strongest AI brand should lead the broader enterprise IT program—even if most of the workload is not AI-specific. Is that the problem IBM is trying to address?
==================================
ANSWER:
Yes - IBM is addressing a problem of category ownership
That is a persuasive interpretation. More precisely, IBM is addressing the risk that the vendor perceived to lead AI will be allowed to define the architecture of the wider enterprise program, even where AI represents only part of the workload.
Strategic importance can outweigh workload volume
Enterprise procurement is not always weighted according to the percentage of computing cycles consumed by each workload. It is often shaped by the capability executives believe will determine future competitive advantage.
A bank may still depend primarily on transaction processing, payments, databases and regulatory systems. A manufacturer may still spend most of its technology budget on ERP, production systems and operational technology. But once the board describes the next investment cycle as an “AI transformation”, AI can become the design centre for the entire program.
The AI platform may then influence choices about networking, storage, orchestration, security, data management, consulting and operations. The danger for IBM is not merely losing an accelerator sale. It is losing the right to define the system boundary.
The AI halo can turn a component supplier into the system architect
NVIDIA illustrates the issue. By extending from accelerators into enterprise software, networking, orchestration and validated AI-factory designs, it can move from supplying an important component to defining the environment around that component.
If the customer begins with the instruction, “Build us an NVIDIA AI factory”, many later decisions are already framed. Other vendors may still sell into the project, but they do so inside an architecture whose centre of gravity lies elsewhere.
IBM’s positioning problem is therefore:
How does IBM prevent its strengths in reliability, transaction processing, hybrid infrastructure, integration, governance and long-term support from being classified as the legacy component of someone else’s AI-led program?
IBM’s answer is to redefine AI leadership
IBM is unlikely to win a branding contest based only on who is most closely associated with GPUs or frontier models. Its stronger argument is that enterprise AI leadership should be measured by the ability to put AI into production across the complete enterprise.
Under that definition, leadership means connecting AI to existing systems, managing multiple models and processor types, preserving governance and data sovereignty, operating across cloud and on-premises environments, providing resilience and remaining accountable for the full production system.
This changes the procurement question from:
Which AI platform should become the foundation of the enterprise?
To:
Which enterprise architecture can incorporate changing AI platforms while preserving security, continuity, governance and freedom of choice?
The first question favours the strongest AI brand. The second plays to IBM’s traditional strengths.
Johnson’s work as “positioning engineering”
Johnson’s demonstrations give technical substance to that corporate narrative. They show different processors, models and applications being coordinated through IBM orchestration and data-management layers. Akida is especially useful because it is not another conventional GPU; managing it supports IBM’s claim that the control layer can remain independent of any one accelerator family.
The work also modernises the meaning of established IBM products. Symphony, LSF and GPFS can be presented not only as traditional HPC tools, but as components of a heterogeneous AI operating architecture.
That is why the programme can be described as positioning engineering. It builds an architecture and, at the same time, changes how customers and partners might classify IBM’s role in the market.
But positioning alone is not enough:
IBM cannot win by renaming established products or by making abstract claims about openness. It must eventually offer supported integrations, repeatable deployment, measurable economics, production references and clear accountability.
Vertically integrated competitors have a strong advantage: they can offer a simpler story. IBM’s heterogeneous alternative succeeds only if IBM absorbs the complexity for the customer.
The answer
Yes. IBM appears to be addressing the risk that AI brand leadership becomes enterprise architectural leadership by default.
The counter-position is not that AI is unimportant. It is that AI is too important to be designed as an isolated stack. It must be integrated with transaction systems, data, infrastructure, security and operations—and IBM wants to be seen as the company capable of leading that integration.
The contest is therefore not only over who supplies the AI technology. It is over who gets to define what the enterprise is buying.
==================================
QUESTION:
While the “repositioning thesis” above remains a well-supported interpretation rather than a proven fact, if we are broadly correct, it is worth analysing the opportunity Johnson’s work and IBM’s broader strategy create for BrainChip.
Points to explore:
- Regardless of IBM’s actual strategy, Johnson’s work has clear promotional value for BrainChip. It raises BrainChip’s profile, creates unofficial brand association with IBM, and indirectly signals technical credibility. It also presents a broad portfolio of Akida use cases spanning edge devices through to cloud-based enterprise computing.
- For the purpose of this analysis, set aside speculation that Johnson’s work will lead to a commercial arrangement between BrainChip and IBM. Such an arrangement appears unlikely, or at least should not be assumed, because it would sit uneasily with Johnson’s heterogeneous-compute thesis and IBM’s broader strategic interest in vendor-neutral orchestration.
- BrainChip must capitalize on the opportunity itself. Even if a financial deal is unlikely, IBM may still have good reason to prefer that BrainChip, or at least the neuromorphic category, succeeds. NVIDIA’s strategic vulnerability is power efficiency, and Akida potentially addresses that weakness as a complementary resource rather than a direct GPU competitor.
- BrainChip’s current strategy is market entry at the edge. So far, this has produced many publicly announced collaborations but limited evidence of material recurring revenue or ASX price-sensitive commercial traction. Johnson’s work arguably makes the case that BrainChip should not abandon its edge strategy, but should expand its value proposition: Akida should be positioned not as a GPU competitor, but as a power-efficient member of an orchestrated heterogeneous compute fabric. Discuss.
==================================
ANSWER:
BrainChip’s opportunity: from an edge-AI component to an enterprise neuromorphic tier
Assuming the IBM repositioning thesis is broadly correct, Johnson’s work has given BrainChip something potentially more useful than speculation about an IBM purchase order: a clearer answer to where Akida belongs in the computing architecture.
Akida can remain physically at the edge—or operate in gateways and server environments—while becoming a logical part of an enterprise-wide compute fabric. It can be discovered, scheduled, monitored and coordinated with CPUs, GPUs, storage, mainframes, cloud services and other specialised processors.
That re-frames Akida from a component sold one embedded design win at a time into a potential resource class within enterprise AI infrastructure.
The promotional value is real, but it is not an IBM endorsement
Johnson’s work repeatedly places BrainChip Akida within the same technical narrative as IBM Symphony, LSF, Storage Scale, NVIDIA infrastructure, enterprise storage, cloud services and other advanced computing platforms.
That creates legitimate value for BrainChip:
- Greater visibility among enterprise and HPC audiences;
- Evidence that a sophisticated practitioner has invested substantial effort in Akida;
- A broad catalogue of possible applications;
- A bridge between neuromorphic silicon and enterprise buyers who might not otherwise evaluate it;
- An association with serious systems architecture rather than only experimental edge devices.
The distinction between association and endorsement must remain clear. BrainChip can refer accurately to public demonstrations conducted by an IBM practitioner using IBM software. It should not imply IBM certification, selection or corporate support unless IBM says so.
The most accurate description is IBM brand adjacency. That adjacency can still strengthen perceived technical credibility, provided it is not overstated.
Johnson has produced reusable architectural patterns, not validated markets
The catalogue is more useful when compressed into a small number of recurring patterns rather than treated as dozens of unrelated use cases:
- An always-on sentinel that monitors at low power and escalates only meaningful events.
- An edge data-reduction layer that converts raw sensor streams into selected observations before transmission.
- A workload router that directs simple work to Akida and complex work to CPUs, GPUs or larger models.
- A persistent inference service that keeps models resident and available through standard interfaces.
- A managed neuromorphic fleet shared across applications, locations and sensor types.
- A heterogeneous closed loop in which an Akida detection triggers central analytics, retraining or operational action.
These patterns give BrainChip the beginnings of a product architecture. They do not prove that every application is a commercially attractive market. A demonstration does not establish willingness to pay, production reliability, security certification, acceptable integration cost or repeatable sales.
Johnson has done much of the architectural imagination. BrainChip must still do the productisation, validation and commercial conversion.
The opportunity should not depend on an IBM deal
BrainChip should plan on the assumption that there will be no special IBM financial arrangement. That is the prudent position because it forces the company to exploit the work itself rather than treating public experimentation as evidence of a future customer, reseller, investor or acquirer.
A non-exclusive technical relationship would not contradict IBM’s heterogeneous-compute thesis. Supported resource discovery, monitoring plug-ins, a validated reference architecture, partner participation or joint customer demonstrations could all fit a vendor-neutral platform.
What BrainChip should not assume is exclusivity or privileged status. Any IBM involvement would be upside, not the business plan.
IBM may want the category to succeed without backing BrainChip specifically
IBM’s orchestration proposition becomes more valuable when enterprise computing contains resources that genuinely differ in capability.
If nearly every important AI workload runs on one vendor’s GPUs, that vendor’s own software has a stronger claim to control workload management.
A commercially credible neuromorphic tier strengthens the argument for a neutral layer above the processors. In that sense, IBM may have an ecosystem-level interest in low-power, event-driven compute succeeding.
That does not mean IBM is committed to BrainChip as the winner. A neutral platform would ideally accommodate BrainChip, other neuromorphic technologies, custom accelerators and devices that have not yet appeared.
BrainChip therefore has an opening, not a protected position.
Akida should complement the GPU, not compete with it broadly
The power demands of AI create an opportunity, but BrainChip must define it carefully. NVIDIA and other accelerator vendors are actively improving performance per watt and full-system efficiency. GPUs will remain superior for many dense, highly parallel workloads and benefit from a vast software ecosystem.
The better question is not:
Can Akida replace the GPU?
It is:
Which work should never have been sent to the GPU in the first place?
Many systems move every sensor observation, frame, acoustic sample or network event toward central infrastructure. Even efficient central processing can waste energy and money if the system transmits routine data, keeps expensive resources continuously active or invokes a large model for a simple decision.
Akida’s role can be continuous low-level perception, filtering, anomaly detection and routing. Only selected, ambiguous or high-value events need to activate a CPU, GPU, language model or cloud service.
A concise value proposition is:
Akida does not replace the AI factory. It helps decide when the AI factory needs to be activated.
BrainChip should retain its edge strategy but broaden its meaning
Johnson’s work does not make the edge strategy obsolete. It shows that BrainChip may have defined the edge too narrowly as a commercial category.
Edge describes where computation occurs. It does not determine who buys, governs or benefits from it.
An Akida processor may sit in a sensor, vehicle, wearable, gateway, communications device or industrial machine while still being provisioned by enterprise IT, monitored centrally, governed by security policy, updated through a model lifecycle and connected to central GPU, cloud or mainframe workflows.
The physical computation remains at the edge. The buyer, operating model and economic benefit become enterprise-wide.
The strategic shift is therefore not from edge to cloud. It is from standalone edge intelligence to enterprise-managed distributed intelligence.
What BrainChip should do next
1. Preserve the embedded beachhead: BrainChip should continue pursuing applications where always-on operation, low power, privacy, local adaptation and constrained connectivity provide a clear advantage. That remains the most credible path to unit shipments, licences and royalties.
2. Productize the minimum enterprise enablement layer: BrainChip should not attempt to recreate Symphony, Kubernetes or a full management platform. It should provide the interfaces that allow those platforms to understand and manage Akida, including:
- Stable drivers and APIs;
- Device and capability discovery;
- Model deployment, residency and version reporting;
- Power, latency, utilization and health telemetry;
- Secure remote provisioning and tenant separation;
- Containerized service templates;
- Scheduling attributes and policy interfaces;
- Lifecycle, audit and provenance information.
This layer should be vendor-neutral. Symphony and LSF may be valuable integrations, but so are Kubernetes, Slurm and other common environments. The objective is to ensure that an enterprise architect can specify Akida without inventing a custom operating model.
3. Convert the demonstration catalogue into a few repeatable reference architectures: The strongest candidates are the always-on sentinel, the data-reduction gateway, the AI workload router and the managed neuromorphic fleet. Each should include supported hardware, software, security, deployment guidance and a clearly measured economic result.
4. Prove total-system economics: The decisive comparison is not Akida versus a GPU on one isolated model. It is a GPU-only operational pipeline versus an Akida-plus-GPU pipeline performing the same business task. Measurements should include energy, GPU usage, bandwidth, storage, latency, accuracy, resilience and total cost per useful event. Independent or customer-validated results would be especially valuable.
5. Build through partners: BrainChip does not need to become the enterprise head contractor. It needs to become easy for head contractors, systems integrators, defence primes, industrial OEMs, server vendors and cloud or edge providers to include neuromorphic compute.
6. Turn collaborations into a visibly managed commercial pipeline: The important criticism is not that BrainChip has no activity. It is that the market has limited evidence of material, repeatable and recurring revenue relative to the company’s ambitions. Credibility will improve as relationships move clearly from evaluation to paid proof of concept, licence, design win, production and recurring royalties or orders.
The principal risks
- The enterprise narrative could distract BrainChip from markets where its advantages are easiest to prove.
- Enterprise enablement also creates substantial software, security, documentation and support obligations.
- A vendor-neutral architecture makes Akida easier to include, but also easier to replace.
- Power efficiency alone is not a moat; customers will also judge model compatibility, accuracy, developer experience, supply continuity and support.
BrainChip must also avoid overstating Johnson’s IBM affiliation. The work is valuable as technical evidence and market education, not as a substitute for corporate endorsement or production qualification.
Conclusion
- Johnson has created a significant strategic opportunity for BrainChip. He has supplied use-case exploration, architectural patterns, integration experiments and a vocabulary connecting Akida with enterprise infrastructure. But he has not created the business.
- The most valuable outcome is not necessarily a cheque from IBM. It is the possibility that Akida can be specified as a recognised low-power compute tier within enterprise architecture.
- BrainChip should retain edge as its commercial beachhead while expanding the proposition upward:
The edge device is where Akida runs.
The enterprise fabric is how Akida is governed.
The total-system saving is why Akida is purchased.
This does not require BrainChip to defeat NVIDIA. It requires BrainChip to prove that enterprises can obtain more value from GPUs and other high-cost resources by using Akida to prevent unnecessary work from reaching them.
The strongest commercial message is therefore not:
Akida is a better GPU.
It is:
Akida determines which data, events and workloads deserve the power of the GPU.
Johnson has made that proposition technically imaginable. BrainChip’s task is to make it supported, measurable, purchasable and repeatable.
