Julian Wraith

Menu Close

Category: Web Content Management (page 1 of 2)

Continuous Delivery vs Content Management

Recently I had a discussion where the initial question somewhat baffled me. Having thought about it more, I want to write something about it to see if I can come to a nice conclusion. The question was; Is Continuous Delivery a threat to Content Management? The form of the question predicates that the asker thinks that Continuous Delivery is actually a threat to Content Management, but why?

As someone who tries to take the independent stance but heavily leaning on Content Management for the staple of work, my initial reaction is that no, Content Management is no threat to Continuous Delivery, but nor is Continuous Delivery a threat to Content Management. Both have a place in any internet delivery environment and such a question is a little like comparing apples and pears. But for kicks, let’s look at it in a little more detail.

What is Content Management (CMS)?
Specifically, we are talking about Web Content Management (rather than the general definition). Wikipedia describes this as:

A web content management system is a software system that provides website authoring, collaboration, and administration tools designed to allow users with little knowledge of web programming languages or markup languages to create and manage website content with relative ease. A robust Web Content Management System provides the foundation for collaboration, offering users the ability to manage documents and output for multiple author editing and participation. (source: https://en.wikipedia.org/wiki/Web_content_management_system)

Systems like SDL Tridion Web make good on the following: allowing non-technical users to edit site content (and even manipulate layout), collaborate on content, version and reuse content across multiple channels and sites. Some systems allow for additional integrations to support content create such as translation systems, DAM etc. and changes can be made to a production website in a matter of minutes. Not all CMS platforms support direct updates but rather they rely on periodic refreshes of the content.

What is Continuous Delivery (CD)?
Continuous Delivery differs in what it, as an approach is trying to resolve. Wikipedia describes it as:

Continuous Delivery is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. (source: https://en.wikipedia.org/wiki/Continuous_delivery)

The focus here is on agility of changes in a development lifecycle with a heavy focus on automation of repetitive tasks to lead to productivity and quality improvements. These automated stages are things like build, test and deployment. They feature integrated products covering things like collaboration, unit tests, versioning and source control and typically this is focused on product (code which could be a website) development which can and often does include editing of assets such as labels, (website) content and binary objects.

Comparing the two
Both have overlap in two areas; versioning control and pipeline management. Both paradigms focus on rapid delivery of assets and both are only comparable if we are talking about the delivery of a website. A CMS is no good for supporting delivery of a desktop application. Whilst many CMSs support the delivery of code and have a web application, SDL Web does not mandate such a thing and you can develop any application you would like with varying degrees of code in the CMS itself. Currently, the recommended practice of SDL is not to include code in CMS, but to develop a separate application and have SDL Web deliver content which it can do in any form you need (e.g. JSON or XHTML). Continuous delivery specializes in the delivery of code and assets.

In Continuous Delivery, you can enter content assets into a versioning system (e.g. Git) and include that in your build which is eventually deployed. Content can be edited with a suitable IDE in a semi- non-technical form. I do not want to say completely non-technical because an IDE is typically still a technical tool. CMS systems tend to focus on empowerment of non-technical users and organizations that use SDL Web have non-technical marketing users editing content either via forms or using tools like Experience Manager. Content that is entered into the versioning system can then be pushed through the delivery pipeline into the deployment together with all the application code. This has an advantage in agility of deployment because the content will always be delivered by the deployment and the content is as available as the application. Where SDL Web sometimes has challenges is that you need to have a single, scaled and redundant source of content for the webapp. This means that always needs to be there to make the web application works. However, separating the two pipelines of code and content using CD and WCM means that you can make minute by minute changes to the website and not require the application to be redeployed. If you want to separate your web application from your CMS, then content can be delivered through content-as-a-service.

Every web application needs content so if you do not have a CMS then you will need to deliver your content through CD. CD will provide enough features to edit and manage content providing you have the right people and you allow the right speed of updates in the form of multiple deployments per day. What you lose by not having a CMS is the features that the CMS would bring such as content inheritance, translation, inline editing, per minute updates of content. For a simple site (i.e. a micro-site), having a full enterprise CMS is perhaps overkill especially if you do not already have a CMS. If you do, reusing content and content editing processes from the existing CMS is a considerable plus.

If your website is larger in content terms than a simple site and is really multiple sites in multiple languages with a high amount of content reuse, then using CMS and CD together, seems to be the ideal solution. You can manage all your content for all your channels (including campaigning) though one tool and develop awesome apps in record time with CD. One is not a threat to the other.

Going forward I would make a recommendation that your deployments are done in a microservice architecture and in that, your CMS content should be delivered as a service (along with all the other things like targeting). This means all deployed sites take advantage of content that is centrally managed, application deployments are not weighed down by large volumes of content assets and CMS features like content targeting are uniformly deployed on all channels.

Photo credit: Ian Brown (Flickr)

Integrating a PIM with SDL Tridion

This is a topic that is raised with me from time to time, mostly because of my connection with a large product company that I work with on a daily basis. A colleague prompted me to write this down properly, so how do you integrate a Product Information Management system, or PIM, with SDL Tridion.

It is fair to say that SDL Tridion, like most CMS systems, is not a PIM and should not be used as one. It is a Web Content Management System and as such its purpose is to allow any organization to create, manage and publish marketing content. PIMs hold a specific type of content which is product data, they vary in what they store but almost certainly the minimum that a PIM stores is product combination or SKU. The number of SKUs an organization has will depend on the amount and type of products. Simple products, e.g. cups tend to have fewer SKUs that say laptops; but in both cases it could amount to many thousands or many millions of possible product combinations. Add to this, SKUs change over time as products are updated or changed as manufacturing parts change or just new products are added.

When looking at integrating a PIM you need to have a careful look at the content stored and how that should be used.  Additional content that could be stored in the PIM could be things like product description and this content will need to be looked at in detail. Is it needed on the website? I it translated? Is it localized? On your website you will want to present a combination of this product content and your marketing content; in different places on your website this content will vary in what the mixture is. But, overall you will want to show a uniform brand and content experience.

How you integrate this content together should be a matter of careful decisions and I will run through three simple scenarios and some basic pros and cons that will help guide that choice.

Importing Product Data into Tridion
Importing product data into Tridion should be seen as the bottom rung of choices for an integration. We assume that the PIM is the master of the product content, if we import this content there will be two copies of the same content so in this scenario we should really decide if we are going to do something with this imported content (e.g. Translation). If we are, this scenario might make sense but, if importing this PIM content into Tridion it only really makes sense if the number of products is low and the number of updates (the delta) is also low.


  • Localization and translation of product content possible from within the CMS
  • Marketing has complete control over the content presented on the environment (from a single system)


  • Content import could be complex to implement
  • Updates need to be published

Integration at publish time
Rather than importing content, we can consider the approach of merging the product content with our marketing content when it is published. For this our marketing content must be tagged or reference in some way to related it to which product it belongs. The templates then render the combination of marketing content and product content together as the pages are published to the website. To relate content to product there are two choices; 1) a product taxonomy in Tridion either created by hand or imported from the PIM or 2) a manual entry of the product ID in the content metadata either completely by hand or helped along with a lookup calling out to the PIM. I personally prefer the taxonomy approach but the automated import of a complex hierarchy will have to be thought out well in advance.


  • Great for static content websites
  • Good for when a PIM is not available directly to the websites
  • Marketing content is easily kept in sync with product content (on publish)


  • Updates to product content require a republish of both sets of content

Integration at runtime
The last major choice would be to integrate the marketing and product content at runtime. This requires use to have some application logic on our website and we’ll still need a way of linking the content we are looking at to the product; we could still use our product taxonomy idea but we could also use other ways such as URL. In essence, we do the same level of integration as we did at publish time only one stage later.


  • Possible to implement more complex website functionality (e.g. product compare)


  • Product content can get out of sync with marketing content (e.g. available colours)
  • Requires a PIM or a sub section of it, to be available directly to the website


Did I miss some pros or cons or another scenario completely? Let me know in the space below!

JQuery as a Tridion GUI extension

Cool coding goings on in the world of Yoav. Experiments with JQuery and the Tridion GUI.

SDL Tridion MVP award

It has been a while since this really happened but I have been so busy that I have not had time to post anything about it. Since I last wrote, I was awarded an SDL Tridion MVP award for my work for SDL Tridion in and around the community. Next to me there 9 other individuals who also received the award. These 9 together with me were selected by a panel formed from SDL employees, partners and freelancers.

I extend my congratulations to my fellow MVPs and hope for good things in the future…

You can learn more about the MVP awards for SDL Tridion and see the full list of recipients on SDL Tridion World.

Training Matters

I have recently posted a new article to SDL Tridion World on the importance of Training. Proof, if ever you needed it, that I can write things that makes sense and do not include anything technical… 🙂 You can read the article here

Getting the Infrastructure ROI

roi1There has been much written on CMS vendor websites by marketing gurus on how to get the best Return On Investment, or ROI, on Content Management Software. There are also a number of good articles that give good coverage on the various aspects of your investment that you should consider. From my mostly infrastructure viewpoint I see allot of areas where the ROI impact is diminished because certain aspects are not considered fully when selecting the CMS or supporting software. Most papers on your ROI mention things like maintenance and hardware costs, but there are a number of other areas where you can look to make sure that you are not overlooking a drain on your ROI.

Hardware and Software

Hardware is often mentioned, it makes sense that the more servers you need to use the more the total hardware costs and their future maintenance will be. Also to be considered is the complexity of the implementation through having more servers in it and the impact on how you manage that. Consider what it will take to make your application perform within your requirements and more importantly to what hardware you really require with regard to your organizations Service Level Agreements.

When it comes to software, most Content Management Systems require some 3rd party software. Each item of 3rd party software that is required has a cost associated with it, Oracle or SQL Server? Windows or Linux? Each one has a cost not only in the purchase of a license, but also in configuration and maintenance. For instance, in my experience, Oracle is much harder to get performing correctly than say SQL Server. Having worked for Oracle in the past, I know an Oracle database can perform well within what you need for a CMS, but you will need the DBA to set it up for you and DBAs are expensive.

After such obvious 3rd party software as the operating system there are other things like file replication software, small custom solutions, scripts, utilities etc. Each one will effect the money you need to spend on the solution. Your IT team is often used to finding technical solutions to a problem without thinking about the ROI of what they are doing. Does the solution they need to solve the problem prove to be complex, costly to maintain and unreliable or can the CMS do it for you?

Installation & Upgrades

Specialist software often requires specialists to install the software for you, but some specialist software does not require specialists to do it all or even anything at all. Costs of installation and upgrades are in people and time. Who needs to complete it, what do they cost and how much time will they take. Consider the amount of people available in the market to undertake the upgrade or install tasks and the quality that they can deliver. I would rather have a consultant take two days to do a job that another can do in one day, but actually do a really quality install. Make a trade off in the resources you will need to get the job done and to the level you require.


Two points on this; complexity and re-usability… Too often configuration of complex applications is in itself complex, but that does not have to be so. Be sure that configuration is as straight-forward as it can be, it will lower costs of maintaining servers and increase good things like uptime (people will make fewer mistakes). Re-usability is key to deploying large applications; lack of re-usability in configuration (e.g. hard-coded paths) will mean an increase in configuration mistakes between servers and an overall higher cost of maintaining large sets of differing configuration.


I mentioned about the extra cost of having complex configuration, but the complexity of the implementation will affect more cost. All the 3rd party software you needed for your implementation has to be maintained, all the connections between servers, all the interfaces etc. We can reduce the cost of all these through effective IT procedures and you should look if the CMS software that provides solutions for helping with those procedures. Monitoring through SNMP is one way a CMS application can help you maintain it, using standard technologies that integrate well with existing tools an IT team might already have is another.

One aspect to consider is who will maintain your application? Do you need a specialist or more than one? Do they have the time to maintain the application? Keeping it alive is one thing, making it work for you is another. To get a specialist, do they need training and who do they get that training from? And the training should not just include the CMS but also all the 3rd party software you needed too as well as training on the implementation you built; it will be different to all other implementations out there because it is the one that suits you.



Nearly all vendors offer Support contracts to help you with problems with the software. In any typical implementation there will be parts that you have built yourself. These might be as simple as a template but could be as complex as a custom CRM integration. Typically neither of these two things fall under what a vendor support team would support. They support that you can write templates and the API that you interact with but they probably won’t support you getting your template to work how you wanted (unless they are really nice). Product versus Implementation is important to consider. If you needed to make a custom part of the implementation you need to be able to support that yourself or via the implementation partner who created it for you. If you never had to make that custom part of the implementation because it already existed in your CMS product, it will be supported by the vendor support team.

And so what if you had to create a CRM integration? You should be able to feed that back to the vendor so that they can include it in the product. How close are you to the enhancement request process?

Agile Development with SDL Tridion

Last week I attended a seminar organized by Hinttech on Agile Tridion Development. The seminar and its participants discussed the use of Agile development methods when creating sites with SDL Tridion. Agile development is something more and more customers are asking for but then how does that fit into a Tridion project? Laurens Bonnema was on hand to give his view on Agile development and how it should and should not be used. Robert Quaedvlieg from SDL Tridion was also on hand to give a view on where Agile might fit into the SDL Tridion Implementation Methodology. The Implementation Methodology is essentially a SDL Tridion variant on the traditional Waterfall model. This is the traditional project methodology and lends itself very well to projects where we need to (or do) know what we are going to build up front. Agile tends towards situations where we do not know the requirements at the start. My aim here is not to explain Agile development – you need to read one of the many good books or even Wikipedia to get a good short explanation – However, I will lay down some very basic concepts so that the rest of this document is clear. Typically, you do not know the complete requirements up front and part of the Agile process is to define the requirements or backlog. These backlog items are organized into sprints and at the end of each sprint the development team has a working product (with the features worked on for that sprint). In theory that means you have something deliverable at the end of each sprint and, in my view more importantly, you are fully away of the progress you are making. There is more to it than that but the important factor is that the priority of development can be changed at anytime without having to go back and change a monolithic requirements document. At the end, you should have a product that is what you want at the time you want it. Rather than a product which you wanted when you made the requirements.

So how does a Tridion project fit into this?

Looking at any regular Tridion project, there are a number of things that look to fit well into an Agile process and others which do not. Some of the things that do not, I do not think every really could fit well into Agile development, probably because there is nothing to develop, more something to be worked upon. However, even those things can be injected with Agile juice to make them flow easily next to the sprints.

Ignoring the Tridion Implementation Methodology, I will outline some of the various parts of a Tridion project and whether or not I think you should approach them in an Agile (A), Semi-Agile (S) or Waterfall (W) way.

Organisational aspects of a Tridion implementation are key to ensuring a successful project in the long term. Like any organizational structure it should focus on the long term and will be the foundation on which this and future projects are built.

What How Why
BluePrint Design S The BluePrint is the corner stone of any Tridion Implementation and is key when you move forward past the end of your project. As such it needs to be fully understood before it is laid down. That said, you can change it to some degree as you go forward, so once the initial design is set you can add to it providing you are prepared to accept the impact from doing so.
Security Design S Security is who has access to what and what they can do with it. It can be decided in the basic form up front, but after that it should be flexible to be changed and grown upon.
Business Processes and Organization W This is a question of understanding the business and how it operates (or wants to operate).
Support and Maintenance W Defining the support and maintenance processes tie into the Business Processes quite tightly.

Content Management
There are two parts to any CMS implementation, the creation of a Content Management environment and then the application to consume the content. In creating our Content Management environment we decide how we are going to manage content both functionally and structurally.

What How Why
Schema Development A Will change frequently during the development cycle
Template Development A Will change frequently during the development cycle
Folder/ Structure Group Setup A This supports the template and schema development
Application Development A Building Blocks are what makes the application. These will change frequently during the development cycle
Event System Development A Will change frequently during the development cycle
Workflow Development A We already will have decided something about our business processes in a waterfall model. Workflow will change frequently as we add more and more content types
Migration of other systems S Often a risk area, migration can be treated semi agile with ease. We know some requirements from the start, however, knowing all requirements can be very complex.

Content Consumption
Consuming the content is a very general topic; it can take any form from a simple .NET application to a MVC framework or webservice. The consuming application’s job is to take deployed content and present it to the user or another application. It is very much a technical coding exercise

What How Why
Deployment Extensions A Deployment Extensions, for example, a Google search integration, can easily be part of a sprint
Consuming Applications A Often the bulk of a development activity is here and this can easily be done in an Agile way

Infrastructural & Integrations
These sorts of activities tend to involve a large amount of people and a very rigid process model. It makes agile work in this area very difficult and you would generally meet stiff opposition.

What How Why
Infrastructure Design W Needs to take into account strict processes and design parameters. Often hardware cannot be purchased until a full design is in place.
Installation W This is an activity that can sometimes be done in sprints (e.g. hardware, OS, CMS, Modules etc), but that is more from practicalities than being designed to look like sprints
Configuration S Configuration of servers should be timed to be worked on post sprint. Configuration and setup adjustments from the sprint can be implemented directly so that the resulting product from a sprint can be put into production. To do this for every sprint would mean that the hardware & software installation should have been completed before the first sprint.
Integration Development A Most integrations are development activities and therefore can easily organized into sprints.

Additional Thoughts
Many standard engineering practices should be implemented that will help you in being agile. These practices stem from traditional development practices but are often overlooked. What is important in each sprint is that all the work you have done has broken nothing from any previous sprint, so structured testing can help you achieve this. Unit and UAT testing can both aid the development process and ensure a quality product. UAT testing can also ensure that the content management environment will work well for the content editors. Getting the editors in and letting them have a play early on might just ensure that they accept the application when the last sprint is complete.

Overall you need to use common sense (in this I very much agree with Laurens). Agile is not the way to solve all evils. Not only are some things just not possible to do Agile but some people cannot (yet) do agile.

Pushing my buttons…

Today I saw this tweet:
“Tridion is boring. I wish we did open source CMS”

And I had to react:
“”Tridion is boring. I wish we did open source CMS” Drupal, now featuring Content Editor excitement pack… :)”

Firstly, I would like to remark that maybe someone was having a bad day when they wrote this, but the tweet really did stand out as being the largest amount of rubbish that someone could stick in 140 characters that I have read for a while. Or was it?

I did stop to ask myself is (SDL) Tridion boring? What do I find interesting? Well, what I find interesting is probably best left off this webpage but all things being equal I think you can all imagine that the leading WCM product is not going to be something that is going to light my fires of my interest on a daily basis. In short, it takes more to get me going.

Wikipedia (don’t shoot me Cheryl) defines three types of boredom, of which one of at least our tweeter must have been suffering and all of which are related to problem of engagement of attention:

  • times when we are prevented from engaging in something
  • when we are forced to engage in some unwanted activity
  • or when we are simply unable, for no apparent reason, to maintain engagement in any activity or spectacle

I highlighted the one key word in the above types, engage (or engagement).  Now I have read allot about engaging customers on websites managed by WCM solutions but I have not read anything on engaging the users of a WCM solution. But maybe he is right, it should be exciting! But then what sort of things would make it exciting? Facebook integration so you can update your status from the WCM interface? Random page publishing? I used to have a sheep that lived on my desktop, it used to do things like munch the side of the windows and take a bath. Maybe that would be good? Maybe RedDot could have a moving RedDot that you have to catch…  or maybe we should just go ahead and integrate FarmVille. I know one website management team that would be very happy with that…

So, is your WCM product engaging to the editors? Does it light the fires of interest every time it pops up? Or does it have the same tedious tasks that other products do? Is yours open source and therefore automatically interesting? I would love to hear it, I am genuinely interested…

And before you respond, take this tweet into acount, clearly this organization has the key to editor engagement already…

“@julesdw @dirkwybe Have a Squiz @ MySource Mini – free to download as VM image here: http://bit.ly/1xCgk2 Revolutionary editing interfaces.”

The Future of Content Management, the follow up

The Future of Content Management is something that I have thought about for a while. But without a good conclusion and so I decided to open it to the floor of CMS Gurus. So I posted a few weeks ago and went on holiday. Not the ideal way to create a meme, but I could not wait to get started. On my holiday I did not have the chance nor the inclination to even think about it. However, a week back from holiday I owe you all a follow up post with at least the highlights.

Today, as I write this post, I am flying between Amsterdam and Chicago on my way to San Francisco. I did not take the direct flight – before anyone points that out – because of the time I have to be back. My flight this morning was overbooked but they guaranteed me a seat on the plane and told me that I would find out later where I will sit. As it turns out, I got an upgrade to business class. Moments before I found that out I heard an announcement about an option for people to upgrade to business class for 450 Euros. I tisked scornfully under my breath and mumbled something about being an idiot to take up the option. Moments later I was in business class for free and I suddenly felt allot more important. Now that is what I call value for money!

So in-between sipping my white wine and I shall have a look at what everyone wrote about the Future of Content Management…

Whilst many of you professed and inability to look into the future, it was clear you all have more than an idea on many aspects. Some of us have more of a dream than others… some of posted based upon your leaning from either ECM, WCM and commercial or open source. And some wrote their own rules to how they were going to respond. As my only rule was “there are no rules” I liked the spirit of doing something different.

I cannot really attempt to outline exactly what everyone said; it is just too much to take on in a way that would justify the meaning of each article. For that you need to read them for yourself and you will find the links at the bottom.

With the recent acquisitions and the general downturn it is likely that the face of vendors will change more that is already has done over the course of the next year. The recent Forrester and Gartner reports have re-asserted some companies positions and surprise people with how some of the reports view other companies. Those that do well will no doubt pick on the weak until we lose a few more vendors. Is Open Source the way? Well as Adriaan Bloem pointed out Open Source is just another license. If commercial software has trappings then Open Source does too, just different ones. I am not a believer that open source will over take commercial software, just that commercial software will leverage open source (and especially open connectivity) just as well as Open Source. In that the playing field will remain level for a long time to come.

I hope and pray monolithic vendors die a slow and painful death but I just know uncreative people will continue to advise customers to invest in such solutions.

“I’ve been in this WCM industry awhile, so lets put aside the crystal ball a minute and ask if we have yet delivered on the CMS promise of 10 years ago? ”

Judging by the thoughts from everyone the simple answer is NO.

Whilst Ian was talking about making the people have the power, the quote fits right in here too. We all grumbled about the lack of standards and the continuation of proprietary standards that rule our customers. There is CMIS but it lacks a really usable implementation and JCR just is not a standard. Yes, it is if you use java but not for the rest of the world.

Uniform repository access will definitely help but mostly it is going to help with being able to migrate systems and join multiple systems together. In the end if we cannot fix even the smallest of real world problems you can forget trying to get two different CMS systems to just “Plug and Talk” On the other hand it is good to know that Sense/Netbarely has any serious CMS vendor issues that have been upsetting customers throughout the years”, even if the list was not complete.

I spend allot of time thinking about this (well OK, a little bit of time) and it is something I like to hear people like Frank talk about. He has great views on what content is and how it should be used – but did not post on this topic (booo!). Challenges we have are how to use the content we have, how long should it exist and what even is content? Is the content that we produce going to live and die in a moment or does it have real life? Social media is perpetuating content that has a very limited life. When was the last time you looked for a Twitter post you had seen a while back? You do not, it has ceased to exist, it is an ex-piece of content. If anything Twitter is a discovery engine, you can discover what is going on, not where to buy a cheap car. This short life also means that some social content has a much more limited value and you can be more risky with it. However, most commercial CMS systems do not truly hand the power to the people, there is also limited tools to help employees create, manage and distribute content remotely or on the move which is something social media requires. For open source the picture gets better, but the most I can manage is Twitter from my iPhone.

That said, almost all vendors push social media connectivity as part of their products but as Ian points out “But, for all that, websites are still the destination – the majority of tweets are linking people with web content. “ So, do not only give us Twitter to tweet our content, give us the mobile application to write the content and then tweet it.

In the end the Twitter bubble will burst unless something happens to give it true value. If that happens the selling point of Content Management Systems will move to other new topics, and hopefully this will be a back to basics move on making content work powerfully rather than enhancing their offering with badly integrated applications that demo well.

The full list of articles is as follows:

There is still chance to contribute to the discussion by posting your view on the Future of Content Management. We did not hear from a great many people, if you post then do not forget to tag your post.

Hashtag: #CMSFuture
MD5 tag for your posts: 6f82f1d2683dc522545efe863e5d2b73, find more related posts

The future of Content Management…

This week Jon Marks posted his list of 40 (now 56) CMS gurus to follow on Twitter, I made the list so now I feel the pressure to say something of genius that will amaze the group. Truth is I have nothing. I have nothing because I am one day from my holiday where my attention can only be brought to thoughts of mountains, dynamic views and scotch. Yes, I am going to Scotland! I hope it won’t rain but hope is always filled with a certain sense of reality – it is Scotland, it is going to rain buckets.

Even before Jon’s post I have been trying to be inspired to write something that I feel passionate enough about to post. I guess I have been too busy to think, net alone get the time to actually post.  However, late last night inspiration hit me and then, after consideration it hit me again! So I put aside the first idea and moved on to the latter one.

It occurred to me that all the CMS gurus are not really discussing. Sure we are partaking in the “global conversation”, blogging and commenting and some of us actually seem to do this for a job. For a discussion you need a topic. Evil genius Kas Thomas managed this, to some extent, with the CMS Vendor Meme but that was too general and too now for what I want to hear. So I have come up with the following challenge.

My challenge is to all the CMS gurus that read or see this post (and by god am I going to try and make sure you read it) is to write a blog post with the title “The Future of Content Management” and start with the line “The future of Content Management is… “. Clearly there is alot of scope in the answer which is of course the idea. Post your answer on your blog and comment on this post with your link. Don’t forget to use the tag in twitter and on your post.

After my holiday I will be checking back on progress. Some of your comments will have to wait until I am back to approve them (sorry), so please be patient.

Hashtag: #CMSFuture
MD5 tag for your posts: 6f82f1d2683dc522545efe863e5d2b73, find more related posts

© 2019 Julian Wraith. All rights reserved.

Theme by Anders Norén.