MSCC MSCC March Meetup: Enterprise Architecture & 12-Factor PHP Infrastructure

The Mauritius Software Craftsmanship Community held its monthly meetup last Saturday at the Klanik office in IconÉbène. Twenty-two attendees gathered for an afternoon of two talks, a shared lunch, and an open discussion.

Two talks were on the agenda:

1. What is Enterprise Architecture and Why Should Developers Care? — by Ajmal Saifudeen
2. A 12-Factor Roadmap for Modern PHP Infrastructure — by Ish Sookun (myself)

Before the talks, Nirvan Pagooah, Engineering Manager at Klanik, welcomed the group and gave a brief presentation about the company, its activities, and the current open positions.

Enterprise Architecture: Not Just for the Big Players

Ajmal Saifudeen from Enterprise Architects Ltd kicked things off with a presentation that tackled a subject most developers in Mauritius rarely encounter head-on: Enterprise Architecture (EA).

Ajmal opened by framing the Mauritius context. Few organisations on the island have a formal EA practice — or even know what EA is. Most developers never interact with it directly. Yet, as he pointed out, Enterprise Architecture shapes the very environment in which all development happens. Whether you're aware of it or not, EA decisions (or the absence of them) affect every line of code you ship.

Before diving into the enterprise side, Ajmal grounded the audience in what "architecture" means in a general sense. He broke it down into four pillars:

• a blueprint that guides constructors on how and when to build;
• a context — a boundary defined by locality;
• a set of guidelines to follow;
• a set of standards to adhere to.

Simple, but a useful mental model for the discussion that followed.

One of the striking slides was the iceberg analogy for why good architecture matters. Above the waterline sit the external touchpoints — websites, mobile apps, conversational interfaces — the parts users see. Below the surface lurk the problems that plague organisations without solid architecture: lack of agility, complex and disparate systems, organisational silos, poorly managed data, weak resource planning, and ballooning operational costs. The message was clear — what the customer sees is only the tip; the bulk of the challenge lies underneath.

What EA Is (and What It Is Not)

Ajmal offered a concise definition: Enterprise Architecture is the practice of designing how a business operates and how technology supports it, so that technical solutions are purposeful, scalable, and aligned with business goals.

He was equally clear about common misconceptions. EA is not just documentation. It is not a rigid bureaucracy. And importantly, it is not only for large corporates — a point that resonated with an audience largely composed of developers working across a mix of startup, mid-size, and enterprise environments in Mauritius.

Ajmal walked through the EA mandate using a layered pyramid model, spanning from Technology Architecture at the base through Integration, Application, and Information Architecture up to Business Architecture at the apex. Each layer maps to a landscape view — technology, integration, application, data, and business — and the whole stack is driven from the top (business strategy) while being enabled from the bottom (technology capabilities). It was a clear illustration of how EA bridges the gap between what the business wants and what IT delivers.

Sadly, I missed the closing segment of his presentation as I attended a phone call. 😔

A 12-Factor Roadmap for Modern PHP Infrastructure

After Ajmal's talk, I took the floor with a presentation on applying the twelve-factor app methodology to modern PHP infrastructure — specifically Laravel.

Origins and Staying Power

I opened with the backstory. The 12-Factor methodology was created by Adam Wiggins and the Heroku engineering team, published in November 2011 at 12factor.net. It codified the patterns they observed separating apps that scaled reliably from those that repeatedly failed on their platform. What makes it enduring is that Docker (2013) and Kubernetes (2014) both validated its principles, and today serverless, microservices, and CI/CD pipelines all build on the same foundations. Organisations like Netflix, Spotify, Airbnb, Google Cloud, and AWS publicly endorse and implement 12-Factor patterns across their platforms.

The Twelve Factors in Brief

I walked through all twelve factors in two groups. Factors I through VI cover the foundation: a single codebase tracked in version control with many deploys, explicitly declared dependencies via composer.json, configuration stored in environment variables rather than code, backing services (databases, caches, queues) treated as attached resources, strict separation of build/release/run stages, and stateless share-nothing processes.

Factors VII through XII cover runtime and operations: self-contained port binding (Laravel Octane serving on a port), horizontal scaling via the process model, fast startup and graceful shutdown for disposability, keeping dev/staging/production as similar as possible, treating logs as event streams rather than files, and running admin tasks (migrations, seeders) as one-off processes through Artisan.

Laravel × 12-Factor: A Natural Fit

The core of the talk demonstrated how Laravel's architecture aligns with 12-Factor almost by design. The .env file and env() helper give you Factor III (Config) out of the box. composer.json handles Factor II (Dependencies). The driver-based service abstraction in config/database.php, config/cache.php, and config/filesystems.php is Factor IV (Backing Services) in action — you can swap from MySQL to PostgreSQL, from file cache to Redis, or from local disk to S3, all by changing a single environment variable with zero code changes.

For Factors XI and XII, Laravel's Monolog integration routes logs to stderr in production containers, where the platform (Fluentd, Loki, CloudWatch) handles collection. Artisan provides the CLI for migrations, cache clearing, queue management, and custom one-off commands — in Kubernetes, these run as initContainers or Jobs.

Local Dev Parity with Laravel Herd

A significant portion of the talk focused on Factor X (Dev/Prod Parity) through Laravel Herd. Herd is a native PHP development environment for macOS and Windows that provides zero-configuration setup, automatic .test domains with HTTPS, multiple PHP version support (8.1 through 8.5), and built-in services including MySQL, PostgreSQL, Redis, Mailpit, and MinIO for S3-compatible storage. A herd.yml file declares the site configuration declaratively.

I contrasted the local Herd setup against a production Kubernetes deployment side by side: locally you run file cache, sync queues, and local disk; in production it's Redis cache, Redis queues, and S3 storage — but the application code, routes, and business logic remain identical. Only the .env changes.

Lunch and Open Discussion

Post-lunch, we shifted into an open discussion that brought both topics together. Questions ranged from how EA principles can inform infrastructure decisions to how the twelve-factor approach can serve as a lightweight architectural discipline even in organisations without a formal EA function. The cross-pollination between the two talks made for a richer conversation than either topic would have generated in isolation.