Applying Enterprise Architecture to Everyday Automation

It is easy to view Enterprise Architecture (EA) as a discipline reserved exclusively for massive, complex organizations—large banks, healthcare networks, or Fortune 500 companies. But at its core, EA is about making intentional design decisions, evaluating trade-offs, and designing systems that can remain maintainable and adaptable as circumstances change.

To illustrate this, consider a very common, small-scale business problem: automating payment reminders.

Consider a small Spanish tutoring business where an enterprise architect faced a familiar operational bottleneck. The process of tracking student attendance, reconciling it with payments, and sending “gentle reminder” emails was entirely manual. While the process itself wasn’t broken, it was repetitive and increasingly tedious.

The initial instinct in this scenario would be to write a quick script—a single, tightly coupled file that directly queries a calendar API, reads a spreadsheet, and fires off emails. However, approaching this mundane problem with an architectural mindset yields a significantly more robust solution and highlights several key EA principles.

Designing by Concept, Not Technology

The most critical shift when moving from a “quick script” to an architectural design is abstracting the solution away from specific products. When mapping out the solution, the architecture should not be defined solely in terms of the tools it uses (like Google Sheets or GitHub Actions), but in terms of the architectural concepts those tools implement.

In this tutoring example, the architecture can be described in terms of distinct, technology-agnostic roles:

• State Store: The system of record containing information that changes over time (student balances, payment history). In this implementation, it happens to be a Google Sheet. In a larger enterprise context, it could be a relational database, Salesforce, or SharePoint.
• Event Source: The origin of business events. Here, it is Google Calendar tracking attendance. In a larger system, it might be an ERP or a custom operational application.
• Automation Engine: The central coordinator that holds the business logic. It pulls data from the Event Source and State Store, evaluates the rules, and determines what actions are required. Crucially, this engine does not care where the data comes from, provided the contract is honored.
• Scheduler: The mechanism responsible for triggering the process at the correct time. By isolating this from the business logic, the underlying platform (currently GitHub Actions) can be swapped for AWS Lambda or Azure Functions without affecting the core workflow.
• Notification Service: The execution layer for outbound communication. Whether it uses SMTP, SendGrid, or Amazon SES, the architectural concept remains unchanged.

By structuring the system around these concepts, the architecture is insulated against technological churn. The implementation details can evolve, but the pattern holds.

Idempotency and State Management

A key design decision in any automated workflow is ensuring that it can run repeatedly without unintended side effects—a concept known as idempotency.

In a naive script, a network timeout during the email-sending phase might cause the system to crash. If the script is restarted, it might resend emails to students who have already been notified.

To solve this, the architecture introduces a simple but critical piece of state: a “reminder sent” flag within the State Store. After a reminder is successfully dispatched, the Automation Engine updates this flag. The next time the workflow runs, it evaluates this state and bypasses students who have already been processed. This small piece of state makes the workflow much safer to re-run and helps prevent duplicate reminders when the workflow is retried.

Orchestration vs. Decoupling

Another critical architectural consideration is how the business logic is organized.

For this small-scale project, all coordination is handled within a single automation-engine.ts file. This centralized orchestration makes the code easy to follow and perfectly suits the scale of a solo tutoring business.

However, an enterprise architect must recognize when a pattern needs to change based on context. IIf this capability were being built as part of a larger enterprise system, the architecture might instead introduce more explicit boundaries between attendance tracking, notifications, business rules, and data access. Those capabilities could then be separated into distinct modules or services, depending on the scale and requirements of the system. Capabilities like attendance tracking, notifications, business rules, and data access would be separated into distinct modules with clear boundaries. This would allow independent teams to test, evolve, and reuse these components across different business processes.

Security as a Separate Concern

Finally, robust architecture benefits from keeping security concerns separate from business logic. In this system, credentials and access tokens are not embedded within the automation engine. Instead, they are managed externally via OAuth and injected securely at runtime (using GitHub Secrets). This separation ensures that the application code remains agnostic to the underlying security implementation.

The Objective of Architecture

Looking at this project, the technology stack itself is entirely conventional: Google Workspace APIs, GitHub Actions, and SMTP have all been around for years. The true value lies in applying rigorous architectural thinking to an everyday problem.

Whether you are designing a system for a global financial institution or automating back-office tasks for a tutoring business, a gym, or a law firm, the underlying objective remains exactly the same: spend less time on repetitive, operational activities, and more time on tasks that actually deliver value. Good architecture helps make that possible by giving the system clear boundaries, making change easier to manage, and keeping maintenance from becoming unnecessarily difficult.