Enterprise-Agnostic Architecture¶
Introduction¶
Most engineering automation begins with a specific problem inside a single organization.
Examples include:
- Automating GitHub repositories
- Deploying Kubernetes applications
- Managing cloud infrastructure
- Generating security reports
Initially, these automations solve real operational problems.
Over time, however, another challenge appears.
The automation becomes tightly coupled to one enterprise.
Examples include:
- Hardcoded URLs
- Hardcoded organizations
- Hardcoded authentication
- Hardcoded environments
- Hardcoded repositories
The automation becomes difficult to reuse.
An Engineering Runtime should follow a different approach.
It should be enterprise agnostic.
What Does Enterprise Agnostic Mean?¶
Enterprise agnostic means the runtime makes no assumptions about the organization using it.
The runtime should not know:
- Company name
- Cloud provider configuration
- Internal URLs
- GitHub organization
- Artifact repository
- Security tools
Instead, these become configuration.
The runtime provides capabilities.
The enterprise provides configuration.
The Problem¶
Many internal automation tools evolve like this.
Automation
↓
Company
↓
Hardcoded Configuration
Examples include:
https://github.company.com
https://artifactory.company.com
production-environment
engineering-team
Initially this seems convenient.
Later it becomes technical debt.
Configuration Over Customization¶
Instead of embedding enterprise information into code, the runtime should load it from configuration.
For example:
github:
host: https://github.company.com
capability registry:
provider: artifactory
url: https://artifactory.company.com/
authentication:
provider: adc
The runtime remains unchanged.
Only configuration changes.
Runtime vs Enterprise¶
The runtime owns engineering capabilities.
Examples include:
- Authentication
- Context
- Policy
- Execution
- Audit
The enterprise owns:
- URLs
- Organizations
- Projects
- Credentials
- Providers
Keeping these responsibilities separate improves portability.
Authentication¶
The runtime should never implement enterprise authentication.
Instead it should reuse existing authentication systems.
Examples:
- Google ADC
- GitHub Tokens
- OpenShift Login
- OIDC
Authentication remains enterprise-specific.
The runtime simply integrates with it.
Package Distribution¶
Different organizations distribute software differently.
Some use:
- GitHub Releases
- Artifactory
- Nexus
- Object Storage
- Internal repositories
The runtime should not care where packages are stored.
It should simply download them from the configured provider.
Context¶
Different enterprises organize infrastructure differently.
Examples include:
Cloud
Projects
Subscriptions
Accounts
Containers
Clusters
Namespaces
Version Control
Organizations
Repositories
The runtime should use the context model already provided by the platform.
Why This Matters¶
An enterprise-agnostic runtime can operate in:
- Banks
- Government
- Healthcare
- Startups
- Technology companies
The runtime remains the same.
Only configuration changes.
Benefits¶
Enterprise-agnostic architecture provides:
- Portability
- Easier adoption
- Lower maintenance
- Simpler upgrades
- Better extensibility
- Reusable engineering capabilities
Design Principle¶
Configuration belongs to the enterprise. Capabilities belong to the runtime.
The runtime should never contain enterprise-specific assumptions.
Future Growth¶
An enterprise-agnostic architecture also enables future integrations.
Today:
- GitHub
- Google Cloud
- OpenShift
Tomorrow:
- Azure
- AWS
- GitLab
- Bitbucket
- New AI providers
The runtime evolves through new providers rather than enterprise-specific implementations.
Looking Ahead¶
As AI continues to evolve, another architectural question emerges.
Should an Engineering Runtime depend on a specific AI model?
Or should it work with any intelligent system?
The next article explores AI-Independent Engineering Systems.
Conclusion¶
The most successful engineering platforms separate reusable capabilities from enterprise-specific configuration.
This allows organizations to adopt the same runtime while integrating it with their own infrastructure, authentication systems and operational practices.
Enterprise-agnostic architecture is not simply about portability.
It is about building engineering platforms that outlive individual organizations, technologies and implementations.
Design Principle¶
Configure the enterprise. Don't customize the runtime.
Design Principle¶
Configuration over Customization
Enterprise behavior should be expressed through configuration rather than hardcoded implementation.
Next Article¶
AI-Independent Engineering Systems