Software is present in every organization that wants to grow at some scale. The software helps the company’s employees to be more productive and to reduce manual and repetitive work. The software can have the best possible interface, turned in 100% people’s productiveness, but as a basic item, it must work when it must work. When vital software to an organization fails, the difference between regular software and good software is discovered. And here I talk about its architecture.
When the architecture makes the difference
To talk about this subject, I’ll show you two real cases of two clients in the media area. They are close to me and had their business growth held for a while due to bad quality software.
Please, no more load
The mentioned software was a portal to for a known Brazilian TV show. With that portal, people used to register themselves to be part of the TV show, donate money for good causes, interact with their favorite characters, and some other activities. Under normal circumstances, the portal used to handle everything. But when one of its TV presenters mentioned something about the portal when they were live on national network, it was deadly. We just had to wait for a few minutes before the portal was down. It could be simple stuff like saying “access our website for a chance to win a prize”, or “access our website to talk to the famous actress X”. And the problem that repeatedly happened, having the portal down, was a technical problem related to its architecture. It was not prepared to receive so many access as it did.
In this example, we see a powerful trigger to an entire population being wasted because of a software malfunction. The population (customers) were already convinced to look for something, was frustrated with the malfunction and lost interest automatically. The TV show image was affected negatively, and he failed at enhancing its brand, increasing its overall engaged public and eventually losing some revenue.
The second example is about a scenario when the software was a big aggregator of information coming from many different sources. It was responsible for some important transactions related to the company’s invoices. It operated fine for many months after its first release. But when the database went over some load, it started to behave slower than it used to. Also, a big project or renewing the entire UI was undergoing. But it would be a big failure if something beautiful was released without actually working. The loading screens were too slow and were forcing the user to wait for many seconds for some feedback. The impact on business was quite relevant because the selling process was also affected for a few of their products.
Solutions and business relief
For both of the scenarios, a new architecture was implemented. The first one focused heavily on caching. The second one focused on shortening the times to get information. But both passed by a deep architecture remodeling.
Nowadays the first one counts with millions of users reaching their portal to interact with the brand. They also count with a stable portal, which allows the decision-makers to make wiser decisions when they are under pressure. The second was able to release the new UI, which enhanced the relationship with B2B demanding customers, and no more transactions are lost. Now the roadmap is welcome again.