Rivet Logic Blogs

Category: Standards

SaaS Based Collaboration

The first aspect and most basic use of Alfresco Cloud is as a cloud hosted collaboration application for your organization. Alfresco Cloud is multi-tenant and can host as many organizations (which Alfresco calls networks) and project spaces within each of those networks as is needed.

In the illustration below you can see two independent organizations each with several project teams working independently on the Alfresco Cloud.

If you need to spin up a simple collaboration environment for your department Alfresco Cloud is a great solution. Alfresco Cloud is affordable and based on per user pricing. There is zero software to install or setup and you get a ton of really rich collaborative features from document libraries to wikis, calendars, blogs and much more.

Cross-Organization Collaboration

Where things start to get really interesting, however, is with cross-organization. With Alfresco Cloud you can manage content between organizations to enable B2B interactions between knowledge workers from the different organizations – again all with zero infrastructure setup.

In the illustration below you can see a project team from each organization collaborating with one another through Alfresco Cloud’s permissions which ensure that only that content which should be shared is in fact shared.

Alfresco One: Private – Public Cloud Sync

The thing is that not all content is meant to live in the cloud. Organizations of all sizes generally have some content they still feel needs to be controlled and secured inside the firewall or as is often the case, there are integrations with critical business systems that are mandatory and those integrations are only possible between systems located within our firewalls.

With Alfresco Cloud this is no issue. You can setup and host your own private infrastructure internally which serves as the system of record and hosts all of your content including those items which must remain internal and for content you want to collaborate on with organizations outside the firewall you can create a synchronization (using Alfresco One) with Alfresco Cloud and synchronize specific content between your organizations private infrastructure and the cloud to facilitate the collaboration.

In the illustration above we have a private infrastructure on the left and the cloud on the right. You can see that some project teams are working only against this internal infrastructure while others may work only against the cloud. And we can see a secure, relationship between our internal infrastructure on the left with the Alfresco Cloud on the right. This synchronization is enabling our teams to collaborate with one another regardless of whether they are working on public or private infrastructure.

Remote API for the Cloud

And finally Alfresco Cloud supports a remote application programming interface or API which is based on CMIS (Content Management Interoperability Standard) and a few additional Alfresco specific non-CMIS APIs.

This is a real game changer because it means that collaboration no longer has to take place through the user interface but as we can see here in the diagram we can enable applications and automated processes to participate in our collaborations – and because we have a sync between private a public cloud infrastructure we’re not just talking about cloud based content storage here – which is great in its own right — we also have a very powerful integration platform.

When you combine the API and the public/private sync what you gain is infrastructure akin to an integration bus.

As many of you know Alfresco introduced its cloud offering almost a year ago. At the time of this writing there are a number of unique ways you can interact with Alfresco Cloud:

Collaborative SaaS (Software as a Service) application. Teams to quickly spin up collaborative spaces (in Alfresco’s Share application) and begin working together with zero on premise software.

Members of the cloud can join multiple networks which enables them to work and collaborate across organizational boundaries.

Custom applications can use Alfresco Cloud as a store. You can interact with cloud through an API (CMIS and Alfresco specific RESTful APIS.)

And you can sync content between your on-premise instance of Alfresco and the networks with-in cloud that you belong to.

Share in the cloud as a SaaS offering is a pretty obvious play. There is a lot of value in this simple use case for organizations that need good collaboration tools but just don’t have the appetite for or enough user volume to justify hosting their own infrastructure.

When you combine this SaaS offering with the ability to securely and selectively collaborate with other organizations, you are now enabling all kinds of people-oriented B2B interactions that can be extremely difficult when you have a system that is stuck behind a firewall.

Add to that an API to that and now it’s not just people-oriented B2B and internal interactions that can take place, it’s automation and rich behavior. At this point Alfresco in the cloud is no longer an application. It’s a bus.

Now not all content was meant to live outside the firewall and not all systems can or even should live/reach outside the firewall. With Alfresco’s “cloud sync” capability Alfresco Cloud closes this gap by allowing organizations to selectively and securely sync specific content between an on-premise instance and the cloud. This is extremely exciting because it opens up a whole new realm of possibilities for B2B integration and mobile enablement.

If you’re thinking about Alfresco Cloud as a simple collaboration application or a simple cloud based content store it’s time to rethink. Alfresco Cloud paired with Alfresco on premise is an extremely exciting hybrid architecture and integration middle-ware that opens up use cases which have traditionally required dedicated business to business infrastructures that were difficult to get approved let alone set up: basically not possible.

On March 14th Rivet Logic will co-host a webinar with Alfresco entitled Using Alfrescos Hybrid Cloud Architecture for Better Web Content Management where we will discuss and demonstrate how hybrid architectures can be applied in a WCM (Web Content Management) context to enable collaboration with external partners like agencies and for integrations with other content services, providers and consumers such as AP, Routers and the like. While WCM use cases will be the focus of the conversation, the topic is perfect for anyone interested in learning more about Alfresco hybrid architectures. See you there!

Digital assets are a key component of almost all web experience and customer engagement projects. In today’s era of engagement with all of the additional content targeting, personalization, internationalization and multi-channel publishing the number and permutation of digital assets associated with any given project are growing rapidly. This trend will only continue as we move forward. Content workers (authors, designers, content mangers) need to be able to create, locate, modify and manage the growing number of assets easily and efficiently in order to maintain brand quality and deliver projects on time and on budget.

In today’s blog entry we’re going to focus on the creative side of WCM (Web Content Management) and DAM (Digital Asset Management) even though this is only a small portion of the overall set of use cases.

Let’s begin by considering the following example use cases:

Create mobile appropriate image resolution variants

Create video stills

Imprint watermarks

Thumbnails for galleries and promotional kickers

Each of these use cases are important ingredients in providing the user with a great experience but they also introduce a lot of additional work for our content teams. One of the ways to deal with the large volume of asset creation and manipulation responsibilities is to automate them. The use cases mentioned above and many others like them are a perfect candidate for automation.

Crafter Rivet leverages Alfresco’s enterprise content management services for image transformation. With a few simple rules applied at the repository level it’s possible to provide your content team with image resolution variants, video stills, apply watermarks, to scale and crop thumbnails and then to make these assets available for review by our authors all in an automated fashion with no additional labor required beyond uploading the canonical assets.

Another important way to help our content teams cope with the sheer volume of digital asset related workload is to make sure our teams are able to work with the very best tools at their disposal. With today’s modern browsers it is possible to provide a fairly decent set of tools / asset manipulation functionality right with-in the browser. However, while purely web-based tools have their advantages they are often slower and much less powerful than the desktop tools serious content contributors are used to working with.

The biggest productivity boosts are gained when we empower our designers and other content workers on our team with rich, native tools that they are already familiar with and work with on a daily basis.

Adobe’s creative suite (which contains tools like PhotoShop) is the quintessential software package for image/digital asset creation and manipulation. Designers are deeply familiar with these tools and are able to leverage their enormous arsenal of capability to accomplish a tremendous amount of work in a short amount of time. The issue that many organizations often face, is that while the tools themselves are great, the interfaces between the tools and the systems that ultimately store, manage and deliver the assets are either non-existent, human-process based, or have clunky integration. This gap creates a drag on the margin of productivity and introduces room for error.

Fortunately Alfresco, Adobe and Crafter Rivet Web Experience Management have a solution that connects rich, creative desktop tools, to your systems of record (e.g. repository) and ultimately to your systems of engagement (e.g. website) in a seamless fashion. Content creators work right with-in the rich, local tools that they are familiar and productive with and those tools are deeply integrated with the repository which means that all of the organization, policies, metadata extraction, and versioning provided by the repository etc are seamlessly integrated and enforced. Alfresco is a CMIS (Content Management Interoperability Standard) compliant repository. This standards based interface enables it to communicate with external applications like Adobe’s products in order to interact with and operate on the content, metadata, permissions, versions and so on housed within the repository. Adobe provides a platform called Adobe Drive which enables its tools to connect in a rich fashion over CMIS to Alfresco. Once we’ve connected our Adobe tools and our Alfresco repository authors working within Crafter Studio, the authoring and management component of Crafter Rivet can now see content updates coming from the Adobe tools right in context with the work they are doing through in context preview and editing. They can also interact with that content through the web based tools, workflow, versioning, metadata capture and publishing capabilities of Crafter Studio.

By closing the integration gap we can now provide powerful tools for productivity and at the same time do so in a way that makes it seamless and easy for our creative teams to collaborate across the entire process.

Click on the video below to see Adobe and Crafter Rivet WEM / Alfresco in action together!

Crafter Rivet is a 100% open source, java based web CMS for web experience management and customer engagement. Learn more about Crafter Rivet at crafterrivet.org

Generally speaking there are two main types of Web CMS architectures: coupled and decoupled. Coupling refers to the relationship between the authoring tools and content delivery of your live site.

The classic example of a coupled CMS architecture is a blog engine. In a coupled system, the underlying store for your content serves both authoring and delivery. Your authoring capabilities are part of the live delivery system but are available only to those who have permissions. In a coupled system, the process of making content live is typically a matter of setting a flag in the database.

A decoupled system by contrast is one that puts authoring and delivery in separate applications, and potentially, on separate infrastructure. In a decoupled system, the process of making content live is done through a publishing mechanism where content is pushed from the authoring platform (and underlying content repository) to a content delivery infrastructure.

So which approach is the right architecture? The reality here there is no single right or wrong answer. The answer depends on context: alignment with your requirements, your business process and your business goals. The topic of coupled vs. decoupled is not a new one. It’s a debate that has been going on for a long time and will continue to go on so long as there continues to be Web CMS platforms, “fan boys” and a perception that one size fits all. The more appropriate way to approach the question is to analyze the strengths and weaknesses of each approach and then to consider these in the context your own specific use cases. We’ll see that in different scenarios we come to different conclusions on which architecture to use.

Coupled Architecture

Let’s take a look at the strengths and weaknesses for a coupled CMS architecture.

Strengths

Easy to set up and deploy a single instance.

Authoring and delivery are on the same infrastructure which can make it easier to build cohesive authoring tools.

Relatively easy administration of production system for single sites

Weaknesses

SLAs (Service Level Agreements) are coupled — meaning that authoring has to be just as available as the live site.

Coupled infrastructures are generally more complex to scale, as they typically depend heavily on database scalability.

Content is typically captured in a database schema meant for delivery on the site. This can make integration and migration difficult.

Software complexity is higher because the code base contains both authoring and delivery concerns. All but the most trivial CMS projects involve some development, and thus becomes an development issue.

Pushing content in and out of the CMS to and from third parties takes place in the same system that runs your live site. Integration is not native to the architecture and it may impact the system’s performance.

Decoupled Architecture

Let’s take a look at the strengths and weaknesses of a decoupled CMS architecture.

Strengths

Easier to scale for high traffic websites, and to handle multi-site management.

SLAs are decoupled. Authoring can be down for upgrades without impacting delivery. The reverse is also true.

Scale only the components that you need. If you are not adding more authors then there is no need to scale out authoring. This affects the complexity of the solution and also license costs where they are involved.

Code complexity is isolated within each of the two components (authoring and delivery). Each piece can be as simple or complex as is needed without impacting the other.

Integration is a built in concept, as content is natively published to a the remote delivery system, it is generally straightforward to push to other systems as well. Also note, integration takes place on the authoring tier safely away from the live site protecting stability and performance.

Content migration and sharing with other systems is generally much more innate to the architecture.

Multi-channel support by nature, as publishing to mobile apps, social channels, and other digital channels is a natural extension of the native publishing capability.

Content sharing and syndication are more naturally supported.

When complexity is isolated and scaling is simple, it’s easier to develop and deploy rich features to your users.

Weaknesses

Setup has more components and can be more complex.

Publishing introduces additional points of failure.

Sub-division of components can go too far driving up complexity and driving down the cohesion of the user experience.

Making a Choice

It’s clear that each approach has its own strengths and weaknesses. A coupled approach may work really well in once scenario while a decoupled approach may be much more appropriate in another.

Our analysis reveals that a coupled architecture can work well for websites that need to be set up and put on line in short order and that do not need to be able to scale quickly or to publish content beyond the website itself. On the other hand, we see that a decoupled architecture is ideal for websites that require high levels of availability and performance, need a lot of tailored functionality, must be integrated with third party business systems and must publish to one or more digital channels beyond the website itself.