AI Readiness Is an Architecture Question

AI Strategy Series | Article 6 of 20

Building the Intelligent Enterprise

Every enterprise wants to know whether it is ready for artificial intelligence.

Consultants offer AI readiness assessments. Technology vendors provide maturity models. Executives commission surveys examining employee skills, data quality, governance practices, technology investments, and organizational culture.

These assessments can provide useful information.

But they frequently overlook a more fundamental question.

Can the enterprise’s existing architecture support the AI capabilities it intends to deploy?

An organization may have enthusiastic leadership, substantial AI funding, experienced data scientists, and employees eager to adopt intelligent tools.

It may also have fragmented applications, inconsistent integration patterns, inaccessible information, obsolete infrastructure, and business processes that depend on undocumented manual intervention.

Under those conditions, AI adoption may be possible.

Enterprise-scale AI execution may not be.

The distinction matters.

Deploying an AI assistant is not the same as establishing an enterprise capability.

Demonstrating an autonomous agent is not the same as integrating one into a production operating environment.

And successfully completing a pilot does not establish that the organization can support hundreds of AI-enabled workflows across multiple business functions.

AI readiness is therefore not simply a question of organizational enthusiasm, technical skills, or model availability.

It is a question of whether the enterprise possesses the architectural capabilities required to make artificial intelligence reliable, reusable, secure, and operationally sustainable.

Your AI strategy may describe what the enterprise wants to become. Your architecture determines whether it can get there.

The Readiness Assessment Problem

Most AI readiness assessments examine several familiar dimensions.

Does the organization have an AI strategy?

Does leadership support AI adoption?

Are employees sufficiently skilled?

Is the data environment mature?

Are governance policies established?

Is funding available?

These are legitimate considerations.

However, a favorable assessment across these dimensions does not necessarily mean the organization can operationalize AI at enterprise scale.

Consider a hypothetical manufacturer with a well-funded AI program.

The executive team has established clear strategic objectives.

Employees have completed AI training.

The organization has identified promising applications involving predictive maintenance, production scheduling, supplier coordination, and quality assurance.

Its initial pilots demonstrate encouraging results.

Yet the underlying technology environment presents substantial obstacles.

Production systems use inconsistent interfaces.

Equipment telemetry is stored in incompatible formats.

Inventory information is distributed across multiple applications.

Critical business rules exist inside legacy systems.

Operational data cannot be accessed consistently.

Integration changes require lengthy development cycles.

The organization may be strategically ready to pursue AI.

It is not necessarily architecturally ready to execute its ambitions.

The problem is not a lack of AI capability.

It is a mismatch between the intended AI operating model and the enterprise architecture supporting it.

AI readiness must be evaluated against the business capabilities an organization intends to create, not merely the technologies it has acquired.

AI Pilots Conceal Architectural Weaknesses

AI pilots are valuable because they allow organizations to test assumptions, evaluate technology, and explore business opportunities without committing to full-scale deployment.

But pilots frequently operate under conditions that do not resemble production environments.

A pilot may use a carefully prepared dataset.

It may connect to only one application.

It may rely on a small group of experienced employees.

Its workflow may contain manual steps that are not visible in the demonstration.

Its operating costs may be subsidized by temporary infrastructure or limited usage.

Its security and access requirements may be narrower than those of a production deployment.

These conditions are not inherently inappropriate.

They become problematic when pilot success is interpreted as evidence of enterprise readiness.

Imagine an AI agent designed to help resolve customer service issues.

During the pilot, the agent retrieves information from a prepared knowledge repository and recommends responses to service representatives.

The results are promising.

Management approves expansion.

The production implementation must now retrieve customer records, interpret service agreements, evaluate warranty eligibility, coordinate replacement inventory, and update multiple enterprise applications.

Suddenly, the architecture matters.

The customer database does not expose the required information through a supported interface.

Contractual terms are stored in inconsistent document formats.

Inventory information is delayed.

Different applications use conflicting customer identifiers.

The organization has no established mechanism for managing agent permissions across systems.

The pilot demonstrated that AI could perform a task under controlled conditions.

It did not demonstrate that the enterprise could support the complete business process.

This is one reason AI initiatives can struggle when moving from experimentation into production.

A successful AI pilot validates a possibility. It does not automatically validate the architecture required to sustain that possibility.

Enterprise Architecture Is the Foundation of AI Execution

Enterprise architecture provides the structural relationships among business capabilities, processes, information, applications, technology, and organizational responsibilities.

Its purpose is not simply to document systems.

It is to help the enterprise make coherent technology decisions in support of business strategy.

Artificial intelligence increases the importance of those relationships.

Traditional enterprise applications generally operate within defined functional boundaries.

An ERP system manages financial and operational transactions.

A CRM platform supports customer relationships.

A supply chain application coordinates procurement and fulfillment.

AI increasingly operates across those boundaries.

An intelligent agent may retrieve information from one system, interpret it using another service, evaluate business rules, select an action, and execute that action through a third application.

That workflow depends on multiple architectural capabilities functioning together.

The enterprise must provide reliable access to information.

Applications must expose appropriate interfaces.

Business rules must be accessible or enforceable.

Identity and authorization mechanisms must support nonhuman actors.

Operational monitoring must extend across the workflow.

Failures must be detected and handled.

Actions must be traceable.

The resulting architecture is not simply an AI model connected to a collection of applications.

It is a coordinated environment in which intelligence becomes part of enterprise execution.

AI changes enterprise architecture because intelligence is becoming an active participant in business processes rather than merely a tool used by employees.

The Six Architectural Capabilities That Determine AI Readiness

An enterprise does not need to modernize every system before deploying AI.

It does need to understand which architectural capabilities are required for the outcomes it intends to achieve.

Six capabilities deserve particular attention.

1. Information Architecture

AI systems depend on the availability, meaning, quality, and authority of enterprise information.

As discussed in Article 5, Your AI Strategy Inherits Your Data Strategy, sophisticated models cannot reliably compensate for inconsistent business definitions, inaccessible records, or unresolved information authority.

Information architecture establishes how enterprise information is structured, related, classified, and interpreted.

For AI applications, this may involve:

• Authoritative information sources.
• Consistent business definitions.
• Metadata and semantic relationships.
• Data quality requirements.
• Information provenance.
• Governed retrieval mechanisms.
• Contextual access to structured and unstructured information.

The objective is not to centralize every piece of enterprise information.

It is to make relevant information accessible and interpretable through appropriate architectural mechanisms.

A customer service agent, for example, may require information from CRM, billing, warranty, inventory, and document management systems.

Those systems do not necessarily need to be consolidated.

But the enterprise must establish how their information can be interpreted together.

Without that capability, AI may generate plausible responses from incomplete or contradictory information.

2. Integration Architecture

AI applications increasingly depend on interactions across multiple enterprise systems.

Integration architecture determines whether those interactions can occur reliably and sustainably.

An enterprise with mature APIs, event-driven integration, reusable services, and well-defined application interfaces may be able to introduce AI capabilities relatively efficiently.

An enterprise dependent on manual exports, proprietary point-to-point connections, and undocumented database access may face substantial implementation challenges.

Consider an AI agent supporting procurement.

It may need to retrieve supplier information, evaluate inventory requirements, check budgets, create purchase requests, and monitor fulfillment.

If each interaction requires a custom integration, the cost of expanding AI capabilities may grow rapidly.

A reusable integration architecture changes that equation.

The same interfaces supporting one AI application may support additional applications, conventional software integrations, and future automation initiatives.

This is an important strategic distinction.

An AI application built on reusable enterprise services creates more architectural value than one that requires a new collection of proprietary connections for every use case.

3. Identity and Authorization Architecture

AI agents introduce a new category of operational actor.

They are not conventional employees.

They are not simply passive software applications.

They may act on behalf of employees, departments, or business processes while interacting with multiple enterprise systems.

That creates architectural questions about identity and authority.

How is an agent identified?

Which systems may it access?

What information may it retrieve?

Which actions may it execute?

Can its permissions change according to the task?

Who can revoke its authority?

How does the enterprise distinguish actions initiated by an agent from actions initiated by a human?

These questions become especially important when AI progresses beyond recommendations into execution.

An agent authorized to summarize invoices should not automatically possess permission to approve payments.

An agent authorized to recommend customer credits should not necessarily be able to issue unlimited refunds.

The enterprise needs authorization mechanisms that enforce these distinctions.

Model instructions alone are insufficient.

AI decision authority must be supported by enterprise identity, access, and transaction controls that operate independently of the model’s generated responses.

This is an architectural requirement, not merely a policy statement.

4. Application and Service Architecture

AI capabilities must be integrated into applications and business processes without creating unnecessary duplication or architectural fragmentation.

Organizations frequently begin by embedding AI directly into individual applications.

That approach can deliver immediate value.

However, as adoption expands, multiple teams may independently develop similar capabilities.

One department creates a document summarization service.

Another builds a separate retrieval system.

A third develops its own agent orchestration framework.

A fourth establishes an independent model evaluation environment.

Each solution may work.

Collectively, they may create unnecessary complexity.

Enterprise architecture should identify which capabilities are appropriately shared and which should remain application-specific.

Potential shared capabilities include model access, retrieval services, evaluation infrastructure, observability, integration interfaces, and selected agent execution components.

Not every enterprise requires a centralized AI platform.

But every enterprise pursuing AI at scale should understand where reuse creates value and where centralization introduces unnecessary constraints.

The objective is architectural coherence, not uniformity for its own sake.

5. Operational Architecture

AI systems must operate within the enterprise’s reliability, performance, resilience, and support requirements.

A prototype may tolerate occasional failures.

A production application supporting critical business operations may not.

Operational architecture addresses questions such as:

What happens when the AI service is unavailable?

How are failed actions detected?

Can interrupted workflows resume safely?

What happens when a model returns an unexpected response?

How are performance and operating costs monitored?

Can the enterprise identify which component caused a failure?

How are model changes tested before deployment?

What fallback mechanisms exist?

These questions are especially important for autonomous agents.

A traditional application failure may produce an error message.

An agent may partially complete a sequence of actions before encountering a failure.

For example, an agent might update a customer record, reserve inventory, and then fail before completing the associated transaction.

The enterprise must determine whether those partial actions should be reversed, completed, or escalated.

That requires deliberate workflow and transaction design.

It cannot be left entirely to the model.

6. Observability and Evidence Architecture

AI introduces new operational behaviors that enterprises must be able to understand.

Traditional application monitoring focuses on infrastructure availability, response times, errors, and transaction performance.

AI systems may require additional visibility into model selection, retrieval behavior, tool execution, workflow state, decision outcomes, and operational costs.

For consequential applications, the organization may also need to reconstruct what occurred.

Which information was available?

Which tools were invoked?

What action was requested?

Which authorization controls were applied?

What result was produced?

Did a human approve or override the action?

The required level of detail depends on the business process and its consequences.

Not every AI interaction requires extensive retention.

Privacy, security, cost, and information minimization requirements must also be considered.

But the enterprise should establish observability appropriate to the responsibilities assigned to AI.

If an AI capability becomes part of enterprise execution, its behavior must become part of enterprise operational visibility.

The Architecture of AI Agents Is Different

Agentic AI is increasing the importance of architectural readiness because agents may coordinate activities across multiple applications and services.

A conventional AI assistant typically responds to a user request.

An autonomous agent may interpret an objective, select actions, invoke tools, evaluate results, and continue working toward an outcome.

That introduces additional architectural complexity.

The enterprise must determine how tasks are initiated, how execution state is maintained, how tools are exposed, and how authority is enforced.

It must also establish how agents interact with existing business processes.

Consider an AI agent assigned to resolve a delayed customer shipment.

The agent may need to:

1. Retrieve the customer order.
2. Identify the shipment’s current status.
3. Determine whether contractual delivery commitments are at risk.
4. Evaluate available inventory.
5. Identify alternative fulfillment options.
6. Recommend or execute an appropriate corrective action.
7. Update the customer and relevant enterprise systems.

The intelligence required to evaluate alternatives is only one part of the solution.

The workflow also depends on authoritative information, application integration, transaction controls, business rules, operational monitoring, and exception handling.

An agent framework may help coordinate these activities.

It does not eliminate the enterprise architecture required to support them.

This is why agentic AI should not be treated as a collection of increasingly sophisticated chatbots.

It represents a potential change in how enterprise work is executed.

And changes in execution require corresponding architectural decisions.

AI Readiness Is Not the Same as Cloud Readiness

Some organizations assume that cloud modernization establishes AI readiness.

Cloud platforms can provide valuable foundations.

They offer scalable infrastructure, managed services, integration capabilities, security mechanisms, and access to AI models.

But moving applications to the cloud does not automatically resolve enterprise architecture problems.

A fragmented application portfolio can remain fragmented in the cloud.

Inconsistent business definitions can persist across modern data platforms.

Poorly designed integrations can become cloud-hosted poorly designed integrations.

Unclear decision authority does not disappear when an agent runs on managed infrastructure.

Cloud adoption may improve the enterprise’s technical options.

It does not guarantee architectural coherence.

The distinction is important because AI readiness requires examining how business capabilities, information, applications, and operational controls work together.

Infrastructure is part of that environment.

It is not the entire environment.

The Architectural Cost of Isolated AI Solutions

When business units independently deploy AI applications, the immediate results can be attractive.

Teams move quickly.

They solve local problems.

They avoid lengthy enterprise planning processes.

They demonstrate measurable productivity improvements.

These benefits should not be dismissed.

However, isolated implementations can create cumulative architectural costs.

Different applications may establish separate integrations to the same enterprise systems.

They may maintain duplicate information indexes.

They may apply inconsistent authorization rules.

They may use different model providers without a deliberate sourcing strategy.

They may establish incompatible monitoring and evaluation practices.

They may produce information that other systems cannot reliably interpret.

Over time, the enterprise can accumulate an AI application portfolio that resembles the fragmented software environment it spent decades attempting to modernize.

The organization gains local intelligence while increasing enterprise complexity.

This is not an argument for preventing decentralized innovation.

It is an argument for establishing architectural boundaries within which innovation can occur.

Business units should be able to experiment and develop useful capabilities.

But enterprise architecture should identify the shared services, interfaces, information standards, and operational requirements necessary to prevent avoidable fragmentation.

The objective is to accelerate AI adoption without allowing every successful experiment to become another permanent architectural exception.

The AI Readiness Assessment Should Begin With Business Capabilities

A more useful approach to AI readiness begins with the business capability the enterprise intends to improve.

Rather than asking whether the organization is generally ready for artificial intelligence, leadership should ask whether its architecture can support a specific AI-enabled outcome.

Consider three hypothetical initiatives.

Scenario 1: AI-Assisted Document Summarization

An organization wants to help employees summarize internal documents.

The application retrieves authorized documents, generates summaries, and presents them for human review.

The architectural requirements may be relatively limited.

The enterprise needs appropriate document access, information security, model integration, and mechanisms for evaluating output quality.

The application does not require authority to modify operational systems.

Its failure consequences may be manageable, depending on the documents involved and how summaries are used.

Scenario 2: AI-Enabled Customer Service

The enterprise wants AI to support customer service representatives by retrieving account information, interpreting policies, and recommending resolutions.

The architecture becomes more complex.

The application may require access to multiple systems, consistent customer identification, authoritative policy information, and integration with service workflows.

It also needs controls governing what information may be disclosed.

If the system begins updating customer records or issuing credits, additional authorization and transaction controls become necessary.

Scenario 3: Autonomous Supply Chain Coordination

The enterprise wants AI agents to monitor demand, evaluate inventory, coordinate suppliers, and execute selected procurement decisions.

The architectural requirements become substantially more demanding.

The organization needs reliable information across multiple operational systems.

It needs consistent business definitions, integration services, transaction controls, agent identities, operational monitoring, exception handling, and recovery mechanisms.

It must also establish the boundaries of delegated decision authority.

These three initiatives may all be described as enterprise AI.

Their architectural readiness requirements are fundamentally different.

A single AI maturity score cannot adequately represent those differences.

An Architecture-Based AI Readiness Framework

Enterprise leaders can evaluate proposed AI initiatives against six architectural dimensions.

Architectural Dimension	Central Readiness Question	Evidence of Readiness
Information Architecture	Can AI access and interpret the information required for the intended outcome?	Authoritative sources, documented definitions, appropriate quality and provenance
Integration Architecture	Can AI interact reliably with required enterprise systems?	Supported APIs, reusable services, defined integration contracts
Identity and Authorization	Can the enterprise enforce what AI is permitted to access and execute?	Scoped identities, permissions, transaction limits, revocation capabilities
Application and Service Architecture	Can the capability be deployed without unnecessary duplication or fragmentation?	Defined component boundaries, reusable services, maintainable interfaces
Operational Architecture	Can the capability operate reliably under production conditions?	Monitoring, exception handling, recovery procedures, capacity and cost controls
Observability and Evidence	Can the enterprise understand and reconstruct consequential AI activity?	Execution records, tool activity, decision evidence, appropriate retention controls

This framework is not intended to produce a universal readiness score.

Its purpose is to expose architectural dependencies before they become implementation failures.

Each dimension should be evaluated against the requirements of the intended business capability.

For example, an AI assistant that summarizes public documents may have modest integration and authorization requirements.

An autonomous financial processing agent may require extensive evidence across all six dimensions.

The evaluation should also distinguish between capabilities that already exist and those that must be developed.

That distinction supports better investment planning.

A proposed AI application may appear inexpensive when evaluated solely on model access and development effort.

Its actual cost may be substantially higher when the enterprise must first modernize integration interfaces, establish authoritative information sources, or implement operational controls.

Those foundational investments should be visible in the business case.

Architecture Readiness Is Also an Investment Sequencing Problem

One of the most important responsibilities of enterprise technology leadership is determining the order in which capabilities should be developed.

AI introduces a temptation to prioritize visible applications because they demonstrate immediate progress.

Executives can observe a chatbot answering questions.

They can watch an agent execute a workflow.

They can measure the time saved by an automated process.

Foundational architectural improvements are less visible.

An API modernization initiative may not produce an impressive demonstration.

A semantic information model may not attract executive attention.

An identity architecture enhancement may appear unrelated to business transformation.

Yet these investments may determine whether dozens of future AI applications can be deployed efficiently.

Consider an enterprise planning ten AI initiatives.

Each initiative requires access to customer information.

If the organization allows every project to develop its own customer data integration, it may create ten separate dependencies.

Each integration must be developed, secured, tested, monitored, and maintained.

If the enterprise instead establishes a reusable customer information service, multiple initiatives may benefit from the same foundational investment.

The service still requires investment and ongoing management.

But its value extends across the application portfolio.

This creates an important distinction between application investment and capability investment.

An application delivers a particular outcome.

A reusable architectural capability enables multiple outcomes.

Enterprise AI strategy should prioritize architectural investments according to the number, importance, and strategic value of the business capabilities they enable.

That does not mean every reusable service should be built before the first AI application.

It means leadership should identify opportunities where a modest architectural investment can reduce the cost and complexity of multiple initiatives.

Technical Debt Becomes an AI Strategy Constraint

Technical debt has traditionally been discussed in terms of maintenance costs, application complexity, outdated technologies, and development productivity.

AI introduces another consequence.

Technical debt can limit the enterprise’s ability to introduce new forms of intelligence into existing business processes.

A legacy application may continue performing its intended function reliably.

But if it cannot expose information through supported interfaces, it may be difficult to incorporate into AI-enabled workflows.

A tightly coupled system may make it difficult to separate business rules from application logic.

An undocumented integration may prevent the enterprise from safely introducing automated actions.

An obsolete identity mechanism may be unable to support appropriately scoped nonhuman access.

These limitations do not necessarily require replacing the underlying systems.

Modernization may involve introducing APIs, integration services, event interfaces, or other architectural mechanisms that make existing capabilities accessible.

The appropriate solution depends on the business value and technical constraints involved.

The strategic point is that technical debt should be evaluated partly in terms of the opportunities it prevents.

The cost of technical debt is no longer limited to maintaining yesterday’s systems. It increasingly includes the enterprise capabilities those systems cannot support tomorrow.

This changes how technology leaders should prioritize modernization investments.

An application that appears stable and inexpensive to maintain may still represent a substantial constraint on enterprise AI strategy.

The CIO’s Role Is to Connect AI Ambition With Architectural Reality

The CIO has a critical role in ensuring that AI strategy remains grounded in enterprise execution capabilities.

Business leaders should identify the outcomes they want to achieve.

AI specialists should evaluate models, techniques, and implementation approaches.

Data leaders should establish information requirements.

Security and governance functions should define appropriate controls.

Enterprise architects should evaluate how the resulting capabilities fit into the broader technology environment.

The CIO must help connect these responsibilities.

That requires more than approving AI investments.

It requires ensuring that architectural dependencies are understood, funded, and addressed.

For each significant AI initiative, technology leadership should be able to explain:

• Which business capability the investment will improve.
• Which enterprise systems and information assets it depends on.
• Which architectural capabilities already exist.
• Which capabilities must be developed or modernized.
• What operational authority the AI system will possess.
• How the solution will be integrated, monitored, and supported.
• Whether the investment creates reusable capabilities or additional fragmentation.
• How architectural readiness affects cost, implementation time, and expected business value.

These questions are not intended to slow innovation.

They are intended to prevent the enterprise from confusing a successful demonstration with a sustainable operating capability.

The CIO’s responsibility is not to make every AI initiative conform to a rigid technology standard.

It is to ensure that enterprise AI investments collectively produce a coherent and adaptable technology environment.

The Boardroom Question

Imagine a board reviewing management’s enterprise AI strategy.

The presentation includes ambitious objectives, promising use cases, projected productivity improvements, and a multiyear implementation roadmap.

The proposed investment is substantial.

Management explains which AI platforms it intends to use.

The board asks about security, governance, and expected returns.

Those are appropriate questions.

But another question deserves equal attention:

“What architectural capabilities must exist for this AI strategy to work, and how confident are we that we possess them?”

That question changes the discussion.

It requires management to identify dependencies rather than merely describe desired outcomes.

It distinguishes capabilities already available from those requiring investment.

It exposes whether projected implementation timelines depend on unresolved integration or information problems.

It also provides a basis for evaluating execution risk.

A board does not need to understand every technical component of an AI architecture.

It does need confidence that management understands the architectural conditions required to deliver the strategy.

If an organization proposes autonomous business processes while lacking reliable integration, authoritative information, enforceable permissions, or operational recovery mechanisms, those gaps are material to the investment decision.

The board should expect management to identify them.

The Executive Imperative

Artificial intelligence is creating opportunities to transform how enterprises operate.

But realizing those opportunities requires more than access to powerful models.

It requires an architecture capable of connecting intelligence to information, applications, decisions, and business execution.

The enterprise must be able to provide authoritative information.

It must expose appropriate application capabilities.

It must enforce operational authority.

It must support reliable execution.

It must observe consequential activity.

And it must maintain these capabilities as technology, business requirements, and AI systems evolve.

Organizations that ignore these requirements may accumulate isolated AI applications without establishing a sustainable enterprise capability.

They may demonstrate innovation while increasing architectural fragmentation.

They may achieve impressive pilot results while struggling to move into production.

They may invest heavily in AI platforms only to discover that their existing systems cannot support the intended operating model.

The alternative is to treat architectural readiness as an explicit component of AI strategy.

Start with the business capabilities the enterprise intends to improve.

Identify the information, integration, authorization, application, operational, and observability requirements.

Evaluate which capabilities already exist.

Determine which architectural investments will support multiple AI initiatives.

Then sequence implementation according to business value and architectural dependencies.

This approach does not require perfect architecture.

No enterprise possesses that.

It requires sufficient architectural discipline to ensure that AI investments strengthen the organization rather than create another generation of disconnected systems.

AI readiness is not measured by how many models an enterprise can deploy. It is measured by whether the enterprise can integrate intelligence into business operations reliably, securely, and sustainably.

Your AI strategy describes the future you want to build.

Your enterprise architecture determines whether that future is achievable.

And the sooner leadership recognizes that relationship, the more effectively it can turn artificial intelligence from an experimental technology into a durable enterprise capability.

References

International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023: Information Technology—Artificial Intelligence—Management System. Geneva: ISO, 2023. https://www.iso.org/standard/81230.html.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. Gaithersburg, MD: U.S. Department of Commerce, January 2023. https://doi.org/10.6028/NIST.AI.100-1.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: U.S. Department of Commerce, July 2024. https://doi.org/10.6028/NIST.AI.600-1.

The Open Group. The TOGAF Standard, 10th Edition. Reading, UK: The Open Group, 2022. https://www.opengroup.org/togaf.

The Open Group. ArchiMate 3.2 Specification. Reading, UK: The Open Group, 2022. https://www.opengroup.org/archimate-forum/archimate-overview.

World Wide Web Consortium. PROV-O: The PROV Ontology. W3C Recommendation, April 30, 2013. https://www.w3.org/TR/prov-o/.

Coming Next

Article 7 — Stop Treating RAG as an Enterprise AI Strategy

Retrieval-augmented generation has become one of the most widely adopted approaches to connecting foundation models with enterprise information.

It can be useful, practical, and relatively straightforward to implement.

But connecting an AI model to a document repository does not establish an enterprise AI strategy.

In the next article, we examine why RAG is an architectural technique rather than a strategic destination, where its limitations become consequential, and how enterprise leaders should distinguish information retrieval capabilities from the broader architecture required to support intelligent business operations.