General:Business:Concepts:Principle:Deliver SCALED, VALUABLE and SMART Services


  • [PRINC-xxxx]: Build Scalable Services
    • Category: Development
    • Statement: Deliver Stateless, Cached, Asynchronous, Location agnostic, Elastically scalable, Distrubutable, Validating, 8A compliant, Loosely coupled, Undoable, API, Backup and Disaster Recovery capable, Logging, Error handling, SOLID/DDD, Multi-tenanted, Accessible, Rule Engine based, Telemetry collecting Solutions.


Deliver SCALED, VALUABLE and SMART Services


package Qualities {

package System {
package "ISO 25010" {

class "Performance Efficiency" as PE {
Time behavior
- -Response time
- -Recovery time
- -Start-up time
- -Shutdown time
Resource Utilization
Capacity (Throughput)

class Compatibility {

class Usability {
Appropriateness recognizability
User Error Protection
User Interface Aesthetics

class Reliability {
Fault Tolerance

class Security {
- -Privacy

class Maintainability {
- -Stability
- -Configurability
- -Installability
- -Scalability
- -Localizability

class Portability {


package Sector {
package Organisation {
class "Ensure 8A Access" as P2
class "Deliver SCALED, VALUABLE\nand SMART Services" as P1

P1 -- P2 : related

System <-- p1



Categories : * Development

Statement : Deliver Stateless, Cached, Asynchronous, Location agnostic, Elastically scalable, Distrubutable, Validating, 8A compliant, Loosely coupled, Undoable, API, Backup and Disaster Recovery capable, Logging, Error handling, SOLID/DDD, Multi-Tenant, Accessible, Rule Engine based, Telemetry collecting Solutions.

Comment : s

  • Stateless:
    • For Availability objectives (see CSA), follow Stateless development patterns which are a prerequisite for elastically scalable load balanced hosting.
  • Cached: for Performance objectives, implement from the very beginning both Host based (ie: local in-memory) caching and System (ie: an infrastructure caching service shared between tier devices). Caching is a key pattern used to reduce the number of performance-impacting cross-device calls.
    • Cache immutable data locally, in-mem, in the layer and format closest to use.
    • Cache mutable data on device shared services, in the format closest to use.
  • Asynchronous: for Availability (see CSA), Performance and Infrastructure Cost objectives, develop using Asynchronous method invocation patterns. Asynchronous invocation reduces thread blocking and in doing so provides both a more responsive application that requires less physical devices to operate on.
  • Location Agnostic: for Portability, Compliance, Legal and Infrastructure Cost objectives, use UTC DateTime and resource localization packs allowing for lower cost hosting options and the ability to reach more users.
  • Elastically scalable: for Availability (see CSA) and infratructure cost objectives, design and deploy the service to infrastructure that can be brought online as needed to handle both scheduled and unscheduled load increases, and subsequently removed when no longer needed.
  • Distributable: for infrastructure cost objectives, develop solutions with application layer defined (not database defined) sequential globally unique ids (Guids) in order to allow distributed deployment closest to end users (whether cloud servers or user mobile applications), improving responsiveness and usability.
  • Validating: for Maintainability objectives, validate all data submitted to the Application Facade's APIs. Note that the APIs are the only way data can be submitted into the solution. ETL's and or direct acces to the Solution's datastore tables and views are expressly forbidden due to their long term impact and cost.
  • 8A: for Security, Auditability (see CSA), Usability, Architecture, and Cost objectives provide 8A accessibility to the Solution's APIs.
  • Loosely Coupled: for Maintainability objectives, design the system to be “Loosely coupled, Highly Cohesive” (LCHC) 1).
  • Undoability: for Usability, Maintainability, Legal, Architectural, and Support objectives, from the start design the system to not Delete records, but change their State (eg: Created, ToBeApproved, Completed, Merged, Archived, Garbage, Deleted). The change from CRUD to CRUS allows for a much richer and smoother user experience. The pattern removes the need for Modal Dialogs asking if users are sure before proceeding, requiers a much less complex and error-prone undo/merge/unmerge architecture, allows users to undo mistakes, and solves archiving elegantly, without requiring a secondary data store. The impact on writing query statements that take into account State is minor (can actually be done transparently using AOP) compared to the benefits.
  • API: for Architectural, Interoperability, Maintainability, and ROI reasons the Solution should be developed as distinct Service and Client deliverables. Specifically, avoid the use of Server side Client User Interface generation (eg: ASP.NET, ASP.MVC, PHP, etc.), preferring Progressive Web App (PWA) Single Page App (SPA) interfaces. The separation ensures the development of APIs that are usable as well as enforcing authorisation and validation.
  • Backup and DR strategies: for Supportability and Business Continuity reasons, ensure that solution is designed to be deployed to an environment that is managed and provides a back up strategy that is implemented regularly (at most daily).
  • Logging: for Supportability reasons, and being able to host as a PaaS, develop diagnostic tracing to remotely queryable datastores (eg: Blob storage in Azure). Logging to trace files is specifically to be avoided as the pattern requires a most costly IaaS based deployment strategy.
  • Error Handling: for Security and Maintainability objectives, ensure that potentially sensitive error stack traces and error messages are not displayed on screen. Trap and Handle at the API boundary any unhandled error, giving it a unique id, log the error and stack trace to the diagnostic logs, record the raw error and stack trace to the database, replace the error with a stackless sanitised error that refers to the Error ID, and display the sanitised error message to the end user.
  • SOLID/DDD: for Maintainability and Modularity objectives, develop code using Robert C. Martin's SOLID development principles. This implies the use of a Dependency Injection Service. An AOP based approach to handling Authentication, Authorisation, Auditing, Tracing, Telemetry and Diagnostics at the API boundary is highly recommended. For Maintainability reasons the solution's components should be designed according to Domain Driven Design (DDD) component principles – which focus on Loose Coupling and High Cohesion (LCHC).
  • Multi-Tenancy: For Supportability, Trainability, Testability, Reusability, infrastructure and Cost objectives, ensure that services can be used by more than one organisation at a time without impact on each other. Multi-tenancy allows safe side by site testing, training, emulation, diagnosis and support on the same system used by end users.
  • Accessible: If you are not taking into account users who are hard of hearing, and or visually impaired, one cannot claim to be implementing a User Centered Design (UCD) approach.
  • Rule Engine: for Maintainability, Supportability, Evolvability objectives the use of a post-deployment editable Rule engine cannot be over-emphasised as to its value to end business users.
  • Telemetry: For Support and maintainability reasons, metrics need to be collected as to infrastructure, application, data performance and usage. These data can then be used to direct subsequent effort.
I'm still missing a way to incorporate the following important design principles.
  • User Centered Design: For Usability, Accessibility, Supportability objectives, design the system using User Centered Design2) to ensure the system conforms to users rather than require users to conform to the system. This implies:
    • Usable (eg: 'Hackable') Resource navigation
    • Simple language, improving understandability
    • Single Action Views, promoting efficiency and responsiveness
    • Undoability (see above)
  • Idempotent: for Maintainability and Supportability objectives, submitting the same transaction should not cause duplication of the operation leading to errors.
  • Modular: for Maintainability objectives, design and develop the system as modularly as possible Apply DDD principles while designing, apply SOLID principles when developing. Plan for libraries needing replacement right from the start: a decade is a long time.
  • Tenant based RBAC security.
  • Keep Communication confidential (HTTPS).
  • Do not store security data (ie, do not store passwords. Use an external IdP Service).