I'm working on a short paper / presentation that describes my position on what an application platform is, the services it provides, and what it does for the application developer. This is this initial outline. This doesn't talk about a specific (LOB) application platform, but instead talks about a set of requirements that a platform should meet. One of the things that started me down this path was noticing partners using the Microsoft CRM application as a platform.  I'm curious to understand how other people think about this "problem" and whether there's any benefit in pursuing the definition.

I want to set the stage by talking about what I mean by "application" first. This paper will look at large-scale line of business applications. This isn't to say that productivity applications such as Office aren't applications, it's just that they're not the class of application that necessarily has this set of requirements.

Diversion

1. Line of business applications
• Tools for automating the business process
2. Productivity applications
• Tools for executing business tasks

 

 Caveat

• A platform isn’t useful without an application
• It’s not possible to determine requirements without an application
• Most people aren’t interested in buying a platform – they want an application
• An application is the start, customers and partners want a solution

Then I'll talk about the necessary and sufficient requirements for a platform. I'm trying to keep this list as short as possible because most application logic tends to leak "down" into a platform thereby making the platform less applicable to other applications.

Platform services

1. Identity and roles
2. Rich type library
3. Security
4. Storage and persistence
5. Extensibility
6. Process identification and execution
7. Solution packaging and containment
8. Deployment models

 

Identity and roles

1. What is a “user” of the system?
2. Collaboration scenarios drive SaaS
3. Roles come in many flavors
• Work roles (position), security roles, reporting structures
4. Roles are facets of an identity
5. Relationships between roles are primary

 

Rich type library

1. Meta-types
• Constituents
• party, role, relationship, contactMethod
• Collaborations
• collaboration, interaction, goal, participation, structuredDocument
• Unstructured collateral
• simpleDocument, annotation
• Opaque data
• Reference data, lookup tables, auditing, etc.
2. Data types
• enumerations, elemental types, higher-level types

 

Security

1. Authorization and authentication
2. Security roles are privilege collections
3. Privileges provide access
• User interface, data, process, tasks
4. Security roles trump work roles

Storage and persistence

5. Storage structure is schema independent
• From an application perspective
6. Storage is disconnected from logic
• From an application perspective
7. The platform controls persistence
• Types DO NOT know how to persist themselves

 

Extensibility

1. Schema
• Types and storage
2. Presentation
• Navigation
• Data capture
• Clients and user interface
3. Process
• Business rules (simple and compound validation)
• Business logic (“big” and “little” process definition)
• Process execution structures (message definitions)

 

Process identification and execution

1. Message definition and execution
2. Actor identification by identity and role
3. Task and work lists
4. Loosely bound to an extreme
5. Declarative vs. imperative
6. Long-running business processes
7. Transactional business logic
8. One entry point to execute processes

 

Solution packaging and containment

1. Everything is an extension
• Schema, process, presentation
2. All extensions are named and grouped
• Names are like CLR strong names
3. Packages are like applications or modules

 

Deployment models

1. Multi-tenancy is important
2. Multi-language per tenant
3. Presentation is independent of the platform
• But the platform can provide presentation tools