Foundry is uniquely suited to enable established players to unlock the value they hold in their legacies: their people as well as their technology and data.
I spent more than ten years with Palantir as an architect and software engineer, much of which was spent working with big, established organisations. Companies with legacies, both technical and institutional, and a tremendous power to innovate once given the tools to do their jobs.
The experience I had deploying Foundry was unlike conventional software projects. “Legacy organisations” have been through other digital transitions: The last thing they need is another layer of complexity on top of what they already had, but the idea of wiping the slate clean—acting like a startup—would never be in question.
Instead, we learned to deploy Foundry with the players inside the company, bring them onboard as co-creators, and take them through a process that was fundamentally unlike conventional software projects. Foundry gives you a freer hand to create architectures that release more value from the organisation without sacrificing safety or control.
The value of a legacy
Enterprise-scale organisations have an enormous resource in their deep ranks of workers who aren’t developers or programmers, but have vast practical and professional experience with the operation of the business. Over the years, they build banks of highly valuable proprietary knowledge that isn’t accessible to outsiders, whether competitors, consultants, or start-ups.
I’ve seen plenty of these organisations struggle with outdated technology, feeling the pressure to innovate. What I haven’t seen is one that didn’t know or understand this. It isn’t about lethargy or nostalgia for decades-old systems. Instead, they’re painfully aware that they can’t simply disrupt workflows that—for better or worse—do work, without losing irreplaceable institutional knowledge.
With Foundry, much of the value of the deployment stems from the ability to incorporate context-specific, bounded knowledge far more directly than other solutions.
Operational users, as they are referred to in Palantir, have often already been performing many of the functions they would need Foundry for—integrating, collaborating and governing data—just without the proper tools. Implementing Foundry should port their skills and knowledge over, just as it does the data and applications they use.
Reference Architectures
When I say architectures, I’m not simply referring to the architectures of systems and data. In the context of Foundry, it pays to think of architecture as spanning both the human and the technical sides of the equation. Once in operation, a Foundry deployment is a system that connects not just data and systems, but also users and developers as nodes in the architecture.
Foundry users are not simply end-users, working with a system from the outside, the way they’re usually plotted in architecture diagrams. Foundry is designed so that the ontology isn’t a brittle artefact that must be shielded from users. And equally, Foundry accessible enough that they don’t need to be shielded from making technical decisions, either.
In my experience, the most successful implementations are the ones that think of people and data together. Depending on the vision and ambition behind the choice of Foundry, and where the organisation adopting it is in their digital journey, there are different routes you can take to get there.
I’d like to use this series to share the four main patterns I’ve seen and helped implement, and discuss why you’d favour one or the other. With Foundry, it’s never a case of one-size fits all, but we can still talk about basic scenarios and how to approach them.
Structured autonomy
Subject-matter experts lead the process, nurturing and deploying Foundry from within their own departments. They receive training and guidance from a support team, but they work autonomously within the bounds Foundry set.
Right for: Organisations that are comfortable with decentralisation, or seeking wholesale digital transformation, and an ideal fit for ones that embrace proactive initiatives and entrepreneurialism.
Task force deployment
A core team of developers and key subject-matter experts own the process from analysing the problem, integrating the relevant data to building the solution which is then rolled out to the rest of the organisation.
Right for: Organisations with a specific, well-defined problem in mind; also ideal way of piloting Foundry before deploying companywide.
Coming soon
Ecosystem
This process is led by partnering teams in separate organisations, working together to create a common ontology without compromising on data lineages or security
Right for: Integrated supply chains, distribution changes, inter-agency cooperation.
Coming soon
From scratch
Finally, we’ll talk about deployment from scratch: How best to implement Foundry when you do have a blank slate, and what the ideal pattern is for using it as the foundation for a new data and user structure.
Coming soon
Martin Seebach is an independent data architect and consultant with a long history working for Palantir. Details on his practice and how to get in touch at seebach.tech.
Co-author Erik Winther Paisley is a researcher and anthropologist of technology. Details on his research offering at ewpaisley.com.
Foundry® is a trademark of Palantir Technologies Inc.