Wednesday, January 10, 2007

Aspects of a Platform Architecture: Part 1

How does one create a “reasonable” platform architecture? By which I mean, how does one put a system in place that allows a small number of (~ 10) related products to evolve and ship independently while building upon an infrastructure substrate to allow for common policies, consistent data access, and presentation.

First to be clear on the high level goals what is a Enterprise platform architecture
Multiple products
  • different developers, different use cases (users may overlap), same general business area
Multi-year timelines
  • changing developers, resourcing budgets, technologies, even the rate of change will all change.
Enterprise level
  • Multiple applications serving a particular group of areas within a business, which are different from issues involved in building an industry platform, Windows, Spring, Linux etc.
Common views upon the data
  • When the expectation around the data is the same, the result used/displayed should be the same, no matter how complex the processing is to derive it.
  • Ability to deviate when the expectation is unique or novel. Achieving the responsiveness required for iterative/agile techniques requires the ability to “special case” data access and processing methods. This allows these special cases to be well grounded before they are moved into the substrate (as appropriate).
Products should be normally able to ship independently
Products should be able to communicate between each other so that users can switch between applications (web based in this case) when desired with some minimal context being maintained.

Building this requires creation of a system consisting of a
Data Architecture
  • How do you identify what you’re looking for, where do you find it?
Application Roadmap
  • What application should own the functionality, and when will it be deployed?
Technology Architecture
  • What are the technologies that we’ve settled upon, how are we exploring new ones, how do we decide what to explore/who does it.
Functional Architecture
  • How are we structuring the functionality and identifying common components, how much of the implementation can we hide, what are the hiding requirements (timeliness etc.)

The first step, a Data Architecture foundation.
Select a small set of entities and assure that they have stable, anonymous identifiers. This is surprisingly difficult when building systems out of existing products in scientific domains.

I have been involved in frequent discussions with users who wish to embed domain information in the identifiers so that they can easily identify what they are holding in their hands without needing to go to a computer to find out what it is, or worst case wait for an application to be developed that will let them go to a computer to find out what it is -- a.k.a. every user’s worst nightmare. The best solution I’ve come up with is to print both when necessary.

This selection is also constrained by existing/off the shelf systems and what they can support. Selecting internal identifies from the core of these systems and building synonym tables is a reasonable compromise.

The issues of the remaining Data Architecture plus the other aspects of and Application Roadmap, Technology Architecture and Functional Architecture are important. However, given our multi product, multi-year, frequent revision goals, the issues are as much about building an infrastructure that supports a culture as much as building an architecture. Such a culture involves setting minimal contracts and some processes around their evolution more than instantiating any particular set. The core expectation is that the platform will outlive any applications and it is at the platform level that practices around technology adoption, quality practices, and user interaction should be set. Note: this is not meant to imply that the practices should be uniform across the applications, but the patterns of use categories vs development strategy should be set at the platform level.

No comments: