Oxymoron?  Could be, but all too real in the world of software start-ups in my opinion.  The following is a short story providing some lessons learned to software developers interested in starting up their own company.  Why?  I wish I had this advice when I started my own company in 2001, but it seemed difficult to find any material, specifically targeted for software developers that think they have a good product idea and want to bring it to market.

 

First let’s talk about product success.  My team and I created a product called Bridgewerx that used BizTalk Server as its integration engine.  BizTalk Server is a middleware product from Microsoft.  Whether you call it an Enterprise Service Bus or Internet Service Bus or Internet Data Router (which we called our product back in 2002 when no such term existed) or a SOA “type” product, or delivered as an SaaS or packaged as an Integration Appliance or… really does not matter cause these are mostly marketing words that basically mean the same thing:  loosely-coupled, message-based application integration server.  Purists will disagree, but I can make BizTalk meet any of these terms.

 

A saying is practice makes perfect.  When you perform similar tasks over and over again, generally speaking, you get good at it.  As a Systems Integrator, we designed and delivered over 30 application integration solutions to our customers over a 4 year time span.  We thought we were pretty smart about it, generalizing components and reusing them for the next job.  In fact we got so “practiced” that we were more or less assembling reusable components and the only customizations were customer specific adapters, business rules, schemas and maps. Regardless of the type of application integration work we did, these patterns occurred every time.  We became experts at developing BizTalk solutions using several design patterns and practices we had discovered and refined over this 4 year time period.

 

Then we thought, we could turn this into a product.  We could take our design patterns, best practices and embody them into a graphical design time tool that allows Business Analysts to specify application integrations.  The tool would capture all of the data (and metadata) necessary to fully describe an application integration scenario (even complicated ones).  The output of the designer tool would populate and configure a Visual Studio solution with several projects that contained source artifacts from our library of reusable components, (e.g. Orchestration patterns similar to C# generics, runtime message envelope, utilities, etc.), plus user defined schemas, maps, business rules and even custom assemblies.

 

Through scripting, we automated the build and packaging process so the final deliverable was a MSI that a customer could install on their target infrastructure, run the installer and voila, a completed application integration project, now ready for operation.

 

Anyone that has been involved in any size application integration project knows how difficult it is.  We called ourselves plumbers because it was a dirty and complicated job.  Application integration inherently deals mostly with distributed systems, not just a single application, therefore complexity goes up, along with the myriad of file formats per application integration.  If you have been there, you know what I am talking about.

 

So what?  Well, our product code generates “complete” application integration solutions from a design time tool output specification.  That’s the one sentence description.  This means the amount of highly skilled, intensive manual labor effort in designing and coding the solution is dramatically reduced.  At least by a factor of 10X, in some cases by 100X, and in the extreme cases where you are talking about very large scale application integration with +100 points of integration, it is not even feasible using traditional (i.e. manual labor) techniques.

 

We believe this to mean product success.  It successfully answers a difficult problem in our software development world in the domain of application integrations.  It provides at least a 10X improvement over current methods and tools. 

 

If you want to read more about the design of the product, you can click on the Bridgewerx category on the right side of my blog.  If you want to see a one hour movie demonstrating Bridgewerx, sponsored by Microsoft (thanks Jim!), you can see it here.  Finally, if you want to see a live demo, contact me at my email address at the bottom of the page.

 

Forrester research says that “Application Integration is the top priority for 2007.”  So we should be all set for business success, yes?  No.

 

Business failure.  As the President of the company for 4 years, a co-founder and co-creator of the product, I failed to realize the vision I had for my business.  Why?  It was not just one reason, but there were a few factors that occurred at key milestones in our company operations that really broke our company (figuratively and literally). 

 

One mistake I made was not getting the right people aboard our company to help us from a business perspective.  Involving business partners/advisors in a highly advanced technology business who have (very) limited understanding of software development and the target market is problematic.  Or even worse, business partners/advisors that were successful in the software business with one type of product and applying the same principles to a product and market that is completely different is disastrous, as was the case in my company.

 

My business partners had backgrounds in “traditional” software business/marketing, i.e. put the product in the sales channel and build up a base of customers.  On the surface this makes sense and were going with what they know.  However, our product, using terminology from Geoffery Moore’s, "Crossing the Chasm”, was an innovative and disruptive product that required very early adopters.  And from my perspective, once we had half dozen early adopters, the play was to sell our IP to a much larger player that could integrate our innovation into their product.  In our case, one play was to sell directly to Microsoft and have the innovation built into BizTalk Server.  Hard to believe no effort was to put into this when the company was operational.  Another play was to sell to a much larger System Integrator, like Avanade, who perform large scale application integrations, to give them a competitive advantage.  Yet another exit strategy was to take the innovation and apply it to another middleware or SOA product.  Based on my latest research, it appears we still have a market advantage of being the only vendor to code generate “complete” application integration solutions from a design time tool output specification.  Technically speaking, using Microsoft terminology, our design time tool is a graphical Domain Specific Language (DSL) and our code generation system is a Software Factory.  Innovative and disruptive?  Yes.  Easily understood?  No.

 

Lesson #1  Make sure your business partners and advisors fully understand your products marketplace and value proposition, especially if it is an innovative, disruptive product.

 

That was my vision and intent.  However, dear fellow software developers looking to bring your product to market, I made one fatal mistake.  I lost control of my company through share dilution.  In order to acquire the people that could realize the vision I had, required giving up shares as, of course, there was little money to pay large salaries.  Or at least so I thought.  Once you lose your controlling interest in the company, well, you know, other people take advantage of this for their own self interest and the companies vision and product changes direction, and not necessarily for the better.

 

Lesson #2  Keep a controlling interest in your own software company at all costs.

 

Another mistake I made was not keeping the professional services division of the company running to bring in cash flow.  It seems obvious enough that you cannot turn an SI into an ISV overnight.  But this was lost on me and my business partners/advisors, who were pushing just to raise capital.  We could have also acquired another professional services company that was similar to ours (Hi Mike and Jame!) to not only bring in additional pro services dollars, but also prime the pump for existing customers that may be interested in trying our innovation out. This would have reduced the dilution of our company before we even got started.  Unfortunately, our advisory board and other business executives did not understand this and was an opportunity missed and may have been the tipping point looking back in hindsight.

 

Lesson #3  Find alternate methods of funding, particularly if you are an SI that already has a revenue channel.

 

Speaking of funding, if you need to raise funds, ensure that you can raise enough.  Research shows that to fully capitalize a product as a SaaS requires $35 million to be raised over 5 to 7 years.  Here in the Great White North, we were able to raise $5 million tops.  If this were a car race, we did not even have a chance to qualify, let alone participate in the actual race.

 

Lesson #4  If you need to raise capital make sure you can raise enough.

 

Followed closely by:

 

Lesson #5  Ensure the people that are raising the money actually have a track record of raising that kind of money.

 

I know it sounds simple enough, but at the time…  At the time there was lots of bravado and speculation, which on the bottom line means absolutely nothing.  

 

The final lesson I have yet to figure out.  Based on my market research, our company has a product innovation that does something no other product does in our market space of application integration.  Market research shows that application integration is a top priority for 2007.  What up?  My guess is that we are yet another company that has fallen into the Chasm.

 

On a personal note, my hope is that in this short story provides a few tidbits of advice (and a little bit of hard earned wisdom) that other budding software development entrepreneurs will find useful, which is the reason I wrote this in the first place.  Secondly, am I bitter?  No, it was one of the most exciting and exhilarating business adventure that I have been on , Would I do it again, absolutely! Of course I would do it differently, no regrets.

 

For software developers wanting to unshackle themselves from the security blanket of the day job to develop their idea, vision, product.  If you can’t stop thinking about it… Carpe diem baby!