On January 8th 2008, I gave the main presentation at TSOT's Ruby / Rails Presentation night. In it, I announced my new company Shindig and Shindig's first product, the S.O.S. Here is the first part of the presentation, with slides and more-or-less what I said. The presentation was in two parts: business and technical. This is the 'business' part. The technical part will be covered in future posts.
Hi, my name is Andrew Burke. I've been a freelance application developer for over ten years or so. I started doing web pages back in the 90s and then moved to Lotus Notes, worked at a consulting firm in the states for a few years, and then came back to Toronto to go back to freelance work. I moved to Java around 2000/2001, and have also done some PHP on the side. I got into Rails in mid-2005 and have been working as exclusively as possible in Rails since then.
Tonight I want to talk to you about a project I've been working on for the last year or so, called the S.O.S., or Store Ordering System. One of the things I like about going to events like this and DemoCamp is the opportunity to see what other people are doing, and what kinds of software is out there. I generally work alone, or as the sole 'computer guy' in a company - so it's always great to learn new things, and see what other people are wrestling with.
The S.O.S. is business-to-business software - specific software for a specific business niche. Since this is the first of the Presentation Nights, I'm not sure who is in the audience, and what kind of work you do - knowing Toronto and Rails, I'm guessing it's more of a consumer venture and design crowd - so I'm going to give a quick overview of what software is like in the business world.
On an airplane over the holidays, I was watching that new BBC series, 'Planet Earth' - and while watching the 'Oceans' episode, I realized that there is a biosphere of software in the corporate world.
At the top of the biosphere are the whales: giant, slow-moving, expensive, resource-intensive software. Enterprise Resource Planning systems like S.A.P., or custom-built solutions by large firms like IBM Global Services and Accenture. These have entire departments or sub-companies devoted to building and running them. On the one hand, these are so large and expensive - and the approval and buy-in has to be done by such senior-level staff (VP, CIO, CEO) - that their momentum carries them forward regardless of whether they actually work or not (this is the kind of software where the consultants who made the original bad system are 'punished' with a $25-milllion maintenance contract, since they're the only ones with the knowledge of how to work with the system.) On the other hand, when these are done right, they are the key to staying competitive for places like Dell, Wal-Mart, etc.
At the far other end of the scale are the little creatures: Phytoplankton, blue-green algae, cyanobacteria, krill. They're small and simple, but they constitute something like one fifth of the biomass of the entire earth. The equivalent to this in the business software world is ... spreadsheets and email. Spreadsheets were the original killer app for getting microcomputers into offices - it started with VisiCalc on the Apple II. It's still the most commonly used business software. It's simple, flexible, provides a combination of database and word-processing features with calculations and graphics. Everyone from interns up to the CEO can quickly slap together a spreadsheet to reflect some kind of business situation - and if they want to 'collaborate' they can attach it to an email. Wikis, intranets, groupware, all of that is a minor distraction from what really gets work done in the business world: email.
By the way, wouldn't it be great if someone could figure out how to turn spreadsheets and email into real applications? Well, it's called Lotus Notes, and it didn't quite work as cleanly as expected.
In between these two scales are the fish - custom-built applications. There are lots of them and they come in many different shapes and sizes. Some of these are built internally by I.T. departments in larger companies, some are built by high-end consulting firms, some are built by smaller firms or independent developers (like me), and many are built by a middle-manager who thinks he's a programmer, or the CEO's nephew who just learned Visual Basic or PHP.
These kinds of applications are an expensive roll of the dice. When people talk about how most I.T. projects fail, these are the projects that they're talking about. A company could easily spend five or six figures and take months or years to build one of these applications, and it may not work, or not meet the business requirements, or do neither.
What's happened in the last few years with the spread of the web and the rise of fast and flexible languages and frameworks like Ruby and Rails, is commercial web-based business apps. These are like dolphins: it's a marine mammal like a whale, but it's smaller and more nimble; it's quite a bit like a fish, but smarter and more capable. Many business functions are similar across different companies, and so they don't need expensive customized solutions. There is already a market for the obvious big things, like CRM and Human Resources - but since these apps can be built by small companies or individuals, they can focus on smaller and underserved niches.
One of the great advantages with this new kind of software is the low level of commitment required from customers. The applications can be built by small teams or even individuals, so they don't cost as much - even less if the production cost can be spread among multiple companies. Since they're web-based applications, you don't need to buy and maintain server hardware or install flaky client applications on your staff machines. Many of these applications are sold on a subscription model - if you don't like the software and stop using it, just stop spending the monthly fee. Because the costs are low and there are no in-house hardware requirements, the decision to start using these applications can stay at a department manager's level or below and it can be set up almost instantly - instead of the years it might take for a CEO or CIO to decide on a big piece of infrastructure. This means that sales and customer relationships is more about good looking web sites and functional software rather than lots of business lunches and golf games.
So, I'm starting a company to produce this kind of software. It's called Shindig - or more exactly, "Shindig Digital Constructions Inc." I'll still be doing dev work for people while things get off the ground, but the main focus is going to be hosting, selling, and managing web applications.
The web site is still getting polished up, but when it's ready, it'll be at www.shindigital.com. The company has a logo and working software that people are already using, but doesn't really have a polished website yet. This puts us ahead of a lot of Web 2.0 companies, that have a logo, a slick website, but no working software!
Shindig's first application is called S.O.S. - the Store Ordering System. It helps manage signage programs, generally for retail operations.
The S.O.S. helps manage signage programs, including production, fulfillment, inventory, shipping, and catalogue management. I'm guessing that there aren't that many people in the audience who are really interested in the nuances of signage fulfillment, so I'm going to skim over the actual functionality and focus on where the application fits in the sign business. If you're really interested in how all of this works, drop me a line and we can talk later.
The sign industry has a few quirks. A lot of the big money is in large retail operations, such as HMV, The Beer Store, Winners, etc - these are large companies with hundreds of locations and a national or sometimes international scope, and they like to have standardized signage programs that they can use in all of their locations. However, the sign making industry consists of a lot of small and medium local producers. If you've ever had to get business cards printed (I'm just starting a company - I'm dealing with that right now) you'll know that a city like Toronto has dozens if not hundreds of printing places, from Kinko's and two people with a laser printer in their garage to much larger shops with back warehouses full of large loud machines. The sign industry is like that, too. Every city or town has an entire ecosystem of custom woodworkers, graphic artists, large-format printers, metal and plastic cutters, project managers, brokers, installers, electricians, lighting specialists, etc. Figuring out who makes what and where can be a full-time job.
This problem is made worse by how the retail companies tend to view signage. Most of these companies have whole divisions and heavy I.T. infrastructure devoted to getting their retail product (DVDs, clothes, beer, etc.) from their suppliers to a network of warehouses and out to their hundreds of retail operations across the country or world. However, if someone drives their fist (or car!) through the front window of one of their shops (if you have 400+ locations, this can happen somewhere as often as once a week) and new 'we take VISA and here are our opening hours' window decals need to be reordered ASAP, this is usually assigned to the already-overworked 'promotions coordinator' at head office.
Actual product is the key revenue source for these companies, and there can be millions of dollars worth of it on the road at any given time. On the other hand, replacing broken or worn signs, or making sure a new location has all of the display elements it needs, is a cost, and not a very big one for these kinds of companies. However, signs still need to be made, shipped, and installed quickly and accurately.
What usually happens is that this already overworked office employee has to collate faxes, emails, and phone calls from the various store managers, and then coordinate with warehouse staff to see if any replacements are still in stock somewhere, and a network of producers if new stuff needs to be made, and then track the production, shipping, and installation of these things - usually by building a lot of complicated spreadsheets and emailing them around.
The Store Ordering System is designed to make this person's job a lot easier.
I'm going to give a quick demo of what the S.O.S. does - but since this is the TSOT Ruby/Rails Presentation night, I want to make a quick digression on Ruby and Rails. The S.O.S. is built entirely in Ruby on Rails (with PostgreSQL underneath, if you want to know). While commercial applications like Twitter have a large volume of small simple elements and relatively simple logic, business applications like the S.O.S. have smaller user volume, but more complicated objects and logic. The elegance and cleanness of Ruby and Rails really help manage this complexity, and make the application code much easier to write, read, and maintain.
(I then gave a quick demo of some parts of the S.O.S. and discussed some programming techniques that I've found useful in building the application. More detailed descriptions of the S.O.S. will be appearing on this site soon, and I'll be covering the programming techniques in the next few blog posts.)