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

Jérémy suggested that I describe my different experiences as a software developer in a set of articles, and I found this approach really interesting. I will start here with my first big experience as a developer during my company creation, and then I will continue with the different projects I’ve realized in my current company. I apologize in advance for not being able of giving some deep details sometimes, as confidentiality matters prevent me from doing this.

Two years ago, Fidji and I decided to launch a company “BlogEntreprise” (now discontinued). The project was to develop a professional blog portal for companies and associations. Instead of using existing tools, we decided to develop our website entirely by ourselves to offer the best personalization tools. The website had two different parts:

              – A professional blog search engine 

              - A personal space to create and manage your professional blog

• Languages and DBMS used :

I was the developer and it was my first real experience of web development. In three months I have developed a website using three different languages.

              - HTML: the basic language for all web applications.

              - JavaScript: it was principally to control that all forms were filled correctly.

              – PHP: I’ve chosen it because it’s the best free language to use with MySQL and because it’s both a procedural programming language and an object-oriented one.

As I said before, for the database management system (DBMS) I have chosen MySQL for two main reasons: it’s free and it’s a powerful tool when used with PHP.

• Strong focus on the analysis stage

In order to develop the website more easily, I took a lot of time to build my entity-relationship model. For those who don’t know it, an entity-relationship model is used to describe the structure of your database and the relationships between different tables.

I think that having a good entity-relationship model is crucial to have a strong database: it is a basic for software developers to dedicate a lot of time to think about it as it eases dramatically the rest of the development process.

• Main issues

The most difficult part of this project was to combine the technical and the design aspect. With languages like PHP it’s not easy to separate the design part from the technical part as they are mixed in all files. Conceptually it is really difficult to know where to start: a website conceived by adapting the technical development to the design might be really different from one conceived with the technical part coming first. In that case it’s often a problem of competencies: as I’m not at all a web designer, I had a tendency to think to the technical part first, and then to adjust the design.

Besides I developed this website in parallel of my studies during nights and week-ends, so I didn’t have a lot of time and I tried to focus on the technical part to get things done more quickly. 80% of my time was dedicated to the technical part of the website and only 20% to the design aspect.

At the end, my lack of design abilities has been the main problem: it was really hard to attract companies and associations with a design which didn’t look corporate at all.

Finally, without any money to invest in design, our idea was perfect on paper but the realization as a whole wasn’t enough convincing. Even a well developed website, without any bugs, can’t convince customers if the design is really bad, as it is the first impression given to visitors.

• Doubts

During those three months, and especially since it was my first large development project that I started from scratch, I had a lot of doubts about my development choices. When you develop an application or a website you never know if you are writing the “best” code. By “best” I mean the most adaptable, the most evolutionary code possible, which is the definition of an “optimized” code. I think that the answer to the question “did I make the right choice or is it possible to optimize the source code?” is that you can always optimize it but sometimes you have to make some choices because you can’t always imagine all the future developments of your website.

• Technical insights

If I had to make the same project again I think I would use a language based on the Model-View-Controller design pattern (it could be RoR or even the MVC version of PHP). Indeed, with MVC, everything is clearer: data access and business logic, data presentation, and user interaction are separated in different files. I’ve also learnt that developing this kind of project alone is really hard as you can’t get any feedback on your code and the testing part is even longer.

• Business insights

The fact of having both a technical and a business education has helped me a lot in this project as I was able to better understand the requirements of my business partner. And it has shown me that software / web developers can’t become obsessed by the development to the detriment of the business idea (and unfortunately it is often the case, which leads to products with a perfect code but which are unmarketable!). I’ve also experienced the thrill of being both a software developer and an entrepreneur, which leads to accept with pleasure long hours and an entire dedication to a project.

Rémy is a co-author on Tech IT Easy. You can read more about him on his initial announcement.

Like

Unlike