Why Standards Matter More Today: From Fear of Lock-In to Foundations for Choice
Looking Back to Look Forward
In the early 2000s, enterprise Java was shaped by caution. Developers and architects alike approached new projects with a defensive mindset. They feared lock-in. They feared being tied to a particular application server or proprietary API that might disappear or fall behind. They feared building something they couldn’t move or scale or modernize later.
Out of this environment, frameworks like Spring emerged. These tools didn’t just add useful features to Java EE. They gave developers a way to bypass the rigid specifications and heavyweight runtimes of the time. Spring offered inversion of control, declarative transactions, and a much lighter programming model. Just as importantly, it gave developers the perception of freedom—freedom to swap components, to delay platform choices, and to move faster.
In that era, standards were often seen as obstacles. They moved slowly, were difficult to use, and sometimes failed to deliver on their promise. Frameworks felt more practical, more in touch with the needs of working developers. So we pushed standards to the side and leaned on community-led innovation.
But time and context have changed dramatically. We now live in a software landscape defined not by a lack of choice, but by an overwhelming surplus. And in this new reality, the role of standards has evolved. They are no longer a constraint. They are the foundation for interoperability and sustainability. They matter more than ever.
The Modern Problem Is Fragmentation, Not Lock-In
Today, almost every developer has instant access to world-class tools, platforms, and libraries. Whether you're building a REST API, training a language model, or streaming telemetry data from Kubernetes clusters, there is no shortage of options.
With that freedom comes fragmentation. Two teams in the same organization might solve the same problem in entirely different ways. One team uses Spring Security with custom filters, another uses Keycloak with standard OIDC flows. One builds a service on AWS Lambda using Python, another chooses Quarkus with Kubernetes. It is not just that people have preferences. It is that those preferences increasingly become dependencies, creating invisible walls between systems.
It is ironic that the more open the software ecosystem becomes, the more we risk creating isolated, incompatible solutions. What once was a fight against rigid, closed platforms has turned into a challenge of coordination. The new vendor lock-in is not the monolithic application server—it is the combination of cloud-specific APIs, proprietary SDKs, and implementation-specific workarounds.
When Portability Fails
A few years ago, I joined a team working on a major digital transformation project for a legacy insurance platform. The goal was to modernize their backend, introduce microservices, and eventually move to the cloud. We chose Spring Boot for its maturity and ecosystem, and we made fast progress. Things worked well—until the compliance team mandated a switch to a different identity provider.
What should have been a small change became a drawn-out ordeal. The application was built on top of a highly customized Spring Security setup, with non-standard flows, token handling, and authorization filters. Integrating the new provider, which followed OpenID Connect more strictly, required us to rewrite entire parts of our security model. We had prioritized convenience over standards, and we paid the price.
This story is not unique. Many developers eventually face the reality that software lives longer than teams or trends. Choosing standards up front is an act of humility—an acknowledgment that others will need to understand, maintain, and evolve what we build.
The New Role of Standards
In the early days of Java EE, standards were associated with formality, committee-driven design, and excessive ceremony. They were often criticized for being too verbose, too abstract, or too inflexible. Frameworks like Spring or Hibernate emerged precisely because they offered a more developer-friendly experience.
But standards today are not what they once were. The open source community has changed how standards are created and adopted. Jakarta EE, MicroProfile, OpenTelemetry, and OpenAPI are not locked behind closed doors. They are defined by the community, informed by real-world experience, and implemented by multiple vendors.
Instead of defining runtime behavior in exhaustive detail, modern standards often focus on contracts and protocols. They describe interfaces, formats, and behaviors that enable systems to interoperate without prescribing how those systems should be built. This lighter, more modular approach fits the needs of today’s cloud-native and distributed architectures.
Where once standards were a burden, they are now a bridge.
Yesterday’s Frameworks, Today’s Foundations
The contrast between the old and new meanings of standards tells a larger story about the evolution of enterprise development.
In the early 2000s, developers gravitated toward frameworks because the official standards were too hard to use. Frameworks provided better APIs, more flexibility, and faster iteration. They enabled teams to get things done.
Today, those same frameworks often embrace the very standards they once sidestepped. For example, Quarkus, Micronaut, and modern versions of Spring all support Jakarta RESTful Web Services. They offer native support for MicroProfile specs like Config, Health, and Metrics. These frameworks still offer productivity, but they now do so on top of standard interfaces.
This shift reflects a deeper truth. Developer productivity and open standards are not in conflict. In fact, frameworks that adopt standards give you the best of both worlds. They let you go fast without locking you in.
The Cloud Changed the Game
Moving to the cloud did not eliminate the risks of lock-in. It simply changed where they show up. Instead of worrying about whether your code is tied to one application server, you now have to ask whether your architecture depends too deeply on one cloud provider's APIs.
This new kind of lock-in is often invisible at first. You might use AWS DynamoDB for your NoSQL needs, AWS CloudWatch for logs, and AWS IAM for identity. Each service is powerful, but each one also introduces a coupling to the provider’s platform, pricing model, and availability zones.
If tomorrow you want to switch to Google Cloud or run your stack on-premises, the amount of code and configuration you need to rewrite might be overwhelming.
Standards provide an answer. You can use Kubernetes to abstract compute resources, OpenTelemetry to standardize observability, and OIDC to decouple authentication from your cloud provider. These standards let you embrace the cloud’s strengths while preserving the freedom to adapt in the future.
Standards as a Social Contract
Beyond code, standards play a crucial role in collaboration. Modern software development is a team sport. Your application is touched by many roles—developers, architects, SREs, QA, security engineers, platform teams, and more.
Each of these people brings different skills and tools. Standards create a common language among them. A security engineer can review an OAuth2 flow because it follows OIDC. An SRE can monitor services using standardized metrics exposed via OpenMetrics. A QA team can generate test stubs automatically from an OpenAPI definition.
When you follow standards, you reduce the cost of communication. You make your software understandable. You make it easier to test, integrate, and secure. And perhaps most importantly, you reduce the number of assumptions someone needs to hold in their head just to work on your system.
Standards are not just about portability across platforms. They are about clarity across people.
Shortcuts Come at a Price
Every developer has felt the pressure to deliver quickly. It is tempting to cut corners and choose the most convenient approach in the moment. Why spend time writing an OpenAPI contract when you could just document the endpoint later? Why bother using the MicroProfile Fault Tolerance API when a custom try-catch block will do the job?
These shortcuts feel harmless at first. But they accumulate. Over time, they create systems that are brittle, inconsistent, and hard to change. They make onboarding new developers harder. They make migrations riskier. They reduce your ability to respond to change.
Using standards requires discipline. But that discipline pays dividends. It forces you to be explicit about interfaces. It pushes you to write code that can be understood by others. And it prepares your system for change, whether that change comes from a new compliance rule, a new cloud strategy, or a new team taking over the codebase.
"In a world of endless choice, standards don’t restrict us — they protect us."
Markus Eisele
The Coming Wave: Standards for AI and LLMs
Just as cloud computing disrupted the architecture of enterprise systems, AI is now reshaping how we build and interact with software. And just like before, this new frontier is already seeing a surge in tools, services, and APIs—all with different assumptions and behaviors.
The good news is that standardization efforts are underway. Projects like Model Context Protocol (MCP) aim to define how agents share context across tasks. ONNX creates a common model format across training and inference environments. APIs from OpenAI, Hugging Face, and LangChain4j are converging around common interfaces for prompt handling and retrieval-augmented generation.
We are once again at the edge of fragmentation. Standards can help us navigate the transition. Developers who adopt them early will avoid the pain of rewriting code when the dust settles.
A Developer’s Checklist for Standards
To bring this home, here are three practical questions you can ask whenever your team is making a technology decision:
Is there a widely adopted standard for this capability?
Will our implementation make it easier or harder to switch tools or platforms later?
Will someone outside our team be able to understand and maintain this solution six months from now?
These questions are not about purity. They are about resilience. They help you choose tools and approaches that last.
Conclusion: Standards Are the Future
In the early days of Java and enterprise development, standards felt slow and heavy. They were easy to dismiss. Frameworks won hearts by moving fast and solving real problems. But as our industry matured, as software lifespans grew longer, and as teams became more distributed, the cost of fragmentation became more obvious.
Today, we do not need standards because we lack alternatives. We need them because we have too many. Standards provide the structure that allows innovation to scale. They make systems portable, maintainable, and secure. They turn isolated efforts into shared progress.
In a world where everything changes quickly, standards offer something rare: a path toward stability that does not sacrifice agility. That is why they matter more now than they ever did before.