BRob On Tech

Since my last post about how I could have used a Document Management (DM) system in a former life, I’ve been thinking about the statement I made about how certain I was that it would have saved the company time and money had we used a DM solution.  That’s the kind of statement that a Tech enthusiast likes to make withouth substantiation, and yes I’m a tech enthusiast.  However, it would be much more powerful to boil it down to dollars and cents.  It wouldn’t take much to truly quantify those savings either. Additionally, it wouldn’t take much effort to estimate savings and calculate a projected ROI for DM implementation.

I’m thinking back to my week of Lean Six Sigma Green Belt training, and I recall the general concept that you can’t improve a process that hasn’t been measured.  That said, it would be fairly easy to simply time someone performing a task or set of tasks before DM implementation to estimate cost savings, and then again after DM implementation to monitor progress.  You could go deep and set up a control chart if you really wanted to, which actually may yield information about special cases that cause delays, and provide further opportunities for automation.

I’m wondering if any Six Sigma experts or system integrators out there have actually done any projects that leveraged DM software to increase knowledge worker efficiency and automate their work.  If so, please comment here and share what you’ve found!

Last week I began working for Alfresco Software, as I previously announced.  During that first week, I learned about Document Management, amongst other things (like the Spring Framework for example).  The end result: I wanted to kick myself.  It really would have been nice to have Alfresco’s Document Management solution in place when I was working on Gestalt/Accenture’s CMMI level 3 compliant Agile software delivery method!

Our process for defining processes was basically this:

1. Draft the process
2. Pilot it (and make revisions based on what was learned)
3. Approve it
4. Deploy it

Of course, there were several sub-steps within those processes, and they required version control, auditing, and moving documents to different folders at certain times (a document workflow).  At the time, we used Sharepoint as best we could to manage all this.  It handled version control and auditing, but it had two shortcomings as I recall.  First, there was no automated way to baseline a set of documents as being part of a release candidate (such as you can do with CVS or Subversion tagging).  Second, the moving of documents was all manual, every step of the way.  This doesn’t sound like much, but as I recall, we had six or seven folders in the workflow, and we could have used some automation when doing round robin peer reviews within our team.  And the deployment of these assets was no trivial matter; I remember it took me almost a whole day to learn how to deploy a set of process assets, and then deploy a set of them for the first time.

So as I went through “Getting Started With Document Management“, I was shaking my head the whole time.  It is so easy to create content rules and workflow rules.  Instead of manually moving documents from folder to folder, a workflow could have been set up to do that automatically.  Instead of manually notifying a teammate that it’s their turn in the round robin peer review chain, the workflow could have done that for us.  And best of all, we could have easily set up a templatized space that could have been used for all of the processes and associated documents that we delivered over the course of over two years.  Finally, because Alfresco is open source and standards based, we could have extended the platform to automate our specific processes for deploying process assets.

Considering the number of documents we handled, the amount of reviews, the number of gates in the process, and the number of people involved, I have no doubt that if we used Alfresco we would have saved a lot of time and therefore money as we defined, piloted, approved, and deployed new Agile processes across the company.

So yeah, document management software is a great thing.  I only wish I knew about it years ago.

Today is my first day working with Alfresco, which I am very excited about!  Let me tell you why.

Over the weekend I read an old article by Peter Drucker called “Managing Oneself”.  In it he basically says that knowledge workers should know their strengths, how they perform best, and what their values are.  Then you can make well informed decisions regarding where you belong and what you can contribute.  I found this article very interesting in light of my recent job search.  When I started out, I knew what my strengths were.  First, I have deep technical experience as a software engineer, having spent eight of the last ten years writing software, and doing all of the things associated with it (see my profile on LinkedIn for details). Second, I’m very well versed in Agile process design, modeling, implementation, and deployment, having spent two years working with a great team on developing the processes for an Agile software development methodology that was also CMMI level 3 compliant.  That methodology is well on its way to becoming THE official Agile delivery method for Accenture. Third, I have been an active ScrumMaster since January of this year, and thus have competency with Agile project management (for which I’ve been told by several people that I do a very good job with).  Finally, I’ve always had a thirst for learning, have a commitment to delivering quality work products, and work very well as part of a team.

I perform best under deadlines. I learn best by doing, and second best by reading.  I believe that I work best as part of a small organization.  I value integrity, family, learning and growth, excellence, and service.  In the workplace, that means doing the right thing, doing it well, doing it transparently, serving the customer, and always learning and growing.  That’s the kind of environment that I want, and I believe I have found it with Alfresco.

Alfresco is an open source software company that delivers enterprise content management software.  In my new role, as I understand it, I will be doing some pre-sales work, identifying how Alfresco software can help deliver on potential customers’ needs.  I’ll also be doing some architecture and design work for customers and partners, once they’ve made a decision to use Alfresco’s software.  Finally, I’ll be doing some development, contributing back to the open source products that Alfresco offers.  In this role, I believe I can leverage my strengths as a software engineer, as a planner (the process work I did required lots of planning), and as a project manager.  I’ll get to learn and hopefully master the domain of enterprise content management.  I believe the team is a very good one, based on my interviews, a person I know that works there (Hi Jess!), and Matt Asay, whose blog I have been reading on and off since the beginning of this year.  Not to mention the successful nature of the business!

So today I begin a new journey with a new team, and I’m very excited to get started!  I hope to define exactly what I will contribute over the coming weeks while learning about enterprise content management.  If anyone has suggestions or ideas on how I can quickly come up to speed, please comment here and let me know!

I’ve recorded another screencast of the Ringside Social Payment service that demonstrates the use of a multi-friend selector when making social payments.  There is an interesting lead-in to what will eventually be part 4 in this series…the multi-network multi-friend selector.  For details, watch the video here or click the image below.

As we at Ringside build out our administrator dashboard, I’ve been working on a feed retrieval API and a new social tag for feeds.  When developing applications for Facebook, the application can only publish feed entries via the Facebook API, but there is no way to retrieve those feed entries.  The Ringside feed tag will enable just such a capability, as well as the ability to import RSS feeds from anywhere online.  Here’s how:

<rs:feed-aggregator display="byDateTime">

</rs:feed-aggregator>


This example is slightly complicated, so I’ll break it down piece by piece. The first thing to note is the feed-aggregator tag. This tag aggregates feed entries for all of its contained feed tags, and displays them according to the value of the display attribute. Currently, feed entries can be displayed by date and time or by tag.

Next you’ll notice that the feed tag can be used in different ways. The first feed tag in the example reads from the social network’s database and is controlled by the attributes specified.  The feed tag will retrieve feed entries relative to the id of the specified user.  Alternatively, the ‘actorid’ attribute can be specified for feeds that are relative to pages or applications.  If the ‘friends’ attribute is true, only the entries by the user’s friends will be displayed.  The Facebook API enables the publication of actions and stories, and those attributes determine whether the feed tag should retrieve actions, stories, or both.

The second feed tag in the example is what you would think it is for - reading and displaying RSS feeds.  The feed tag will retrieve the latest feed entries from the specified URL and display them according to the display attribute, which is not shown in this example since the feed-aggregator tag will do all rendering according to its display attribute.

This should be pretty exciting for social application developers, since integrating RSS feeds and social network feeds into their applications will become very easy.

These tags are currently under development, so if you have ideas to make them even better, please share your thoughts via a comment below.

I don’t pretend to know what the future of the Social Web holds, but I have some ideas about the markup language that will power much of it.  First though, let me recap the short history of Social Web Markup.

About a year ago Facebook launched their social network with a full application platform consisting of a rich set of social APIs, many of which were wrapped with easy to use tags called FBML (FaceBook Markup Language).  Since then, a few things have happened.  First, Bebo opened up their social network with their own markup language which they called SNML (Social Network Markup Language), which was mostly the same as the FBML collection, though it included some tags only offerred by the Bebo platform.  Finally, Ringside Networks released beta versions of their Social Application Server, which supported many of the FBML tags, and a few only available on the Ringside Platform.

This is all well and good, since tag libraries for specific social networks definitely enable social application developers and designers to create rich social applications quickly.  What is unfortunate about the current situation is that these tag libraries are closed in that they are only supported by the platforms that offer them (though the open source Ringside Social Application Server supports many FBML tags).  This means that social application developers would have to rewrite portions of their applications in order to deploy to multiple social networks.  I’m reminded of the early days of the J2EE application server market, when each vendor offered their own tag libraries in an effort to differentiate their platforms from each other.  In the end though, most of those tag libraries did many of the same things via different syntax, and ultimately JSR-52 was established and the JSTL (JavaServer Pages Standard Tag Library) was produced. Now all J2EE application server vendors support JSTL.

I don’t necessarily see the same course of events unfolding in the social web space, but perhaps there will be some similarities.  First of all, I’m inclined to believe that social application developers will want to be able to write a social application once and run it anywhere. In order for that to happen, those developers would have to code using standard APIs and tags, which is an argument for a standard for a social tag library.  Alternatively, because Ringside offers the ability to render social tags via widgets, I can see a whole community emerging around social tag development, which would in turn enable the rendering of those tags via widgets anywhere across the web.

What do you think?  Are you a social application developer?  Do you want to be able to write once and run anywhere?  If so, how do you see social tags evolving?

Rich Friedman recently discussed the architecture of the Ringside Social Application Server with some new members of the Ringside development team.  Watch the video below to see where Ringside started from an architectural perspective, and where the architecture is today.

Online Video provided by Ustream

Last week Jonathan Otto, author of the Run Voomaxer Facebook application, and Eric Pascarello, highly acclaimed author of AJAX In Action and JavaScript: Your Visual Blueprint for Building Dynamic Web Pages, joined the Ringside team and participated in some great discussions with the team.  In one of those discussions, Rich Friedman gave an overview of various open source licenses and what they mean, including GPL, LGPL, BSD, and others.

Free video streaming by Ustream

If you’ve ever spent too much time on Facebook, you may be familiar with the ability to declare yourself a fan of a page. For example, I’m a fan of the Philadelphia Eagles on Facebook (see below).

Wouldn’t it be interesting though, to enable people to declare that they are “not a fan” of a page. For example, as an Eagles fan, it would warm my heart to declare myself “not a fan” of the Dallas Cowboys. Such an action enables users to further define their social identities.

This doesn’t seem all that important on the surface, but let’s take a minute to think about a case that may be important to a business. Let’s say that I own a golf course and that I created a page on Facebook for this golf course of mine. Currently, I can see those users that are “fans” of my golf course, but I have no visibility regarding those users who are not fans. Wouldn’t it be great if I could learn about what people don’t like about my golf course via Facebook? Perhaps users could enter comments when they declare themselves “not a fan”. As the owner of the golf course, I could take corrective action based on what I learn from those comments.

Let’s face it, people like to complain. Why not enable businesses to learn from it? I’ve created a new feature request for such a capability to be built in the Ringside Social Application Server (see JIRA item). What do you think? As a Facebook user? As a business owner? As a brand manager?

Last week I started fiddling with UStream. At first it was just a cool new technology that I was trying out, but it has evolved into a daily part of our lives at Ringside Networks. We’ve been streaming live video for about a week, which has been working out very well. For those team members that are remote (we have 3-4 depending on the day), they have been privy to the office conversation that they have always missed. Since we started streaming, those remote teammates have been clamoring for better cameras, and more of them.

You can view our live stream here. Note that there are portions of the day that are very boring. For example, at the moment, anyone that is tuned in will be watching my face as I type this blog entry and listening to Weezer. However, Twitter is a great tool for notifications. Whenever an interesting discussion is going on, I’ve made a habit of turning the camera outward towards my colleagues and the white board and logging a message on twitter with a link to our live audio/video stream. Follow me on Twitter if you’d like to get these updates.

The most interesting part of our use of this technology is that it pairs nicely with our open source development model. For those developers out there using our software, they can watch and listen while we discuss how to resolve a bug, how we will prioritize our work for the next beta release (every two weeks), or just get a feel for where we stand on a daily basis (our daily stand up meetings are at 2:30pm EST). Even better than watching live though, is that the community will have the ability to participate through the chat window in the UStream interface. For our remote team members, we’ve been using Skype to bring them into the live discussion. As users of our software, you could potentially have the same level of access.

To me, live streaming takes open source development to the next level of openness and provides an engaging experience that will ultimately result in better software and faster solution delivery due to the availability of this rich communication medium.

By the way, we also tried Stickam for a day, which offers group video chat capabilities. Our experience has been that Stickam’s availability is not as good as UStream’s. Also, Stickam’s user interface wasn’t very intuitive or descriptive. We have tried on two separate occasions to coordinate three video streams in the same session without success. Regardless, this service has great potential, and I look forward to improvements that are surely coming.