Showing Posts From

Architecture

Seeing opportunities with AI

Artificial Intelligence (AI) is changing the way businesses operate, offering new opportunities and challenges. As a C-level executive, it's important to understand how AI can benefit your company while managing the risks involved. Setting Your AI Goals First, you need to decide what you want to achieve with AI. Do you want to use it to improve internal processes or to create new products and services? Your ambition will guide your strategy and set realistic goals. For example, AI can help streamline back-office tasks, making them faster and more efficient. Or, you might use AI to offer personalized customer experiences, which can lead to higher customer satisfaction and loyalty. Choosing the Right Approach Next, consider how you will implement AI. There are different ways to do this. You can use pre-built AI tools that are already available. This is quick and doesn’t require much technical knowledge, but it may not fit your specific needs perfectly. Alternatively, you can adapt existing models with your own data to make them more tailored to your business. This approach is more flexible but requires more expertise. Lastly, you can develop your own AI system from scratch. This gives you full control but is more expensive and time-consuming. Choosing the right path is crucial. It affects how quickly you can start using AI and how much it will cost. For instance, if your goal is to quickly improve customer service, a pre-built solution might be the best choice. If you need a highly customized solution for a specific problem, developing your own AI system might be necessary. Navigating the Risks Using AI also comes with risks. These include unreliable outputs, data privacy issues, cyber threats, and regulatory concerns. For example, AI systems can sometimes produce incorrect or unexpected results. This can happen if the data used to train the AI is flawed or if the system encounters new situations it hasn’t seen before. Ensuring data privacy is crucial, especially when handling sensitive information. You need to comply with regulations like GDPR in Europe or HIPAA in the U.S. Cyber threats are also a concern. AI systems can be targeted by hackers, putting your data at risk. This means you need to have robust cybersecurity measures in place. Additionally, different countries have different rules about AI, and you need to follow them. This can be complex, as regulations can change quickly and vary widely. For instance, regular audits and compliance checks can help ensure you stay within legal boundaries. Leading with Vision and Prudence Leading with AI requires a balanced approach. You need to support innovation while also ensuring safety and ethical considerations. This involves engaging stakeholders, balancing speed and caution, and fostering a culture of learning. Engaging stakeholders means talking to everyone involved, from developers to end-users, to get their input and support. This helps build a sense of ownership and alignment. Balancing speed and caution is also important. You need to move fast to stay ahead of competitors but take time to ensure your AI is reliable and secure. Fostering a culture of learning means encouraging your team to learn about AI and keep up with new developments. This helps keep your organization ahead of the curve. Wrapping Up AI offers a unique chance for C-level executives to drive growth and innovation. However, it also presents significant challenges. By carefully planning and managing risks, you can use AI to improve your business and stay ahead of the competition. In summary, leading with AI means setting clear goals, choosing the right deployment strategy, and being prepared for risks. With the right approach, you can unlock the full potential of AI for your organization. True leadership means guiding your company through the complexities of AI with vision and resilience.

Co-managed IT explained: who is really responsible?

Choosing how to run your IT infrastructure is one of the most important strategic decisions a business can make. However, many business leaders struggle with confusing terminology in the IT service provider landscape. Terms like co-managed IT, co-sourcing, fully managed services, and co-creation are often used incorrectly, leading to failed partnerships and unclear expectations. Understanding what these models actually mean, how responsibilities are divided, and how financial billing works is essential before signing any contract. The landscape of IT management models To make informed choices, business leaders must clearly distinguish between the different ways IT services can be delivered and organized. Under an insourcing model, a business handles all technology needs internally by hiring and managing its own personnel. Outsourcing, by contrast, transfers an entire process or department to an external provider who guarantees specific performance targets. Co-sourcing takes a staff augmentation approach by bringing in external personnel to work under your internal team's direction, adding temporary capacity without shifting operational control. Service delivery models also differ in scope and management approach. A standard managed service focuses on buying a specific functional outcome under a strict agreement, while remote managed services rely on software tools to monitor systems from a distance. Fully managed services go a step further by handing over complete operational responsibility for the entire IT environment to an external partner. Finally, co-managed IT involves an internal team and a provider managing a domain together, whereas co-creation focuses on jointly developing new digital products rather than managing existing systems. Deep dive into co-managed IT: what it is and what it is not Co-managed IT is often misunderstood in the service provider market, where it is frequently confused with buying extra staff or single software tools. In reality, a true co-managed setup is a joint operational partnership. Both the internal IT team and the external provider actively manage a specific domain together by sharing access to management platforms, support queues, and daily workflows. Both parties share equal accountability for system health, overall uptime, and cybersecurity. This approach is fundamentally different from other sourcing arrangements. It is not co-sourcing because co-sourcing merely supplies extra hands without transferring operational accountability to the vendor. It is also distinct from co-creation, which develops new intellectual property, and traditional outsourcing, which removes the internal team from daily operations entirely. Companies select co-managed models when they have a capable internal team that understands the business, but needs enterprise-grade tools, 24/7 coverage, and specialized knowledge. Financially, co-managed services usually rely on a predictable monthly fee per user or device, combined with set rates for project support. Deep dive into co-creation: what it is and what it is not Co-creation is another term that is often misused when organizations confuse custom software development with operational IT management. At its core, co-creation is a collaborative development strategy where a client and a technology vendor build a software tool together. The client provides domain expertise, practical feedback, and operational requirements, while the vendor contributes technical architecture, software engineering, and scalable infrastructure. This model should not be confused with standard custom software development, where a client pays the full cost to keep exclusive rights. Nor should it be mistaken for co-managed IT or co-sourcing, as co-creation focuses on building new digital tools rather than supporting daily IT operations. Businesses choose co-creation when standard commercial software falls short, but building custom tools alone is financially unfeasible. Financially, the client typically receives lower development rates or early software access. In return, the vendor retains the core intellectual property and creative freedom, allowing them to market and sell the solution to other commercial customers. The shared responsibility model: operational versus legal reality When working with an external IT partner, dividing responsibilities correctly is critical to avoiding operational gaps and legal surprises.IT Sourcing Model Operational Execution Operational Responsibility Legal Accountability Common Billing StructureInsourcing Internal staff Internal IT management Internal business board Internal salaries and capital spendOutsourcing External provider External service provider Internal business board Fixed monthly contract or service feeCo-sourcing Internal staff & external personnel Internal IT management Internal business board Time and materials or daily ratesCo-managed Shared internal and external team Joint shared responsibility Internal business board Fixed fee per user/device + project rateCo-creation Joint development team Joint development leadership Internal business board Discounted dev fees + IP retentionFully Managed External provider External service provider Internal business board Fixed monthly fee per user or deviceOperationally, you can delegate tasks and share daily responsibilities with a partner. In a co-managed environment, the vendor might handle backup management and software patches while your internal team supports end users. If a backup fails due to vendor negligence, the vendor is operationally accountable based on agreed service levels. However, legal responsibility works very differently. Regulators and courts hold your board of directors legally accountable if a cyberattack occurs or privacy laws are violated. While you can seek financial damages from a partner for breach of contract, ultimate legal accountability remains with your business. Closing thoughts Modern IT management requires a clear understanding of where effort ends and true responsibility begins. Misidentifying your sourcing model leads to operational confusion, unfulfilled promises, and unmanaged business risk. By defining roles, financial structures, and legal boundaries early, organizations can build effective partnerships that protect their operations. True IT partnerships are built on shared operational accountability, but business leaders must remember that legal responsibility can never be outsourced.

Large vs. Small Language Models: Understanding the differences and choosing the right tool

In the early days of generative artificial intelligence, tech companies believed one main rule: bigger is always better. Massive AI models like OpenAI's GPT-4, Google's Gemini Ultra, and Meta's Llama-3 proved that adding hundreds of billions of parameters unlocked incredible skills. These models could solve complex logic problems, write software, and translate languages easily. However, a new trend is taking over the tech world: Small Language Models (SLMs). Models such as Microsoft's Phi-3, Google's Gemma, and Meta's Llama-3-8B show that smaller models can also be smart, fast, and much cheaper to use. To understand the AI landscape today, models are generally divided into three main categories:Large Language Models (LLMs) [70B+ Parameters]: Massive models trained on huge amounts of internet data. They require powerful cloud servers to run and act as general-purpose experts. Medium Language Models [13B to 70B Parameters]: Balanced models that offer strong reasoning skills while still being easier for companies to host privately. Small Language Models (SLMs) [1B to 10B Parameters]: Compact models designed to run efficiently on small hardware, such as regular laptops, smartphones, or small internal company servers.Hardware constraints: Why model size matters To understand why SLMs are becoming so popular, we need to look at computer hardware, specifically graphics memory (VRAM) and speed. Memory requirements (VRAM) To run an AI model, its weights (parameters) must be loaded directly into a computer's high-speed graphics memory.A large 70-billion parameter model needs around 140 GB of VRAM to run at standard quality. This requires high-end enterprise hardware costing tens of thousands of dollars. In contrast, a small 8-billion parameter model can be compressed (quantized) to run using less than 5 GB of VRAM. This means it can easily run on a standard work laptop or a modern smartphone.Speed and latency Big models need to move massive amounts of data back and forth through hardware every time they generate a word. Smaller models carry much less data, which allows them to generate text much faster. This makes SLMs ideal for real-time tasks like live customer chat or typing assistance. How small models get so smart How can a small model perform almost as well as a giant model from a few years ago? The secret lies in high-quality data and smart training techniques. Traditional LLMs learn from raw internet text (billions of webpages, social media posts, and slang). Modern SLMs, on the other hand, learn from curated, high-quality "textbook" data and simplified lessons from larger models.Filtered Synthetic Data: Instead of learning from random internet chatter, modern SLMs are trained on clean, high-quality data created by larger AI models. This includes clear coding examples, textbooks, and step-by-step logic exercises. Knowledge Distillation: This is a process where a large "Teacher" model helps train a smaller "Student" model. The student learns to copy the reasoning patterns of the teacher without needing the giant memory size.Key differences at a glanceFeature Large Language Model (LLM) Small Language Model (SLM)Model Size 70B to 1 Trillion+ parameters 1B to 10B parametersHardware Needed Massive enterprise GPU servers Standard laptops, phones, single GPUsMemory Footprint Very High (100GB+ VRAM) Low (2GB to 10GB VRAM)Response Speed Slower for large answers Extremely fast generationOperating Cost High cloud API or server fees Very cheap to host locallyData Privacy Data usually sent to the cloud Data can stay fully on your local deviceCombining SLMs with company data (RAG) Many organizations assume they need a giant AI model to understand their company's internal files. However, using an AI model as a giant memory bank is inefficient and often leads to false answers (hallucinations). Instead, smart companies combine Small Language Models with a system called Retrieval-Augmented Generation (RAG):Step 1: User asks a question. Step 2: The system searches internal company documents for the facts. Step 3: The exact document text is given to the SLM. Step 4: The SLM reads the text and writes a clear answer.Because the SLM does not need to memorize all company facts inside its parameters, a small 8B model paired with RAG often outperforms a large, expensive LLM at a fraction of the cost. When to choose an LLM vs. an SLM Choosing the right model depends on your specific goals, budget, and privacy requirements. Choose a Large Language Model (LLM) when:You need complex reasoning: Writing complicated software code, analyzing vague legal documents, or solving advanced scientific problems. You build autonomous agents: AI systems that need to plan multiple steps and interact with external tools independently. Your queries are unpredictable: Your application covers many completely different subjects without a fixed focus.Choose a Small Language Model (SLM) when:Speed is critical: Applications like real-time translation, autocomplete, or instant customer support. Privacy is mandatory: Healthcare, finance, or legal tasks where data cannot leave the local building or device. You operate on a budget: Running high volumes of daily requests without paying expensive cloud API subscription fees.Closing thoughts Artificial intelligence is no longer just about building the largest possible model. While giant LLMs remain important for cutting-edge research and complex logic, Small Language Models are proving to be the most practical choice for daily business operations. By using clean training data, clever optimization, and targeted document systems, SLMs deliver fast, private, and cost-effective performance. The best AI architecture is not about using the biggest model available, but finding the smallest model that can solve your problem effectively.

AI didn't replace engineering. We just stopped talking about it.

Artificial Intelligence has become impossible to ignore. Open Gartner. AI. Read CIO.com. AI. Attend Microsoft Build, Google I/O or AWS Summit. AI. Scroll through LinkedIn for five minutes and you'll quickly get the impression that every meaningful conversation in technology now begins and ends with large language models, autonomous agents and AI-assisted development. I understand the excitement. AI is a remarkable technological breakthrough, and its impact will be difficult to overstate. But I've started wondering about something else. Not what we're talking about. What we've stopped talking about. The conversations that quietly disappeared A few years ago, our industry spent enormous amounts of time discussing operating models, governance, architecture, automation, platform engineering and cloud operating practices. Those conversations weren't glamorous. They rarely filled conference halls. They certainly didn't dominate social media. But they mattered. Because they determined whether technology actually worked once the keynote was over. Today those disciplines seem strangely absent from the conversation, as though AI somehow made them less relevant. It didn't. If anything, it made them significantly more important. Engineering never disappeared One of the more curious assumptions behind today's AI enthusiasm is that intelligence somehow compensates for engineering. That if an AI model can generate code, architecture becomes less important. That governance becomes something you can add later. That operational excellence is simply another problem AI will eventually solve. I'm not convinced. Software has never failed because people lacked ideas. It usually fails because complexity quietly grows beyond anyone's ability to understand or control it. AI doesn't remove that complexity. It introduces an entirely new category of it. Unlike traditional software, these systems are probabilistic. They don't always behave the same way twice. They require validation instead of assumption, observation instead of certainty. That doesn't reduce the need for engineering discipline. It raises the standard. Demonstrations have an unfair advantage One reason the current conversation feels so optimistic is that most of what we see are demonstrations. Someone builds an agent in twenty minutes. Another team generates an application from a prompt. A startup orchestrates half a dozen AI services into something that looks almost magical. And genuinely—it often is impressive. But demonstrations have an unfair advantage. They don't have to survive production. They don't have to operate for three years. They don't have to pass security reviews. They don't have to explain themselves during an audit. They don't wake someone up at three o'clock in the morning because an automated decision suddenly affected thousands of customers. Production has always been where technology stops being exciting and starts becoming accountable. That hasn't changed. Abstraction is a wonderful servant The cloud taught us an important lesson: Abstraction is incredibly powerful. We no longer think about physical servers before deploying an application. Kubernetes allows developers to focus on workloads instead of individual machines. Managed services remove enormous amounts of operational burden. Those are extraordinary achievements. But abstraction has always come with an implicit agreement. Someone still needs to understand what happens underneath. Every abstraction layer increases productivity for thousands of people while simultaneously reducing the number of people who understand the foundation beneath it. That trade-off is acceptable. Until the abstraction breaks. Then expertise suddenly becomes scarce. I wonder what we're teaching the next generation When I speak to younger engineers, I'm often impressed by how quickly they adopt new technologies. Many can build sophisticated cloud-native applications long before they have ever managed a physical server. Increasingly, many can also build AI-powered applications before they've fully understood distributed systems, identity, networking or storage. None of that is their fault. We teach what the industry rewards. And right now, the industry rewards speed of adoption far more visibly than depth of understanding. I sometimes wonder what happens twenty years from now. Not when AI becomes more capable. But when the people responsible for critical systems have never needed to understand the layers beneath the abstractions they inherited. The question that interests me most Perhaps this isn't really an article about Artificial Intelligence. Perhaps it's about attention. Technology has always moved in waves. Every few years we collectively decide what deserves our attention, and everything else quietly disappears into the background. Today, AI occupies almost all of that space. Meanwhile, architecture, governance, operational excellence and systems thinking continue doing what they have always done. Quietly determining whether ambitious ideas become reliable systems. Or expensive experiments. Final reflection I have no doubt that Artificial Intelligence will transform our industry. I also have no doubt that most organizations are underestimating what it takes to operationalize it responsibly. Because intelligence alone has never been enough. Not in software. Not in leadership. Not in engineering. Perhaps that is what concerns me most. We celebrate every new abstraction as progress, while paying remarkably little attention to the knowledge it slowly replaces. Every generation of technology asks us to understand a little less of what happens underneath. AI simply accelerates that trend. Maybe that is inevitable. But history has rarely been kind to civilizations that confuse convenience with understanding. The industry is celebrating intelligence while quietly abandoning wisdom. And history has never been particularly kind to civilizations that confused the two.

Digital sovereignty is not where your cloud runs

Organizations often talk about digital sovereignty as if it is a geographical problem. As if moving workloads from one region to another, or choosing a “European cloud”, somehow resolves it by default. That framing is comfortable. It is also misleading. Because digital sovereignty is not defined by where your cloud runs. It is defined by what you depend on, who controls those dependencies, and how quickly that control can shift without you noticing. And in most modern architectures, those answers are far less reassuring than organizations assume. The illusion of location-based control One of the most persistent misunderstandings in cloud strategy is the idea that data residency equals sovereignty. If data is stored in a specific country or region, the thinking goes, it must be under that jurisdiction’s control. Therefore, the organization is sovereign. But sovereignty is not a storage property. It is an operational condition. Modern cloud environments separate storage, compute, identity, observability, orchestration, and security into distributed services. Even if data is physically stored within a defined region, the control plane often is not. Identity providers, logging systems, container orchestration, key management services, and telemetry pipelines may all cross borders by design. And each of those layers introduces external dependency. So what looks like sovereignty at the infrastructure layer can still be deep dependency at the control layer. The real dependency map is not obvious Most organizations can tell you where their workloads run. Far fewer can explain:Who controls their identity system Where authentication and authorization decisions are evaluated Which external APIs are critical to deployment pipelines How secrets are managed and rotated What happens if a major cloud control plane becomes unavailableThese are not edge cases. They are core architectural facts. Yet they are often treated as implementation details rather than strategic dependencies. The result is a mismatch between perceived autonomy and actual control. A system may look sovereign on a slide deck while being tightly coupled to a small number of global providers in practice. Sovereignty is not binary Another common mistake is treating digital sovereignty as a yes-or-no state. Either you are sovereign, or you are not. Reality is more nuanced. Sovereignty exists on a spectrum of control across multiple dimensions:Data sovereignty: Where data is stored and under which legal regimes it falls Operational sovereignty: Who can change, deploy, or interrupt systems Technical sovereignty: How replaceable core components are Economic sovereignty: How easily costs can be influenced externally Vendor sovereignty: How dependent you are on specific providers or ecosystemsAn organization can be strong in one dimension and weak in another. For example, you might host data locally while remaining fully dependent on a single global identity provider. Or you might have multi-cloud infrastructure but still rely on one provider’s proprietary orchestration layer. Calling this “sovereign” or “not sovereign” misses the point entirely. The real question is: where are you constrained without realizing it? Cloud convenience is a design trade-off Cloud platforms are powerful because they reduce complexity. Managed services remove the need to operate infrastructure at scale. APIs abstract away operational burden. Integrated tooling accelerates delivery. But every abstraction is also a dependency. When you adopt a managed database, you gain operational simplicity. You also accept a specific backup model, a specific failover mechanism, and a specific pricing structure. When you adopt a managed identity provider, you gain security and standardization. You also accept that authentication is no longer fully under your control. These are not flaws. They are trade-offs. The problem arises when organizations treat these trade-offs as reversible defaults rather than strategic commitments. The hidden concentration of control Over time, cloud adoption tends to concentrate control rather than distribute it. Even in multi-cloud environments, the same patterns emerge: One provider becomes the primary identity source One ecosystem dominates observability One pipeline tool becomes the standard deployment mechanism One set of APIs defines infrastructure behavior This is not accidental. It is the natural outcome of efficiency seeking. But concentration introduces fragility. Not necessarily technical fragility in the form of outages, but strategic fragility: reduced negotiating power, limited exit options, and increasing difficulty to redesign systems without significant disruption. The more optimized a system becomes around a single ecosystem, the less sovereign it tends to be. The uncomfortable question: what can you actually replace? A practical way to evaluate sovereignty is not to ask where systems run, but what would happen if key components disappeared. Not hypothetically in a disaster scenario, but structurally:If your identity provider changes terms or access, how fast can you switch? If your primary cloud provider increases costs significantly, what breaks first? If a critical managed service is discontinued, do you have an exit path or just a migration project? If external connectivity is restricted, which parts of your architecture stop functioning immediately?These questions are uncomfortable because they expose design assumptions that are usually left unchallenged. Most organizations discover that their “sovereign” architecture contains far fewer independent components than expected. Sovereignty requires intentional friction True digital sovereignty is not achieved by avoiding cloud platforms. It is achieved by designing for optionality, even when it introduces friction. That can include:Avoiding unnecessary proprietary abstractions in core systems Designing data portability as a requirement, not a future task Separating identity from infrastructure providers Maintaining documented, tested exit strategies for critical services Ensuring that no single provider becomes a structural bottleneckNone of these decisions are purely technical. They are architectural governance choices. And they often conflict with short-term efficiency goals. Which is why they are frequently postponed. Leadership, not infrastructure, defines sovereignty At its core, digital sovereignty is not a cloud architecture problem. It is a leadership problem. Because the hardest part is not building systems that are portable or independent. The hardest part is deciding when dependency is acceptable and when it is not. Every organization will rely on external platforms. The question is not whether dependency exists, but whether it is understood, measured, and intentionally managed. Without that clarity, sovereignty becomes a narrative rather than a capability. Closing thought Digital sovereignty is not where your cloud runs. It is whether you could still operate if your assumptions about that cloud stopped being true. And in most modern architectures, that question is less theoretical than it seems.

Rolf Schutten
22 May, 2026
- Privacy

Data is not neutral. It changes your organization.

Most discussions about data start from a familiar assumption: more data is better. Better insights. Better decisions. Better products. Better personalization. It sounds rational, almost self-evident. And in many cases, it is also true. But it misses something fundamental. Data is not a passive resource you collect and occasionally analyze. Data actively reshapes the organization that collects it. Every dataset introduces dependencies. Every tracking mechanism introduces obligations. Every retention policy introduces long-term complexity. And every attempt to “just store it for later” quietly expands the system you are responsible for operating. Over time, data stops being something you use. It becomes something you maintain. The illusion of harmless collection Data collection often begins small. A tracking event here. A user attribute there. A logging mechanism added “just in case.” A consent banner implemented to stay compliant. Individually, none of these decisions feel significant. They are easy to justify, easy to implement, and easy to ignore once they are in place. But data does not remain isolated. It spreads through systems. Once collected, data tends to move:From frontend to backend From application to analytics platform From analytics platform to data warehouse From warehouse to dashboards, models, exports, and external integrationsWhat starts as a simple event becomes a chain of systems that depend on its continued existence. And at that point, removing the data is no longer a technical decision. It is an organizational disruption. Data creates responsibility before it creates value A common misconception is that data becomes “valuable” once it is analyzed. In reality, data becomes expensive the moment it is stored. Not only in infrastructure costs, but in responsibility:Who is allowed to access it? How long may it be retained? Under which legal basis is it processed? How is it secured across environments? How is it deleted when requested?These questions do not appear after value creation. They appear immediately after collection. And they do not scale linearly. The more data you collect, the more governance surface area you create. The more systems you connect, the more failure modes you introduce. The more teams rely on it, the harder it becomes to change anything. At some point, organizations are no longer asking “what can we learn from this data?” They are asking “what breaks if we stop collecting it?” That is a very different question. The feedback loop no one budgets for Data does not just describe reality. It influences it. Once organizations start measuring behavior, they begin to optimize for what is measurable. This creates a feedback loop:You define metrics based on available data Teams optimize toward those metrics Behavior shifts to improve measured outcomes New edge cases emerge More data is collected to explain those edge cases The system becomes more complex and more self-referentialOver time, the metric becomes the target. The target becomes the system. And the system becomes increasingly dependent on its own instrumentation. What started as observation becomes control. And what started as control becomes constraint. Privacy is not a layer. It is a constraint on design Privacy is often treated as something you “add” to a system after the fact. A policy. A banner. A compliance checklist. A legal review step before launch. But privacy is not a layer that sits on top of architecture. It is a set of constraints that should shape architecture from the beginning. Because once data exists, privacy is no longer abstract. It becomes operational:You must track where data flows You must know where it is stored You must control who can access it You must be able to delete it reliably You must prove all of the aboveThis is not paperwork. It is system design. And systems that were not designed with these constraints in mind tend to accumulate “privacy debt”: workarounds, exceptions, undocumented pipelines, and fragile deletion mechanisms that only work under ideal conditions. The hidden cost of “just in case” data One of the most expensive phrases in data strategy is: “we might need it later.” It is rarely challenged because it feels prudent. Safe. Responsible. But in practice, “just in case” data is rarely used proportionally to its cost. Instead, it accumulates indefinitely:Old events no longer tied to active product decisions Historical logs kept beyond operational relevance User attributes that outlive their original purpose Datasets retained “because storage is cheap”Storage may be cheap. Understanding it is not. Every additional dataset increases:Complexity of access control Risk surface for breaches Cost of compliance audits Difficulty of migration or redesign Cognitive load for engineers and analystsEventually, organizations discover they are no longer collecting data because it is useful. They are collecting it because no one is confident enough to remove it. Data concentration creates architectural inertia As data systems mature, they tend to centralize. Data lakes, warehouses, and unified analytics platforms are built to reduce fragmentation. And they succeed at doing so. But they also create a new form of dependency: architectural inertia. Once multiple teams depend on a centralized dataset, changes to that dataset become politically and technically expensive. Even small schema changes require coordination. Even simple deletions require impact analysis. Over time, the data platform becomes a stabilizing force that resists change. Not because it is designed that way, but because everything depends on it. And when everything depends on it, nothing can easily evolve. The real question is not “can we collect this?” Most organizations still evaluate data decisions in terms of permission:Can we collect this? Is this allowed? Do users consent? Are we compliant?These are necessary questions. But they are not sufficient. The more important question is structural: What does this decision force us to maintain in five years? Because every data point is a long-term commitment to:Infrastructure Governance Security Legal interpretation Organizational knowledgeAnd those commitments rarely decrease over time. They accumulate. Data maturity is not about scale. It is about restraint. A mature data organization is not one that collects everything. It is one that understands the lifecycle of what it collects. That means:Knowing when data stops being useful Designing systems that allow safe removal Avoiding unnecessary granularity in the first place Treating retention as a cost, not a default Being explicit about what is not collectedThis is often counterintuitive. Because maturity is usually associated with capability expansion. But in data systems, maturity often shows up as disciplined limitation. Not everything that can be measured should be measured. And not everything that is measured should be kept. Closing thought Data is often described as an asset. But that description is incomplete. Data is also a commitment. A dependency. A governance responsibility. And, increasingly, a structural constraint on how an organization can evolve. The organizations that treat data as neutral will continue to accumulate complexity they do not fully understand. The ones that recognize its impact on architecture and control will design differently from the start. Not by collecting less for the sake of it. But by understanding that every data decision is also a decision about the shape of the organization itself.