At the Enterprise Identity Forum last week, panelists initiated a conversation on whether we should look again at “Build Vs Buy”. This came up as a part of the broader conversation about the proliferation of AI enabled propositions that are flooding the market even while persistent older issues within enterprise environments have not been resolved yet.
Entry barriers to building products are low today. AI Coding agents and spec based development are changing the economics of software engineering. Start-ups with an early inside track to VC’s are finding themselves in ecosystems that can get products quicker to design clients through their network of CISO’s. Innovation and Venture funding arms of leading enterprises are investing and/or incubating Cyber start-ups. Despite all these developments, most products are just probably a shell of inert workflows and a control plane that sits in a SOC2/ISO27001 compliant Hyperscaler.
Whether Products will fail or succeed will depend on the representative environment it is actually built on, versus, the quirks that it will encounter with the exotic and deviant variances in client data and use cases. Their failure or success will depend upon the efficiencies (and security) their product will deliver given the trouble the client will go through to tailor the product to the enterprise fit.
This brings me to a provocative question. If the software vendor is bringing code, automated workflows (a version of which probably already exists within the client environment), a vector or graph db, a connector and an LLM in the box, should we still be calling it “The next gen IDM solution for the Agentic Enterprise”?
It also begs the broader question. What is real differentiation if smart engineeering is a given? Product vendors have “democratised” (to use a polite word) workflows and edge cases across other clients. Are enterprises paying for this democratised knowledge more than anything else? What if this playing field is not as uneven as one thinks?
In my view, IAM teams cannot afford to sit out of the “build” conversation. There are two choices (a) either enterprises are building with the vendor on the same table, or (b) they are on the menu waiting to be gouged with consumption costs that design customers have smartly avoided. “If you are not at the table, you are on the menu.”
A probable laggard here could be continuous assurance (or rather, the lack of it) for such co-built solutions. As for the other compliance tick boxes, well, we are going through a SOC 2/ISO 27001 process right now, and i can say with confidence that it is the barest minimum. A FTSE 100 company that fails a SOC 2 audit has a lot of other things to worry about, other than the audit itself.
With such co-built IAM products we are heading towards other conversations that have longer term implications. Stack sovereignity is one such topic. Does the product use the enterprise validated/hardened LLM or other dependant infrastructure? How is consumption tracked? How will rate limits work for a product that is still learning in the first few months? In a few cases, enterprises may conclude that it is more efficient for them to run the whole stack, open weight models et al. The control plane that sits with the “vendor” will be very thin, with such clients.
Despite the glut of vendors, the biggest problems in IAM have been unresolved since the past two decades. Authorisation and control execution has been persistent bugbears. The good news is that these hard problems will be solved in the next 2/3 years. The difference being that this time it will be a collaborative and equal effort between the product vendor and their forward deployed engineering team in conjunction with a hyper engaged IAM team. I don’t have visions of IAM engineers writing code — on the contrary they may not even touch code. They will build the automation, pipelines, the systems and specs to rapid deploy features integrated to enterprise process intelligence and workflows. They will not be held back by the pedagogies of yesterday and the tickbox of compliance.
It was in the 2010’s that Palantir pioneered the forward deployed model. That was driven by client necessity. The world of Identity sits at this inflection point a decade and a half later.