Architecture | CMS Blog Watch

architecture

NoSQL Deja Vu

Posted in Development, architecture, nosql on February 23rd, 2010 by seth – Comments Off

Around thirteen years ago, I helped build a prototype for a custom CRM system that ran on an object database (ObjectStore). The idea isn’t quite as crazy as it sounds. The data was extremely hierarchical with parent companies and subsidiaries and divisions and then people assigned to the individual divisions. It was [...]

Related posts:

  1. The CMS Decorator Pattern Web content management systems are very good at capturing,…
  2. "ZOracle" Part II: The Solution In my last post, ZOracle Part I, I described…
  3. CMS Architecture: Managing Content Type Configurations Warning: this post is highly technical. Non-programmers, please avert…

Related posts brought to you by Yet Another Related Posts Plugin.

CMS Architecture: Managing Presentation Templates

Posted in Development, architecture on January 25th, 2010 by seth – Comments Off

Another geeky post…
In my last post, I described the relative merits of managing configuration in a repository vs. in the file system but excluded presentation templates even though how they are managed is just as interesting. Like configuration, presentation templates can be managed in the file system or in the content repository. Like [...]

Related posts:

  1. CMS Architecture: Managing Content Type Configurations Warning: this post is highly technical. Non-programmers, please avert your…
  2. Code moves forward. Content moves backward. One of the primary functions of a web content management…
  3. Finally, Drupal Gets Deployment Greg Dunlap, over at Palantir, has a post introducing a…

Related posts brought to you by Yet Another Related Posts Plugin.

CMS Architecture: Managing Content Type Configurations

Posted in Django, architecture, selection on January 19th, 2010 by seth – Comments Off

Warning: this post is highly technical. Non-programmers, please avert your eyes.
Deane Barker (from Blend Interactive) and I have a running conversation about CMS architectures. One of the recurring topics is how content models and other configuration is managed. There are two high-level approaches: inside the repository and outside the repository. Both [...]

Related posts:

  1. CMS Architecture: Managing Presentation Templates Another geeky post… In my last post, I described the…
  2. Code moves forward. Content moves backward. One of the primary functions of a web content management…
  3. Finally, Drupal Gets Deployment Greg Dunlap, over at Palantir, has a post introducing a…

Related posts brought to you by Yet Another Related Posts Plugin.

When WCM isn’t enough

Posted in WCM, architecture, fatwire, terminalfour on January 14th, 2010 by Philippe Parker – Comments Off

Orange and blue liquid forms in a glass

How many websites these days are purely content-driven?

It’s hard to justify brochureware sites. How many people do business with you just because your website looks pretty? Organisations want websites that either generate an income or reduce pressure on more costly channels, like call centres. That means transactional web applications, not just web content management.

Yet content management is still required. Whether you’re updating marketing material to support your service offering or changing form labelling and layouts to ensure fewer drop-outs on transactions, the web team still needs to be able to make content changes without having to go through a lengthy development release process.

The simplest way to achieve this is to run two web applications separately, one driven by the content management system and the other by the transactional software, like eCommerce. You get your developers to style the two applications to look the same, run from similar URLs and hope that the web app gives you enough control to alter content that it’s responsible for, such as labels on form fields. This way you can keep system integration to a minimum. There are a couple of significant disadvantages, however. Firstly, if your site needs to change globally — a change to brand or navigation, for example — you have to update both systems. Secondly, you need to design your site in such a way that you keep content and transactions separate, which is very unlikely to lead to a successful user experience.

So what are your other options? You could take content managed through the CMS and embed it in the transactional application. This means that when you have a form field to complete which needs some guidance, that guidance can come from the CMS without the user having to abandon their transaction. But this creates problems of its own. You lose some of the key benefits of the CMS: relationships are harder to maintain between pieces of content and preview becomes nearly impossible.

This is why the transactional application is often embedded in the CMS. FatWire, for example, has just launched its Web Experience Management Framework, which should make this process easier, while Terminal Four also touts its integration with external systems. Yet irrespective of the CMS you use, you’re going to face some integration problems. There’s bound to be an element of custom code, issues with assuring decent performance from both the CMS and the transactional application, and above all design difficulties ensuring that the security of the user’s transaction is maintained by the delivery layer.

Another option is portal technology. In theory, portals enable you to deliver all your web applications in an integrated fashion and what’s more, do so incrementally, adding applications without having to change the core configuration. They’re also usually pretty good at managing sessions and user credentials. Portals bring their own problems however, not least cost of delivery, increased time to develop and un-friendly URLs.

So all four approaches have positives and negatives. There’s a niche in that market somewhere for a vendor. Until someone proves they’ve filled that niche however, you’re unlikely to be able to deliver a great business-driven website using just a web content management system.

The future of the web is JavaScript

Posted in JavaScript, architecture, google, strategy on December 11th, 2009 by Philippe Parker – Comments Off

O'Reilly JavaScript textbook

The future of the web is mobile. And by mobile I don’t mean mobile phones. I mean browsing through devices that people carry around with them. All these devices, irrespective of form factor, have a common problem: they are prone to lose connectivity to the internet.

If you’re on the move and keep losing your 3G signal, or just happen to live in an area with a poor reception, or in a house with brick walls which slow wifi, or suffer from terrible contention rates in your Starbucks or conference venue, you’ll know that cable-less connectivity is fallible. So you’re in the middle of a transaction, just trying to get to the next step when… enter tunnel / lose packet / connection error and you have to start over.

There is a solution to this problem however. As Michael Kowalski tells us, the future of the web is JavaScript. Or perhaps not JavaScript in its current form, but client-side scripting nonetheless. Why? Consider the options.

If you want interaction that will run reliably on a device with poor connectivity, you can’t keep expecting the browser to go back to a server. So you might make your functionality available as a downloadable app. But it had better be a killer app the user wants to rely on, because otherwise they won’t want it taking up real estate on their phone. And it’ll have to run across operating systems if you want to reach a broad market, not just Steve Jobs’ latest toy.

You could use a rich internet application such as Flash or Silverlight. But the client platform has to support these and the user has to install them, although they’re more likely to do so for a generic RIA than for a specific tool. The big issue with these applications however is that the content is embedded in the interface, which makes them both heavy to download and difficult to make accessible to other applications, such as screen readers and content aggregators. So you’d probably have to create two versions of the content: one embedded in the RIA, the other standalone. That’s not great.

JavaScript has the advantage that it can be used to enrich content, but not contain the content itself; for example, to provide better interactivity on maps. There are also libraries of JavaScript functions that can be re-used and downloaded to the client device with the user barely noticing. Take jquery: Google hosts a copy, so if you use these functions on your site, you don’t even need to host the file. Reference Google’s copy and you’ll save bandwidth and, if enough websites follow the same path, there’ll probably be a cached copy on the user’s machine even before they get to your site, which will significantly improve response times.

Google is of course moving beyond jquery to complex client-side scripting which its own browser / operating system will be capable of handling, but some other browsers may struggle with. Chrome is a replacement for off-line scripting using Gears. It should not only enable mini applications such as Wave to run faster in a browser, but will enable online transactions to continue to function better when connections are poor. Opera has been developing similar functionality for its browser too.

So if you want to provide audiences with a better experience irrespective of platform and location, a lightweight client-side tool that separates content and function and runs in a browser seems like a future-proof idea. And for the moment at least, that means JavaScript.

Don’t Make Monoliths

Posted in Agency, Ramblings, architecture, planning, procurement on November 11th, 2009 by Jon Marks – Comments Off

Come gather ’round friends
And I’ll tell you a tale
Of when the red iron pits ran plenty.
- NORTH COUNTRY BLUES

Asterix was worried. Once again he’d woken up with his bed surrounded by water. It appeared that the melting polar ice caps were leading to a rise in the sea level, which was threatening to flood the whole of Armorica. The only solution would be to move the entire town further inland, and they’d run out of magic potion. He got up, got dressed, and went to find Overcomplix, the town’s architect. When he found him, Overcomplix looked worried too.

“So, Overcomplix, how are the plans to migrate the village inland progressing?”, inquired Asterix. “To be honest”, replied Overcomplix, “not very well. You see, when we designed this village, we opted for a tightly coupled, fully integrated architecture. The town hall is joined to the market by solid iron girders, and all of the houses are tightly welded to the market. If we could move one building at a time, we’d be okay. But if we try to separate them, the whole village will fall apart. I think Gantchartix is working on a plan, though.”

“That’s no good at all”, sighed Asterix. “I’ll talk to Gantchartix, but it sounds like we’ve built a monolith. Let me find Obelix. He’s helped us out of tight spots before.”

asterix-obelix

When Asterix found Gantchartix, he was surrounded by Microsoft Project Plans and grinning from ear to ear. “I’ve created a masterpiece”, smiled Gantchartix. “The village is saved. All we need to do is get one hundred thousand doves and connect them to the village with pieces of rope. Then, all the doves need to lift off at exactly the same moment, fly inland a bit, and land at exactly the same time. If one of them mistimes it, the village will fall apart. But look at my project plan – it’s perfect.”

Asterix wasn’t convinced. Once again, Gantchartix was living inside his plan instead of reality. “That sounds like a Big Bang approach to me, Gantchartix. Those never work. Your plan is a monolith. I really need to speak to Obelix. He has experience with these things.”

All this worrying had made Asterix hungry. He decided to visit Procurafix to grab a bite to eat.

“Sorry, Asterix, we don’t have any food,” explained Procurafix. “We are in the  middle of evaluating responses to our Supply Everything To Armorica RFP. The lawyers are embroiled in a battle over the Boar Hunting Rights clause, so the process might take a while yet. Rather annoyingly, this probably means we won’t have grain or water for a while either. It’s a single contract for everything.”

“That is annoying”, said Asterix. “In fact, your process sounds rather like another monolith. I’ll see if Obelix can move it forward. He is good at that.”

Building A Monolith

Obelix seemed to be the only one that could bypass Procurafix’s rules as when Asterix found him he was feasting on nuts and oysters. Asterix explained the sad state of affairs, and asked Obelix for help.

“Sorry, Asterix. I’m afraid I have some bad news. The Goths have offered me a much higher day rate as part of an extremely attractive package. Effective immediately, I’m working for them. You’re on your own.”

“Oh no! We’re doomed,” cried Asterix. “We should never have made those fucking monoliths.”

Daniel Jacobson on de-coupled publishing systems

Posted in architecture, commentary on October 13th, 2009 by seth – Comments Off

Daniel Jacobson, NPR’s Director of Application Development, has an excellent article on the philosophy of de-coupling the content management tier from the delivery tier. He calls this strategy COPE: Create Once Publish Everywhere. In particular, the diagram is particularly useful in showing how all the pieces fit together.
If you are in the content [...]

Related posts:

  1. Paul Graham on Post Medium Publishing Paul Graham, has an interesting essay on Post Medium Publishing….
  2. How Open Source CMS Fits into the Future of Digital Publishing In his summary of the SIIA Information Industry Summit, John…
  3. CMS Deployment Patterns One of my favorite terms in the world of Web…

Related posts brought to you by Yet Another Related Posts Plugin.