In the previous chapter, we defined the business requirements for Fetched & Far GmbH. We now understand what the company needs and will now translated the requirements into an enterprise architecture.
Architectural Goals
Every architectural decision should support at least one business requirement.
For Fetched & Far we defined those in https://philipp.guide/company/requirements/ and assigned each requirement an unique identifier
Business Requirements
| ID | Business Requirement | Rationale |
|---|---|---|
| BR-01 | Employees should have a single identity across all internal services. | Reduces administration and improves usability. |
| BR-02 | Employees should be able to securely access company resources from any location. | Supports the company's hybrid working model. |
| BR-03 | Customer and company data must be protected against unauthorized access. | Protects sensitive information and builds customer trust. |
| BR-04 | New employees should be onboarded quickly with minimal manual effort. | Supports rapid growth and reduces operational overhead. |
| BR-05 | The infrastructure should scale without major architectural redesigns. | Enables long-term business growth. |
| BR-06 | Critical services must remain observable and recoverable. | Ensures business continuity. |
| BR-07 | The IT infrastructure should be manageable by a small IT team. | Reduces operational complexity and cost. |
Technical Requirements
| ID | Derived From | Technical Requirement |
|---|---|---|
| TR-01 | BR-01 | Central Identity Provider |
| TR-02 | BR-02 | Secure Remote Access |
| TR-03 | BR-03 | MFA, RBAC and Encryption |
| TR-04 | BR-04 | Identity Lifecycle Management |
| TR-05 | BR-05 | Modular Architecture |
| TR-06 | BR-06 | Monitoring, Logging and Backups |
| TR-07 | BR-07 | Automation and Centralized Management |
Cloud Strategy
Fetched & Far will follow a hybrid infrastructure strategy.
Not every workload belongs in the cloud.
Likewise, not everything needs to be self-hosted.
Instead, every service is evaluated individually based on security, operational complexity and cost.
Business-critical identity services, internal infrastructure and management systems will primarily remain on-premises, while cloud services may be introduced where they provide clear operational or financial advantages.
The objective isn't to avoid the cloud.
The objective is to choose the right platform for each workload.
Identity as the Foundation
Modern enterprise infrastructure begins with identity.
Rather than maintaining separate user accounts across different services, every employee should authenticate using a single identity. This also alligns with BR-01 and TR-01.
Identity becomes the central trust anchor of the entire infrastructure.
This allows us to implement:
- Single Sign-On (SSO)
- Multi-Factor Authentication (MFA)
- Role-Based Access Control (RBAC)
- Centralized user lifecycle management
- Comprehensive auditing
To achieve this, the environment will combine Windows Server Active Directory with a modern identity provider supporting OpenID Connect and SAML.
Traditional Windows environments and modern web applications will therefore share the same identity platform.
Core Components
The infrastructure will consist of several independent but connected building blocks.
Identity
Active Directory, modern SSO and centralized authentication.
Networking
Segmentation, firewalling and secure connectivity between all systems.
Secrets Management
Secure storage and distribution of credentials, certificates and sensitive configuration.
Platform Services
Git, documentation, internal tooling and collaboration services.
Monitoring & Logging
Centralized visibility into infrastructure health, security events and operational metrics.
Backup & Disaster Recovery
Protecting business data and ensuring fast recovery after failures.
Each of these areas will be designed individually throughout this series.
Design Philosophy
Throughout this project, technology is never the starting point.
Business requirements determine the architecture.
Architecture determines the technologies.
This approach prevents unnecessary complexity and ensures that every component exists for a reason.
Whenever a new technology is introduced, I'll answer three questions:
- Which business problem does it solve?
- Why was this solution chosen over the alternatives?
- Which trade-offs does this decision introduce?
If a component cannot answer those questions, it probably doesn't belong in the architecture.
Looking Ahead
With the overall architecture defined, the next logical step is designing the network.
Before deploying identity services, applications or monitoring systems, we first need a secure and scalable network that connects them all.
The next chapter will focus on the company's network architecture, including segmentation, trust boundaries and the reasoning behind each network zone.