Part I — The Enterprise Foundation

Cloud, SaaS, and the Sprawl Problem

If legacy systems are the foundation that will not move, SaaS sprawl is the layer that keeps growing. The average enterprise now runs over one hundred SaaS applications. Each team has its own tools. Each acquisition brought its own stack. Each shadow IT initiative that got promoted to production left behind its own data store. AI practitioners who assume they can find all the relevant data in one place have never mapped a real enterprise data landscape.

4.1 How Sprawl Happens

SaaS sprawl is not a failure of governance — it is the natural outcome of decentralized decision-making in organizations where individual teams can buy software with a credit card and a three-year contract. The pattern is consistent across industries:

A team has a problem. The central IT procurement process takes six months. The team buys a SaaS tool that solves the problem in six weeks. The tool works. The team becomes dependent on it. Two years later, it is in the budget as a line item, the data it holds is operationally critical, and IT has never heard of it.

Multiply this by fifty teams over ten years, add three acquisitions with their own independent SaaS stacks, and the result is a data landscape where customer data lives in seventeen different systems, none of which have the same customer ID format.

Mergers and acquisitions accelerate sprawl. When Company A acquires Company B, both organizations continue running their existing tools while the integration project is planned. The integration project takes longer than expected. The tools become entrenched. Five years after the acquisition, some of Company B's original systems are still running alongside Company A's.

4.2 The Data Fragmentation Problem

Sprawl creates fragmentation, and fragmentation is the enemy of AI. AI systems that need a complete view of a customer, a transaction, a product, or an asset must aggregate data from multiple systems that use different identifiers, different schema conventions, different data quality standards, and different access models.

The fragmentation problem has three components:

Identity fragmentation — the same real-world entity (a customer, a product, a supplier) has different IDs in different systems. Joining across systems requires an identity resolution layer that may not exist or may not be complete.

Schema fragmentation — the same concept is represented differently in different systems. "Customer status" might be an enum in the CRM, a free-text field in the support system, and a derived flag in the data warehouse. Normalizing these into a consistent representation for AI training or inference requires domain knowledge that is rarely documented.

Quality fragmentation — each system has its own data quality characteristics. The CRM is well-maintained because sales leadership enforces data hygiene. The support system is poorly maintained because agents are incentivized on speed, not data quality. An AI trained on combined data inherits both quality profiles.

4.3 Cloud Complexity

The move to cloud was supposed to simplify enterprise IT. In many organizations, it added a new layer of complexity instead. The typical enterprise now runs workloads across multiple cloud providers (AWS, Azure, GCP), a private data center, and dozens of SaaS platforms — each with its own identity model, network security model, and data governance framework.

For AI practitioners, multi-cloud environments create specific challenges:

Data gravity — large data sets are expensive to move between cloud environments. An AI model that needs to train on data in Azure and data in GCP faces real egress costs and latency constraints that affect what architectures are practical.

Identity federation — users and services must authenticate across multiple environments. AI systems that call APIs in multiple cloud environments must manage credentials, service accounts, and federation agreements that vary by provider.

Compliance boundary confusion — different cloud environments may have different compliance certifications, different data residency commitments, and different audit logging capabilities. An AI system that processes regulated data across cloud boundaries must navigate all of these.

4.4 AI in Sprawled Environments

The practical response to sprawl is not to solve sprawl before starting AI — that is a multi-year enterprise architecture initiative that will not wait for the AI opportunity. The practical response is to design AI initiatives that are explicit about their data scope.

Start with a bounded data domain. Rather than asking "what data do we have?" ask "what data do we need for this specific task, and where does it live?" A bounded scope makes the integration work tractable and prevents the initiative from becoming a data integration project with an AI veneer.

Build an integration inventory before building the model. For each required data source: what is the access mechanism, what is the data format, what is the refresh rate, what are the quality characteristics, and what are the compliance obligations? This inventory is the scoping document for the integration work.

Design for the data you can access, not the data you wish you had. The most sophisticated AI model trained on inaccessible data produces no value. A simpler model trained on accessible, high-quality data produces production results. Scoping to accessible data is not a compromise — it is the prerequisite for shipping.