The principles of Create, Store, Transform and Present; and why it's a good idea to separate your product from the third party software you built it on. Typically for people whose main job is building websites, we think about creating web pages. In the BBC, we're beginning to stop thinking in that way, we talk about stories, or guides, or topics, or articles (or any number of things like events or people or places); we talk about the thing that's represented on the web page rather than the page itself. It's a smart move. We spent ten years thinking web pages, and ended up with thousands (millions maybe) of HTML pages that are largely useless today. They are static, outdated, locked up in old branding or in a narrative flow that's no longer relevant. Now, we've expanded our view and are building systems that allow us to create content that's about Things (real world objects or ubiquitous concepts). We don't think about web pages because our content has to appear on four screens (today, who knows how many tomorrow), and it has to be able to be reused in myriad ways. So what does that mean? Well, our presentation systems (web page renderers and smartphone apps) are distinct from our content storage systems. Our content is accessible via an api, so if we discover we need to publish out content to a new interface it's simply a matter of building a new presentation layer, no need to rebuild the whole management system. We also separate our authoring environment from our content storage. This allows other systems to use our store, and gives us the same ability to support new authoring environments as we have to support new presentation systems (want an iPad authoring tool? Easy, just write an app that pushes content to this restful endpoint in a format we define for you). It's a modular approach, which feels like a sensible approach in this fast-moving, rapidly iterating, highly competitive world where Agile development is the order of the day. Why would anyone create a monolithic system any more? A loosely coupled kit of parts, consisting of the best component for each role regardless of source, bolted together with web based glue. I'm going to take off the shelf products and combine them with my own application in interesting and unique ways. I need to make sure that I'm writing my application in such a way that I can switch any bit out for a better version easily. I'm going to be very careful about defining my content format so that I can safely make changes. I need to be able to upgrade my web application framework without rewriting my website. I need to be able to switch my web server from apache to nginx easily. I need to be able to change my xml store without recreating my content schemas. Writing an application that runs on Zend without relying on it means you should be able to switch to Cakephp (for example) without a wholesale rewrite. You'll lose some efficiency by having to eschew framework features, but your application will be more future proof as a result.