App Services Design Criteria

Further to my earlier post on high velocity object models, let us consider goals and decision criteria surrounding implementation of app services.

App Services are typically consumed by end user applications existing on various device platforms: desktop (mac, windows), mobile (iOS, Android, BB, Win7), web (IE, FF, Chrome). However, in the SaaS world a fourth customer has now creeped up - developer API. This is a developer outreach program that many SaaS companies actively support.

Here is a nice set of goals for building out an app services layer:

• Deliver reusable business value at high speed: Easy to implement, code, and test
• Software flexibility: Ability to change faster, easily, and reliably
• Solution extensibility: Ability to do custom additions

We assume that most of the heavy lifting around multitenant scalability, performance and reliability are taken care of by data web services layer. App services software layer itself is fully stateless and hence easily clustered (using VIPs) and load balanced (using a Load Balancer).

Let us study each goal in turn.

Deliver reusable business value at high speed

In a nutshell, this means that we want the R&D team to address complex and ever changing business requirements productively. Features of a solution which aid in supporting this goal:

• Rich object model expressed using a modern OOP language along with an IDE
• Compose reusable objects
• Domain Modeling Framework
• Easily model and communicate solution centric concepts, designs, and implementations
• Continuous Integration
• Automated Deployment
• Automated Code Quality Measurement
• Automated Functional Testing
• Automated Performance Testing
• Automated Security Testing

Software flexibility

We want to help R&D team easily add new functionality to existing app services without breaking applications which depend on them. Features which aid in supporting this goal:

• Isolated & segregated resource objects
• Backward compatible external object interfaces

Solution extensibility

3rd party developers enrich the software layer with custom resource objects, custom behaviors, custom data providers. Features which aid in supporting this goal:

• Interpreted and/ or dynamically compiled languages
• AOP support inside the language
• Multitenant deployments