Oct 212008

I just got around to watching Friday’s webinar by Optaros about Alfresco in the media industry.  In it, Bob Fitzpatrick highlights three major points regarding how to increase online revenues:

  • Increase user engagement with your content
  • Extend the reach of your content
  • Enable API access to your content

As a prerequisite though, companies should be converting their content into assets that can be managed centrally.  In so doing, content can be easily related to other content and then be syndicated, retrieved by third parties, or composed and presented to users.

In addition to the aforementioned strategic goals, companies should strive to deliver on them in an efficient manner.  According to Bryan Spaulding, this means building a system with a Media Service Architecture that scales and enables exposure to PCs, mobile devices, and TVs.  And don’t forget to instrument your system such that feedback can be obtained to enable reporting and thus tweaking of the platform.  Jeff Potts reminds us that Alfresco and Optaros can be levaraged to get you there faster via their awesome capabilities.

What is interesting to me about all this is the different approach to the problem.  At Ringside Networks, we focused on the “beefy middle”, as Shaun Connolly so eloquently put it.  In a nutshell, this meant enabling social interactions in the context of existing web sites with existing users and content.  Restated in terms of a Ringside customer’s objectives, those three goals might look like this:

  • Increase user engagement with your web site
  • Increase the reach of your company/brand
  • Enable API access to your site’s social capabilities and/or users

In the Alfresco/Optaros case, the underlying premise is that content is of the utmost importance, and that people will pay to enable their users to interact with your content, or better yet to advertise around your content.  In the case of Ringside, it was all about identity and interaction on your site amongst your users, with new eyes sourced from various social networks.  SocialPass is taking yet another approach, which brings people to your site, regardless of where they came from.  Either way, people would pay to bring users to their web sites.

I think the best of both worlds can be achieved.  There will be some shops that won’t be positioned to re-architect their content management systems, and will pay to bring new users to them.  Hopefully their advertising revenue will more than offset the costs of customer acquisition.  Other shops will be well positioned to capitalize on their content via a solid Media Service architecture.  Finally, there will be shops that do both.  I can imagine the NY Times online syndicating images, videos, and stories, providing API access, and serving photo galleries and videos along side related stories with personalized SocialPass conversations involving Facebook users, MySpace users, E-Mail invitees, and Twitter invitees all on the same page with integrated ratings and persistent commentsThis is nirvana!!!

Apr 202006

SOA is not necessarily ‘Web Services’.

A service oriented architecture could be implemented in many different ways. One implementation might be a client-server application, where services are independently deployed to the SOA platform and accessed by client programs. Think of 20 cash register operators at Wal-Mart (the client programs) and a server running a set of cashier related services in the back room somewhere. This might all be implemented in Java.

Another implementation of a service oriented architecture might involve traditional ‘Web Services’ implemented using SOAP (Simple Object Access Protocol) and WSDL (Web Service Description Language). Imagine Amazon.com providing software services to their business partners and UPS providing services to Amazon.com. In this scenario, Amazon.com might have implemented their system using Java, whereas UPS implemented their system in .NET. This is the value of ‘Web Services’ – SOAP and WSDL enable these heterogeneous systems to communicate with one another. The SOA part of this scenario lies in the fact that new services can be deployed and consumed independent of the existing services currently deployed. SOA enables this loose coupling which is quite valuable from a business standpoint, as I discussed before.

So service oriented architecture is not necessarily coupled to ‘Web Services’. It’s more of an architectural style.

Apr 192006

Why should anyone care about SOA?

Service Oriented Architecture (SOA) is the idea that business functions can be built in such a way that it becomes easy to produce or consume any service by loosely coupling services from consumers (and from each other). If you have an operational service that currently accepts standard purchase orders, it should theoretically be easy to build and deploy a new service that compliments the existing one. For example, perhaps your users want the ability to change the quantity of supplies ordered before the order ships. In theory it should be very easy to create and deploy such a service along side the existing purchase order service. Additionally, it should be easy for system integrators to integrate with the new service, and thus users of the service can use it much sooner.

You might be thinking, who cares? Well, here’s why it’s important. Enabling loose coupling of services makes software cheaper to produce and consume. Many companies have spent many millions of dollars on maintaining and/or modifying very tightly coupled systems. By enabling loose coupling and standardizing on certain technologies, companies can produce services more rapidly. Also, companies that consume those services can integrate with newly created services more rapidly, thus enabling their use much more rapidly than was previously possible. This has the downstream effect of providing value to users more quickly, which can generate economic activity.

So who cares about SOA? You should if you want to deliver value to your users as quickly as possible.