“Customer-Centric”, “Responsible AI” - Are they just slogans? | EA Series #3

EA lectures last week jumped into a new chapter: Enterprise Architecture Principles

You may have been in an office with a poster in the office: “Cloud as an enabler”, “Customer-Centric”, “Responsible AI”, etc.

Some of these slogans could be Enterprise Architecture Principles.

EA Principles a Slogan?

EA principles are general rules and guidelines that inform and support how an organization fulfills its mission.

EA Principles are backed by the rationale for their existence and the implications of operational requirements. Each EA Principle also includes a clear description that the organization communicates succinctly and unambiguously.

An organization is better off with around 5-8 principles. Too much focus simply means no focus.

Instead of simply repeating TOGAF guidelines on what an EAP should include, I apply them to a sample North American SaaS company.

This sample SaaS company

• Has been operating for 10 years.
• Maintains its platform on-premises.
• Is serving around 200 corporate clients and their clients,
• Relies on a dedicated production server. The server hardware (such as memory and storage) was upgraded as long as it could meet demand, such as increased corporate client intake or client feedback about slow response times.

This year, the server has reached its limit for any further upgrades.

• The server crashes almost every week during peak hours, such as every Monday.
• Restarting the server is the only way to keep it running. The technical team is under pressure.
• The company has another SaaS product coming up next year. And believe the existing way of provisioning is just another nightmare

The company now realizes that adding more hardware is no longer a sustainable solution. It needs a long-term architectural direction that supports business growth, handles changing workloads, and improves service resilience.

This is where an Enterprise Architecture Principle comes into play.

Let's use this SaaS company as an example to explore how such a principle can be defined and applied.

(Practical Example) EA Principle: Cloud-Enabled Elasticity

Component #1 - Name

Cloud-Enabled Elasticity

Component #2 - Statement

All new system developments and core platform upgrades must consider cloud architecture for elasticity and scalability, while integrating with existing on-premises infrastructure.

Component #3 - Description

This principle focuses on extending fixed on-premises capacities into a flexible, hybrid, and elastic environment.

In the initial design phase of any system, architects and development teams have to prioritize the following

• Elastic Capacity: Architects and developers have to prioritize burstable instances.
• Application Portability: Applications should be designed to operate across different infrastructure environments, including on-premises and cloud platforms, allowing horizontal scaling.
• Modular Design: Systems should use loosely coupled modules that can scale independently.

Component #4 - Rationale

• Ensuring Business Continuity: Addresses the weekly server crashes caused by limited on-premises scalability. This supports customer satisfaction and brand image.
• Supporting Growth: The SaaS platform’s expanding customer base and varied client service schedules create unpredictable workloads. Cloud architecture provides the flexibility to dynamically allocate resources.
• Cost Efficiency: Shifts IT costs from CapEx to OpEx. You only pay for consumed resources (Burstable), aligning expenses with actual revenue.

Component #5 - Implications

• Hybrid Skillsets: Teams must maintain existing infrastructure knowledge while mastering hybrid connectivity (e.g., VPNs), cloud-managed services, and Infrastructure as Code (IaC).
• Refactoring for Customizations: Monolithic code for customized features must be progressively decoupled and converted into a modular architecture, allowing specific modules to scale independently in the cloud.
• Dual-Model Financials: IT budgeting evolves to balance fixed annual capital expenditures (CapEx) for local servers with variable monthly operational expenses (OpEx) for scalable cloud workloads. The company must establish a FinOps framework to monitor, manage, and optimize cloud spending to prevent budget overruns.

How would this principle translate into an actual architecture?

The above are my personal notes for my EA course at UofT SCS, to reinforce my understanding. And I am delighted to share them here. Hope you find it useful.

During this period, I am also pursuing the AWS Solutions Architect certification. I have finished 95% of the AWS course this week. So I will extend this case in the next article to share how the on-premises infrastructure and cloud services (taking AWS as the example) can work hand-in-hand to support this EA Principle - Cloud-Enabled Elasticity.