If we are developing a system, program or script for a business then, we are solving a business needs. Sometimes, we are guided (or misguided) technically in what to do, but it is not rare to find that customers don't know what he needs to do. I explain, a good requirement says "we need a website with a,b,c functionalities with x form and y tables" but usually a customer could say "I want a website".

It is what differentiates a nerd from an engineer. Nerds tend to be poor programmers because they don't understand "what" to build but "how" to build. The HOW is important but the WHAT sets the route.

Example, a website

Let's say we need to build a website for a small SMB (Small and Medium Business). And you start building it, and you pick Wordpress, and you make a portal/ blog, and you create the next sections: * Front page * About us * Categories of blogs * A catalog of products * Contact

Question, what is the business needs?

Of course, if we are asking after the construction, then we screw it big time!. For example, what the SMB needs? Or more importantly, why the SMB needs a website?. Why the SMB is spending money on the project. Let's say that the SMB sells shoes.

• What the business does and what it wants (for this project) are not precisely the same. For example, the SMB could sell shoe; however, it wants to promote the brand. Anyways, in this case, the website is to sell shoes. Great!. Now we have the leading.
• Front Page. Ok, it must be focused on sells shoes.
• About us. Ok, but it is irrelevant. Some companies spend time taking pictures of the team. Is it essential, most of the time, it's not!. However, let's say that the business is Italian and its +100 years old. Now, that sells shoes and the "about us" counts considerably.
• Blog. It is a common mistake. We want to SEO (to be positioned on Google Search), and a blog could help. However, it could not lead to sales. Our target is sales, not visitors to the page (an absurdly common mistake). Usually, the blog is gone, unless the business is willing to spend money adding new content.
• Then, the catalog. If the company is a B2B (business to business), then the catalog is way too different than a B2C (business to customer). A B2C catalog must have categories, end price and so on while a B2B is focused on quantities.

Question, can I sell shoes using the website?. Let's me tell you an experience. I purchase a shoe from the Internet; the shoe was small, it is because some shoe companies (Chinese) uses some weird specifications to size or just the shoes are not fit. So, I prefer to buy it directly, I want to test it, and most people will do that. If I can sell it via the Internet, then the website is considered LOCAL, so my focus is not to sell shoes, but customers must visit my store!.

• Contact: I will put a form, and that's it!. Is it right?. Not really. First, I want all the ways of contact. Do my business have a phone? Then it's contact! And the email, too! Also a form and social network (if any). But most importantly, I must put this everywhere on my site. And since it is a local site, then the map is a must, also the schedule and maybe a photo of the store. Also, people hate to fill forms!. And people hate to fill forms that are never answered.

So, our site will look as follow. * product -> contact us (or visit us). * front page -> visit us * others -> visit us

We aren't even touched the SEO part, but now the site will fulfill its goal.

Only YOU Can Prevent Forest Fires (and bad architectures).

Architecture.

What we know: * It is a website. * Maybe we need a dynamic catalog but that's it, everything else is static. * And Maybe we need some form. Sometimes, customers want a static site, and it's easy. So, let's pick technology. * PHP Is King of the SMB. Why? It is because it is easy to find host/server/dedicated, it is cheap, and it works fine. However, what if our dev team knows Python, so we use Python too. * We don't need a site-editor, for example, we don't need functionality to modify the front page. It lowers the costs and performance. So, Wordpress is gone because we don't need it. * But we need a small table into a database (for the catalog of products) and maybe a table for the contacts (if we have a contact form).

Picking architecture * MVC? Maybe. Our project is focused on the visual, after all, it is a front site. * Services? We don't need it, either a messenger system. SOA is gone. * Microservice? Why? not!. Why we would want to increase the costs?. * Reactor/Angular?. Okay if we're going to kill the SEO, so no. * Monolith? Some developers hate monolith; it is because they don't understand the business needs. In this case, Monolith is ideal: low maintenance costs, easy to program. Do you know the opposite of Monolith?. Fragmented!. * Cloud? It is the decision of the platform but the decision of Cloud versus hosting vs vps vs dedicated it depends on the number of customers. In general: * * Few visitors: hosting. * * Average visitors: vps. However, it requires the installation. * * High demand: a dedicated server. * * I'm clueless: cloud, however, it is always expensive. Sometimes it's cheaper to pick a VPS and later escalate to a dedicated server * * I like useless fad: Serverless. Serverless is not server-less.

---