Why every software architect is also an entrepeneur

I'm not sure when it happened exactly, but at some point this month while watching the new TV show Billions, it dawned on me: being an architect is just like being an entrepreneur, just without the huge financial benefits and risks. I might be wrong about this, or worse, I might be insulting our profession, but before you judge on me, give me a minute to explain.

For instance, just like an entrepreneur, an architect has to do a risk-analysis before he or she makes a decision. E.g. can we take a shortcut here without causing unrepairable technical debt? Or, what's the risk if we postpone this refactoring to a later point in time? In a similar fashion, the perfect solution doesn't exist. You always have to make a trade-off between multiple options for which the consequences (both good and bad) aren't always clear yet. For instance, the choice between a relational database or a NoSQL solution. One may be good for conservative clients and will increase the change it is accepted by management. At the same time, being agile and emerging database schemas don't always go hand in hand. Going for a NoSQL solution will give you some obvious benefits, but there's less experience in the field. If you happen to run into unknown territory, you might be on your own.

Successful entrepreneurs have to balance short-term investments against long-term investments. But architects do too. In most projects I've been involved with, the amount of development capacity is limited and pressure to deliver is high. So do you put those developers on introducing an automated UI testing pipeline that you expect to need very soon, or are you going to build that one feature the business people have been asking for. You know that you haven't delivered enough features to be competitive in the market. But you also know that if you continue without a proper testing framework, you won't be able to deliver the right quality anymore. Unfortunately, you don't know exactly when this point-of-no-return will be reached. And that's true for business investments as well. The entrepreneur might put some money in a new and better location for his shop, which he is really going to need if his business continuous to increase at the current rate. But he won't be able to replace that occasionally malfunctioning baking machine in his current shop.

Another similarity can be found when you consider an entrepreneur whose company sells professional coffee brewing machines. You'll have to sell those machines to your potential clients. This involves some serious marketing efforts to make those machines more attractive than your competitors'. But even if there's no competition, you still might need to convince your clients that they need to upgrade to newer or more expensive machines. As an architect, you're doing a similar thing with the developers that need to work with your architectural ideas. In most agile companies, you can't really force them to apply your architectural principles (well, you can, but you won't get the results you want). Instead, you need to sell your ideas to them so that they understand why certain extra layers of abstractions are needed, or why they need to write a unit test before they write production code. This requires face-to-face sessions, pair programming, written guidelines and investments in tools that facilitate that architecture vision as much as possible.

If an entrepreneur doesn’t have the money to buy that new location for his shop I mentioned before, he might have to go to an external investor or a bank to get some money. But he won't get that money without trying to get 'buy-in' for his business plan. The investment party needs to trust that their money will be spend wisely and will give them sufficient 'return-of-investment'. Similarly, if you're an architect and you want to invest in a NoSql solution that will take a couple of developers a few weeks to complete, you'll probably have to convince management to accept that that development capacity cannot be put on feature development. But you can't explain them the technical benefits, simply because they will not understand you. Instead, you need to try to formulate those technical benefits in business opportunities. Maybe you can convince them that doing this investment will allow them to more quickly deliver new features. You probably can't quantify this accurately enough, but by trying to put your feet in their shoes, you might be able to help them see this investment is worth the time.

Another difficult decision, especially when your time is limited, is to decide between quality, functionality or the delivery date. When a deadline is approaching, it’s the job of an architect to clarify the consequences of jeopardizing the internal software quality to all stakeholders. If the deadline is really close, it might be better to skip some functionality or forfeit some of those bells and whistles (a.k.a. gold plating). If that is absolutely not possible, you can decide to drop quality for this sprint. But only under the explicit agreement that this will be repaired right after the dead-line, even if it will cost twice as much capacity. If you're a vendor of coffee brewing machines, and your competition has just introduced their newest product, you could decide to ship a product a bit earlier. And since you can't really drop functionality from a physical thing like a coffee machine, you might decide to not wait for those updated batch of components, even though you know some of the internal machinery has reported construction errors. Maybe you're lucky and nobody will notice. And even if somebody does complain, it'll probably be cheaper to replace the machine than to postpone market introduction now. And why not? Volkswagen has managed to hide their emission cheating device for years.

So what do you think? Does this make sense? Or am I comparing apples with oranges. Let me know by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.