I actually learnt what software architecture means something like 9 months – when Jean-Sébastien and Pierre discussed the architecture of CartoReso and I was listening, eyes wide opened not understanding the slightest bit of what was going on. However, it didn’t take long for me to realize how crucial designing a smart and robust architecture is in making the implementation of a software product strategy successful though.

This being said, there’s a number of things one should know when it comes to software architecture design applied to an entrepreneurial context. I acknowledge I’m brand new to this domain, but software architecture has been the one thing I’ve been focusing on in the last 4 months: the sun could rise without me having read at least a few pages on the topic. So, here are my 11 non-technical takeaways. There you go:

1. Think strategy, not technology. Strange? Maybe. The goal of software architecture is to embed you strategy into your product. Keep that in mind. And keep strategic analysis informal: week-long brainstorms between founders will perfectly do. Keeping the strategic analysis informal shouldn’t prevent you from going the extra mile digging deep though. Be tough-as-nails, cold-blooded and if necessary, surround yourself with razor-sharp, nit picky colleagues that will pinpoint what deserves to be pinpointed
2. Think intellectual property, especially if you’re small and weak. You don’t want the big guys to steal from you. Ooosh, I was almost forgetting. See this pizza-and-coke Linux guy in your team unwilling to think of patents as anything else than evil? Yeah, I know, he’s smart, nope, very smart and you don’t want to argue with him. But fight him with words until he understands intellectual property is key in a knowledge warfare industry where some countries (like China) are more equal than others when it comes to IP. The guy’s smart so it will take a lot less time than you expect as of now.
3. Think interface and user experience first, also called Think take your time. Don’t start coding from day one. What you should do is draw the screens of your applications. Each screen. With all the buttons, everything. Think of the human – machine interface first. Paradoxically, the longer you’ll wait, the faster you’ll get it done. Procrastinate. Do actually your best in procrastinating. You’d better walk slow in the right direction than run fast in a dead end. Unfortunately, true geeks can’t help coding. So refrain them from doing so by all means – including, if necessary, use violence and blackmail their families.
4. Think world-class engineers, or don’t think – or even think of thinking ever. Pick up the best – and trust me that’s easier to say than do. One smart develop does the work of ten lame programmers so do it, whatever it takes. And give out stock options, be generous about it: startup developers jump from one failed startup to another. Finding for once a good horse to ride is a rare, unique opportunity to make a home run and stop worrying about money for a while. These guys are the ones who deserve it most.
5. Think division of labour. Software architecture helps you parallelize the work load between developers to make all different groups working on all different parts finish on the same date. Believe me, there’s nothing more beautiful than assembling parts of code processed by different brains, clicking on ‘compile’, and see it run. However, do not believe you can then take a nap: the hardest thing in software isn’t to have a program that compiles properly. I would tend to say the hardest bit lies in packaging your software (never did it so I should just stop here). You’ll come up first with a broad drawing of the different software layers depending on the number of floors of your software (eg data / infrastructure; application; presentation – the SOA trend tends to divide the application layer into two, technical and a functional, subcomponents) – which ease work breakdown structuring. For instance, those with some good taste (or the least bad taste) will deal with the interface, others with the client side, the remaining ones will work on the server side. As an example, in CartoReso, Jean-Sébastien dealt with lower layers hacked in C (he was the most knowledgeable in NMap, the open source brick on which we decided to build on), Pierre with the application engine and with integration / build / project management (since he was in charge of the middle layer) and my humble self with the interface. But a broad drawing isn’t enough. You may then decide to fine tune your architecture and delve into the details of each layer. This work is necessary when dealing with large software development teams: regression risk finds itself lowered when everyone knows what it has to do and each method is clearly owned by a lead someone.
6. Think flexibility. Lay the groundwork for future evolutions: you’re not building a software for today or even tomorrow. Think long term. A fashionable way of implementing flexible architectures is to go for modularity – like Dassault Systems does: you don’t acquire one standard piece of software, you just build your own DS software by picking the modules you need in their catalog. Interestingly enough, Dassault Systems‘ pricing catalog follows the way the architecture was thought, hence creating a perfect alignment between marketing and engineering which I believe is an industry best practice. Why? Well, Dassault Systems happens to fulfill the dream of all software vendors: it sells generic software that matches specific needs.
7. Think lock-in. The new release of Firefox sucks: it crashes thrice a day and every time I try to download something. so I’ve decided to drop it for Safari on my Vista Mac at home and IE7 on my Vista laptop at work. But I find it REALLY hard, as I loved these little del.icio.us taggers or icons to subscribe to RSS readers embedded in the URL bar. Firefox has achieved to lock me in (well, not quite, but so far it did): the number of available plug ins prevent me from dropping Firefox until I find a solution (FYI, there exists IE7 plugins on windowsmarketplace.com). Lock-in has long been the one major issue with Google: it is now solved since Google login eases access to other Google web applications via Ajax menus. The powerful lock-in strategy execution usually reflects the value of the underlying platform – and the value of a platform equals the value of its ecosystem.
8. Think proprietary control of a widespread standard Look at Adobe Acrobat’s .pdf format, or Microsoft Office applications (used to be .doc, .ppt and .xls, and now, with Open XML, it’s .docx, .pptx, and .xlsx). Once you’ve set the standard, the value of your software increases dramatically because it takes long for an installed base to migrate to a new standard. This simple phenomenon is called inertia. The hardest bit here is to become the standard. Which can be achievved running faster than everyone and remain in stealth mode (invisible from the big ones) as long as possible. Easier said than done.
9. Think competition. Don’t mess with large corporations. If they are after you before you’ve proved your architecture is hard to replicate, they’ll make an announcement stating they’re soon to release a similar software, which will slower sales for your software, and come up, probably a little late, with something similar and sell at a loss, which will inevitably kill you. If your architecture is strong, elegant and patented, then the big one will realize it costs a lot to replicate (developers, patent breaking risk, time frame, etc.) and will think of acquiring either you or one of your competitors. This is how big corporations now innovate and trust me, software architecture audits aren’t piece of cake. Should they choose to acquire a serious competitor, sell your company before you get to die. Indeed, once the big one has the same product as you do and i) you’re alone, independent and weak; ii) you haven’t set the standard yet, the usual path followed to reap you off the map is that it will sell a similar product to yours for cheap, probably at a loss, if not for free – and the only thing you can do to compete is do the same too. Right? But think twice: your software product is your only cash cow whilst the big one on the other side of the river generates revenues from a large product portfolio. You’ll henceforth die before your large competitor does, no matter how much money you’ve raised.
10. Think first things first: your project needs an architecture too. “Right” order is: 0) idea + slideware demo 1) quirky demo for funding + recruitment purpose that you’ll throw away as soon as you’ll get seed funding + recruitment + strategic analysis 2) seed funding (angels) + software architecture 3) functional specs + user interface design + feasibility + technical requirements + development schedule 4) prototype started all over again from scratch 5) series A + refined proto + then start the marketing machine (road map, channel, trade shows, PR, buzz, and all that jazz), hand it to the CEO and prepare for release crunch time: documentation, support, help, manufacturing, shipping, etc.. Don’t worry though, things never happen as such. Expect the unexpected: the story never ends up as planned in the scenario.
11. Think interoperability: since you can choose, choose the most appealing role of the play: the white knight. In order to play White Knight, you need to look like a honest broker, even though you’re not. Think of Firefox’s ‘we’re gonna free the web from Microsoft’-approach: they run on all major platforms, support a massive number of external applications (like iGraal) as a platform, is translated in a number of languages by a community, etc. and at the end of the day, Mozilla makes 60 million dollars per year, whilst Google makes much, much more (Mozilla runs Google as a default search engine), and locks you in with little apps like del.icio.us tagger. So, to recapitulate Mozilla Firefox’s set of best practices (I should say right here that Microsoft is very good to at implementing such strategies, I can answer questions on this if you like), your product should be multi platform (start with Windows (90% installed base is convincing enough), then move to Mac OS, then move to Linux), be multi language-ready (it’s not so complicated to support Chinese, Japanese, Arabic and Russian unless you think about it afterwards, and then it’s a nightmare), and opened to external developers through a game of APIs: it will generate a buzz, make your company look sexier and hence ease new hires, and last but not least create value on your software by developing what you don’t have time to develop yourself. If you can use freeware code, do it; if you can purchase code for flat fees, do it; don’t pay flat royalties for source code down (eg US$ 15 per product sold), go for pay-per-deployment revenue % royalties instead – ie 1% of unit price; too risky. Make sure you don’t start depending on a partner though: don’t get locked-in yourself. At the end of the day, a good interoperability execution of strategy will strengthen your bargaining position with potential partners who will then realize you have the ability to choose to support them, or not. And then you’re the one calling the shots.
12. Think robustness. Like Criteo, software with crème-de-la-crème architectures never break because of the load (the post, in French, I’m pointing to basically says their full .NET software resisted torture)

Expect a bunch of technical takeaways this time as soon as I feel ready for it.

Like

Unlike

Related posts:

1. Developer to all-technical-staff ratio: 1:4 as a rule of thumb?
2. Lessons from Microsoft's acquisition of ScreenTonic
3. Peter's Principle applied to software start ups
4. Microsoft IDEAS software startups web 2.0-style
5. Hardware giants to software BU: "thank you!"