Remember that a software must be designed to meet the business goals and only to meet the business goals.

Software design is not just the design; you have to worry about many things with financial considerations and shifting ground under you.

Establish the goals and non-goals of the business.

Identify the features needed for the Minimal Viable Product MVP) and then negotiate with the marketing team to establish a Minimal Marketable Product, most probably it will be MVP + more bells-and-whistles.

Armed with the above, draw up a high level componentized design. with the view that these components will be pluggable and replaceable at will.

Now for each component try to see what all sub components are needed e.g. Database, Messaging System, Data Persistence Silo, Statistical Analysis Engine etc..

Get the sub components’ list and bring the pieces together to form a master list of sub-components needed and remove duplicates.

Now for each sub-component evaluate if you can or want to build it yourself or you need to take a 3rd party dependency. Realistically, some OS/Low level dependencies cannot be avoided, e.g. one cannot be realistic about the hope to write their own OS or IIS/Tomcat/WebSphere replacement or DB server from scratch. These underlying things are well understood and are the industry-standard hard dependencies.

Now worry about the other dependencies:

If you want take on a 3rd party dependency, understand the long-term implication of that dependency. If this component is one open-source “DIY” component with public forums (stackoverflow etc.) as the only support group :-), always bear in mind that you are taking on a tough dependency. Anticipate and account for the possibility that you may have to assign engineers to understand the open-source code, and modify it, recompile it and like a good Samaritan, contribute back to the open-source movement. [On another side note: These pieces love to break when some version of an dependent component gets updated by Gradle or Maven or npm etc. Do not depend on Maven & Co. to pull down all the dependencies at compile time. Pull them down yourself, reference them and add in your source repository as external dependencies. Update them only when you are satisfied when “updated everything works”. Forgive me for my digression, this is not Software Design – It comes under “how to actually run a dev project”.] Another thing to worry is that these components may go out of fashion (like Hadoop, Ruby did and Blockchain is on its way); and once they are out of fashion, you will not find anyone who even wants even to talk about them.

If dealing with a commercial 3rd party component, understand the licensing and SLA promises and costs.

Now look at the skillset available in the job market. Do we do this in C# / Java / PHP / Python, whatever? This depends upon the availability of personnel. Your beloved language does not matter. e.g. I love C but there is nothing popular happening in C, it is used only for real low-level stuff, AND HENCE there are no C programmers available in the market anyway.

[ A side-story: In one of the projects, my client inherited large piece of code written by someone else in a language called Clojure – a lisp-like layer on top of JAVA. It was impossible to find Clojure coders in the job market, so this piece remained a mystery black box, and nobody wanted to touch it because nobody understood it. If a defect came or modifications were needed, they would just pre-munge and post-munge the data and code flow. Recently the company actually invested in a few engineers to learn Clojure, understand this code, and have started rewriting the functionality in JAVA (because the company is a JAVA shop and JAVA programmers are available in the market).]

Now take this (with a hand-in-glove with Marketing folks) to the business owners and show the costing with choices (Dot NET v/s JRE, DB2 v/s Oracle v/s MySQL etc.). I have seen in one instance, the business owners thought that Oracle license was too expensive and we should use free version of MySQL. From the componentized design point of view it was just another RDBMS, but from infrastructure point of view, they had to have person dedicated to support the MySQL instances. And they call all this Software Design Costs… forgive them, for they do not know what they are doing.

Now design some plug-in points for feature creeps from Marketing folks. Marketing folks keep on looking at the competition and always want to be the “warmest and fluffiest croissant” in the market. Keep some some “Reserved” parameters in APIS or undocumented secret APIS so that you can sneak in these late-comer features without shaking the whole foundation. It is like a spare tire (en-US) / tyre (en-GB) / Stepney (en-IN) in the trunk of your car, which you pray fervently to the almighty, that it will never to have to be used, but you keep it anyway,

Many marketing folks have the “Ostrich Syndrome” i.e. whenever they see something shiny thing in the industry, they, like an ostrich, want to pluck it. Even if your software handles tiny 6 MB files, they will want to use SPARK/HADOOP cluster, blockchain or ChatGPT or whatever is in fashion, so that they can say that in the marketing messages and they will keep on asking for including the latest fashionable technologies during the product development cycle. Sometimes you have to succumb to their demands. As a software engineer you must clearly call out the cost of incorporating and maintaining such irrelevant add-on components.

Deployment is not a part of Software design. Whether to use AWS or Azure or whatever else are a part of the deployment strategy.