SaaS Application Architectural Principles
The following are what we believe are important architectural principles for a successful SaaS application in today’s cloud infrastructures. We try to name them with a catchy phrase so they’ll actually be remembered. (Like: “This follows the principle of Exactly One!” or the troubling “This violates the principle of the Safe Coal Mine Policy…”)
If you would like help implementing these policies, contact us. We’d love to help!
Our hope is to make this a living document that matures with the microservice industry and is of service to the community. If you are passionate about SaaS application design, Microservices or Cloud Computing, come join the Latticework team! There’s always a way to contribute.
IT Policies are enforced and monitored for compliance.
Every SaaS project shall be aligned with business goals and strategy.
The SaaS organization logically operates as an autonomous organization separate from corporate infrastructure and corporate development operations.
SaaS resources, services, and systems shall provide access to and from international markets.
Product Lifecycle Management
Product Lifecycle Planning
The vendor and organizational lifecycles for all resources in the SaaS environment are tracked and planned.
The Money Meter
SaaS development, administration, and operations are managed so that earnings & costs are materialized across Service Center, Data Center, Line-of-Business, Customer, and Customer Organization dimensions.
Decisions will be based on long term strategy — even at the expense of short term profitability.
Three’s a Crowd
Technical diversity shall be controlled in order to reduce complexity.
Open standards shall be preferred wherever possible.
Speak the Same Language
Data definitions and vocabularies will be meaningful to the business domain and consistent throughout the organization.
System of Record
There is but one system of record for any data element.
Data resources and processes shall be managed in three classes: Agile Data, Transactional Data, and Analytic Data.
Structured Data Processes
Clearly defined, consistently used, documented processes shall be enforced to migrate data between data stores using industry standard tools.
Non-Production Data-Scrubbing Pipeline will be maintained for all application deployable data.
Analytical, agile, and transactional data will be continually purged and measured for optimal performance.
Don’t Repeat Yourself (DRY)
Where possible applications will re-use existing components
A meaningful and measured percent of SaaS development effort is spent on refactoring. The amount spent on refactoring differs per Code Quality Class.
Applications, Services, and Libraries shall have design, reference, and usage documentation.
Services will hide their underlying implementation details.
If it isn’t tested, it doesn’t work
A meaningful and measured percent of SaaS code is maintained with unit and integration tests. The amount of unit tested code differs per Code Quality Class. Unit and integration tests are automatically run CI processes and provide build success criteria.
Enabling the Agile Team
SaaS processes, resources, services, data, and software are structured to enable the Agile Team to create value to maximize customer satisfaction and business opportunity acquisition.
Agile by Design
Applications shall be designed to maximize the ability to refactor and extend functionality.
Agile in Practice
Software development tools and processes shall be preferred that encourage Agile development practices.
Four Dimensional SaaS
The SaaS operational and application software is aware of and can automatically configure, manage, and migrate all resources, services and applications within Service Centers and Primary Data Centers and across Customers, and Customer Organizations.
Scalable by Design
The SaaS systems shall be able to scale without needing to be re-architected.
Throughout the SaaS environment, all software services follow the reactive programming model, servicing client requests as events. All application software respond to events using the reactive programming model.
Service Process Statelessness
Services should avoid saving state where possible.
The SaaS software exposes meaningful business metrics to permit Business Activity Monitoring of KPIs and Business Analytics of other factors.
The SaaS systems and software expose meaningful system and application health metrics. SaaS management software provides automated processes to maintain system health and clearly exposes system health information.
The SaaS operational and customer administration tools and interfaces permit management of SaaS properties as a single system. Operational and business analytics supports a single, rolled up view of the system from analyst’s perspective.
No Single Point of Failure
SaaS system resources and services shall be designed to avoid single points of failure whenever possible.
Safe Coal Mine Policy
Canary CI Builds and Canary Production and Non-Production Environments are continuously tested to ensure software stability.
The SaaS production system employs automated Business Continuity processes that are tested in production continually. Tests are automated using simulated outages.
Version Control System
All SaaS software shall be sourced from a version control system (VCS).
They Come in Twos
When applicable, any dependence of the SaaS system on non-open standard resources, services and applications is offset by also executing a competing offering to some extent in production behind a common Anticorruption Layer.
External System Services
Application and Domain software receive Infrastructure and System services through explicit external interfaces.
Minimum Quality Standards
A minimum standard of quality will be maintained despite time to market concerns.
Keep it Simple Stupid (KISS)
When deciding between technologies or approaches that both adequately support specified requirements, the simpler technology shall be chosen unless the simpler technology is no longer maintained and/or supported.
External Security Responsibilities
The SaaS organization shall fulfill security responsibilities to customers, partners and regulators.
Security accountabilities and responsibilities shall be made explicitly clear.
Security policies will be applied consistently across the SaaS organization.
Secure by Design
Security is embedded into business, application, data and technology architecture.
Security supports business goals and should be as transparent as possible.
Security controls will be balanced and proportional to risk.
Security is not a one-time activity — it must be periodically reassessed.
SaaS applications have threat assessments that determine the credibility and seriousness of a potential threat.
Like Oil and Water
The builder and operator of an application will be independent roles.
Unique identities of users shall be protected and preserved.
User identity is verified at application perimeter.
SaaS systems shall verify user access to interfaces, actions and data at approved layers.
Meticulous Security Accounting
SaaS systems shall implement security auditing for access to interfaces, execution of Actions and access to Data.
Information Access Control
Data access is controlled through established processes and authorities.
Secure Data in Use
The smallest footprint practicable shall be employed when using secrets such as encryption keys and passwords. No secrets shall be cached.
Secure Data in Motion
All data in motion is encrypted.
Secure Data at Rest
All secrets, Personally Identifiable Information (PII) data and sensitive Business Identifiable Information (BII) data are encrypted at rest using industry standard methods.
Data Loss Prevention
Data is critical to the success of the SaaS organization. It must be accurate, protected, and recoverable.
Ease of Use
User interfaces will be as simple and intuitive as possible.
Applications shall be designed to maximize the devices from which they can be used.
Services shall be self-describing.
Applications will handle errors in a controlled fashion and continue to operate normally (graceful degradation).
All data and transactional interchange is supported through automated processes.
The Quality Lifecycle
Quality is much more than functional testing. A Quality Assurance Lifecycle shall be employed throughout the software development lifecycle, from Requirements and Design through Documentation and Implementation.
Testable by Design
Software shall provide adequate support for Unit, Integration, Functional, Usability, Performance, Stress, Regression, and Deployment Testing.