AmazonCamp Roundup

This roundup is a couple of weeks overdue – life’s been a bit hectic round these parts between work and the new kid so blogging got a bit back-burned so, from the “Better Late Than Never” file:

For something that started out as a “I wonder if anyone would be interested…” AmazonCamp sure blossomed into a fun evening that seemed to provide a lot of value to everyone who attended. Heck, at the end of the night I practically had to drag people out (I did have to turn out ALL the lights) of Indoor Playground so we could move onto a local bar for some drinks – I’ll take that as a good sign that people were engaged.

After I threw out the idea I touched base with Amazon evangelist, Mike Culver, just to make sure I wasn’t duplicating the effort of anyone else locally. He turned me on to Reuven Cohen of Enomaly who was working with a couple of people to try and get a local AWS user group up and running.

The night quickly became an AmazonCamp/AWS User Group kick-off evening and Mike graciously offered to come up and talk to the group as well.

The Presentation
Mike gave a quick talk to lay out the groundwork for Amazon and what each of it’s AWS services are. He then provided some examples of apps he’d seen or heard of that really took advantage of Amazon’s services.

Sworn to secrecy (or as he put it pro-actively ignorant) about what’s coming down the pipes there wasn’t a tonne of net-new information to be gleamed from the presentation but he did everyone on to some very interesting use-cases of each of the AWS applications (at least the one’s we can use from up here in Canada).

The Demos

Following Mike’s presentation we flipped into a more DemoCamp style portion of the evening. We had five companies talk about what they were doing with AWS.

Justin Giancola, Freshbooks
Justin talked about their work with Amazon’s Flexible Payment Service. Sadly not something we can really play with here in Canada yet but certainly some very interesting opportunities arise out of the service.

Me & Dave Rapin, Clay Tablet Technologies
Dave and I dug into how we’re leveraging AWS for a SaaS/hosted license version 2.0 of the Clay Tablet product. We’re leveraging EC2, SQS & S3 to make it all happen and our architecture allows us to quickly ramp new servers up (and subsequently take them down) to handle heavy loads of content etc.

Kevin Thomason & Ilya Grigorik , AideRSS
Kevin & Ilya covered their experiences in developing AideRSS on the Amazon platform and how it basically saved them a lot of money (and face) when usage exploded on launch day. Amazon allowed them to ramp from 10 to 30 and ultimately 100 server instances in a 24 hour period.

Chris Thiessen,
I’d seen Chris demo Zoomi at a DemoCamp a few months ago and asked him to come out. Chris has built a unique online bookstore that basically pushes the limits of the AWS services in just about every way possible. A very cool idea that should be launching soon check out his site to signup for the BETA.

Reuven Cohen, Enomaly
Reuven has a long history with the AWS guys and co-organized the event for me. He got up and talked a bit about the various services and products that they’ve built to complement AWS.

All in all the night seemed to be a big hit – we followed the formal part of the evening with some drinks at a local bar. Despite plying Mike with pitchers of beer we were unable to pry any Amazon secrets out of him ;) – To his credit though he really was interested in digging deeper into what all of us were doing and what we were looking for from AWS down the road (Reminder: Bulk Account Management please! :) ).

Looking forward to getting another AmazonCamp together in the new year.

Of Standards and Methodologies: Defining best practices for the LSP

Back at Localization World Berlin I sat in on a session at during GALA‘s pre-conference day. The conversation, somewhat to the surprise of myself and some other product vendors in the room, wasn’t about technical standards but rather about trying to establish standards for LSP’s. These standards were in the context of operating procedures (tasks, process etc.) and at times got down to specific metrics or formats (quality measurement, fuzzy matches, etc.)

“Standard” is a funny word. To techies it often creates a sense of relief (if it’s actually been adopted) but to business operators like LSPs it can create a real sense of panic. During the meeting I noticed more than a couple people who clearly heard the word standard, had it used in the context of defining how they run their business and it was all they could do not to run screaming from the room.

At first I thought I was just going to end up zoning out for the two hours as the topic only had tangential interest for me but a few minutes in the conversation the discussion seemed to be stalling/circling a bit and, well, I’m the kind of guy who likes to jump into discussions with both feet just for the hell of it – so I chimed in.

My Concerns
My big concerns out of the gate were twofold:

  1. No specific focus
    The conversation was jumping from the 100,000 foot “Let’s examine and define our processes” right down to the 10 foot “how do we standardize fuzzy matches?” debate. To be successful the end result/goal needs to be clearly defined and those pushing it forward need to buy in. The reality is there are no wrong answers here but there needs to be one answer.
  2. The word “Standard”
    As I mentioned above the word Standard can freak people out. In this case I’m also not so sure it applied to the highest level view of what the group appears to be trying to accomplish. Subconsciously it probably sounds a lot better to say you’re working on establishing a “standard” rather than creating a “methodology” but there’s a lot of baggage that goes along with the word.

At some point in the discussion I suggested that perhaps “Standard” wasn’t the right word and perhaps “Methodology” or “Best Practices” were more appropriate. Initially I got the sentiment that folks were happy lumping them together under the same umbrella but eventually even Don DePalma suggested we get a jar and every time someone said the word standard they’d have to throw a Euro in it .

Lumping them together didn’t sit well with me at the meeting but I rolled with it. Upon reflection I think it actually does the process a disservice. While Standard, Best Practices and Methodologies all fall into the same, very broad group, I think they each speak to very different levels of definition.

Hierarchy of Business Practices
I’d like to step back for a second and layout how I view all of the different levels that come into play when trying to define a business model or process. Starting from the highest level, 100,000ft strategic view right down to the 10ft tactical level.

While the notions of Best Practices, Methodologies and Processes are separated by fairly fuzzy lines I thing there is still a sense of hierarchy between them:


  • Best Practices:
    These establish the baseline expectation anyone should have of a Language Service Provider. They state what an LSP (or internal language department) should and should not perform as part of their business process. For example, best practices may dictate that an LSP has a Quality Assurance Methodology but not necessarily detail what steps that involves.
  • Methodologies:
    A Methodology covers a group of processes that an LSP will utilize to achieve a specific goal. A Methodology will detail what processes should be under taken to ensure they are putting out the highest quality translation. For example, the QA Methodology may dictate that each document must be peer reviewed and a client in-country review should take place. Again, in this case it won’t necessarily dictate what exact steps must be taken by each resource, just that they need to be involved and follow the prescribed review process.
  • Process:
    These are the isolated processes that combine to make a methodology. Processes will generally reference a specific cluster of tasks related to a specific competency. i.e. “Project Intake”, “File Preparation”, “Translation”, “File Review”, etc.
  • Tasks/Standards:
    Finally at the very base we have tasks and standards. These are essentially the building blocks of the entire system. These are the individual steps that a person must perform or a standard that elements of the project must conform to. Standards could be technical (XLIFF, TMX) or material (Standard for defining fuzzy matches).

It’s also important to note that components such as methodologies, processes and tasks/standards do not have to have exclusive relationships with the adjacent tiers. A Quality Assurance process may be reused in a variety of methodologies within an organization. And at the lowest-level standards and tasks will likely be reused numerous times across a business.

So Where to Start?

The toughest challenge is always, “Where to start?” – and this is where I think the conversation largely got stalled in Berlin. We were flipping back and forth between notions of Best Practices/ Methodologies & tasks/standards. Again, neither answer is wrong, but you need to pick one and roll with it.

At the end of the day, regardless of what level you start at the outcome has to approachable, attainable and agreeable (AAA) to the people who you want to have adopt it, in this case the LSPs.

If you start at the bottom then it’s important to pick a narrow, defined niche and explicitly define the task or standard. If it meets the AAA measure you should have no trouble getting organizations to adopt it, especially if it’s merely defining something they already do. People love to be able to say they comply with something.

My personal approach though would be to start at the very top. Define the broad best practices – by doing this you create the buckets that you will need to back fill with methodologies. Processes, tasks and standards. As an industry body GALA can, over time, begin to roll out sanctioned methodologies & standards but by defining a broad best practice it gives everyone a chance to contribute.

If GALA were to bring to market the “GALA Best Practices for Translation Service Providers” they could outline the methodologies and processes that a client should expect their translation provider to have adopted. These best practices should outline that the translator has a clear and stated policy with respect to fuzzy matches, a methodology for identifying and assigning ‘best fit’ resources to projects, a clear and stated policy on translation memory ownership, a defined Quality Assurance process, and so on.

By identifying these best practices GALA would have created a plan from which to build out all of the necessary methodologies, processes, standards & tasks. And best of all, as organizations begin to adopt these best practices they will in turn start to creat
e their own methodologies etc., as those get shared back into the community they can help shape and define the GALA standard. Additionally, a Bet Practices standard gives member companies something they can achieve without (potentially) having to radically alter how they do business – which makes it far more approachable.

These are just my thoughts on the issue – I hope the conversation continues as it is really worth having and I think, over time, could contribute greatly to the business of all GALA members.

BarCampTorontoTechWeek – Belated recap…

BarCampTTW - DSC08228

Well, BarCampTTW has come and gone. As the unofficial kickoff to Toronto Tech Week, I’d have to say BarCampTTW was a rousing success.

Based on the show of hands we had a pretty diverse crowd where almost 50% of the participants were first time BarCampers. Also a good sign was the number of women we had come out – while numbers are still in the teens they represented about a quarter of the attendees. In recent month’s there’s been lots of discussion in both the conference and unconference spaces around the lack of female representation so it’s good to see that some improvement is being made but we’ve still got a ways to go.

All in all the sessions were quite interesting and I found this camp definitely slanted more to the conceptual and ideas rather than pure tech which was interesting. I was talking with some folks at the post-camp drinks and realized that I’ve started to look at BarCamp as the generalist platform/entry point into the community that we use to launch niche interest groups/events from (DemoCamp, VizThink, InteractionCamp, TransitCamp, EnterpriseCamp etc.) . It truly has no agenda or theme out of the gate and, true to form, is entirely whatever the participants make of it. It’ll be interesting to see how the nature of the event changes as we continue to reach out and try and bring new members into the community.

Photos from the event can be found here. Blog posts from the event can be found here & here.

Along with my fellow organizers (Will Pate, Mark Kuznicki, Bryce Johnson and Dan Kurtz), I’d also like to thank our sponsors for this past camp:

Microsoft Canada
Hyndman Law
University of Toronto: Faculty of Information Studies

It’s through supporters like the organizations above that we’re able to put on these great events and keep the price of admittance your time and a willingness to participate.

Check out the TorCamp page to see what events are coming up (VizThink3 is June 14th). If you’re not from Toronto, the BarCamp community is a truly global phenomenon – check out the BarCamp site to see what is going on in your neck of the woods (or see how to start something up).