Get the latest updates about our blog posts.
Subscribe so you don’t miss out!
Enterprise Ready is far from an official term and not only software related. Any development agency will have its own interpretation of what makes a software Enterprise Ready. At Lizard Global the key word is Reliability. Quality assurance processes and rigorous testing protocols ensure that applications are reliable under all foreseeable circumstances, making them perfect for enterprise customers. All products developed from Lizard Global also adhere to industry standards in terms of scaling, performance and security.
So what makes software reliable?
It seems easy to define when anything is reliable. If you can trust something to do what it claims to do, you’re fine, right? So we get the smartest developers we can find and it won’t get more reliable than that.
Unfortunately there’s more to it than just having the best people on the job. Software is more than a complicated algorithm. It’s a product with users and it might be the backbone of a whole organization or enterprise. This takes the whole “trust” issue to multiple levels. Can you trust that:
1. Users are satisfied with the product? 2. Users can access the product at all times? 3. Users and company data are protected? 4. The product can grow in both users and features? 5. Is the product equally stable at all times? 6. Is the product resilient to unexpected problems? 7. Are the costs predictable?
Although it seems trivial, user satisfaction is not something we take lightly at Lizard Global. An in-depth article was posted a while ago on our blog about our approach to guarantee continuous satisfaction. Another article explains how to launch the best possible product.
For an organization, the users are either the source of income or the people that work with the product to generate income. Directly or indirectly, if users are not motivated to use the product it will cost the organization revenue. Hence, making user satisfaction a priority is a vital part of making software enterprise ready, even before we go into anything technical.
…or simply the uptime of a service is defined by uptime/(downtime+uptime). The target for this formula is of course 100%. Keeping a service up and running is a combination of different factors. To start, the hosting: Lizard Global is not a hosting company but with 10 years of experience in hosting our products with different cloud partners, we know what to look for. At the same time we adapted deployment methods with very little dependency on hosting parties, ensuring no environmental issues at deployment time and the ability to host on any cloud solution a company requires.
We utilize docker to do so and incorporated this fully in our CI/CD flow. While this almost ensures no downtime, deployment isn’t the only thing that can go wrong. A network can fail, a router can die, a nameserver can suddenly show weird behavior. We cannot influence this, but we won’t simply call it a force majeure either. We have processes in place to monitor any unforeseen circumstances and workarounds to minimize the downtime, next to 24/7 support availability in our SLA. Reach out to us to find out more (free consult)!
Since the Internet exists security has been an issue. Whether it’s a DDOS attack to take down a service, or a hacker trying to get valuable user data, a breach has huge consequences for any business. Examples like downtime, affecting availability and exposed credit cards or private data, change the user’s perspective. One side of dealing with breaches is prevention. For instance by keeping software up to date by applying the latest security patches. This is a continuous process. Another preventive measure is a Penetration (PEN) test. This is basically asking a specialized company to try and hack the product. Lizard Global partnered up with a couple of such companies to do PEN tests before launching a product.
But all these measures might not be sufficient, hence we make sure we are always ready for impact. An IT Disaster Recovery Plan helps us to minimize the damage. This is not only a software recovery plan, but also a business recovery plan, including breach notification plans, and data handling. Many governments have regulations in force that will make this mandatory for sizable companies, like the GDPR in Europe or PDPA in many Asian countries.
In 10 years of software development we’ve seen many clients outgrowing their own expectations. Great! Right? Yes, ofcourse, but success can also ruin a product if it’s not ready for it. Successful products typically grow in two ways: User base and Features. To facilitate the first, services need to be scalable. One way to do this is throw in more CPUs and RAM (vertical scaling). But there’s a limit to this and to solve that we add more nodes or instances for the same service (horizontal scaling). This can be done in many ways but the software has to be designed for it.
Creating infrastructure and data diagrams is a very important step to see exactly where scaling bottlenecks may occur even before you plan to scale up. Feature expansion is a scaling on the development side. It requires a very well defined development and source code planning. Adding features can bloat the system and also cause failures where you don’t expect it. Automated end-to-end (E2E) tests will help prevent this. E2E is part of the core of our source code control.
Stability is defined in the time between repairable failures, also the Mean Time Between Failures (MTBF). It’s a measurement and thus having monitoring tools in place to make sure the value is as high as possible is important. Monitoring tools also help us identify problems and tell us how to resolve them. Stability issues can happen on a very low level, unnoticeable even, but giving users a sense of distrust. It can be unexpected user input, small parts of 3rd party modules that have been updated or even bad UI.
We have several tools in place to alert us when something is not working as expected and to get to the bottom of it. We can explain everything about it, if you’re looking to build a mobile- or web-application with a digital partner like Lizard Global. Get in touch with us!
All the items above show the complexity of creating a software product and keeping it up and running. With all the tools in place to make sure this happens in the best possible way, we must still expect a system to fail. Many failures can be caught by the software itself. Simple solutions like operation retries, for example a write operation to a database failed; simply do it again. Or even queue tasks for external integrations and run them asynchronously. Making operations idempotent (running it multiple times with the same parameters without additional effect) needs to be a core design principle of software engineering. Where this is really important, make use of database transactions: All or nothing operations.
Software is very likely to fail due to lack of resources. Rather than waiting for it to fail and then scale up, rate limiting is a method to keep things under control until the team can scale up or improve resource demanding parts of the application. Another thing to consider is well thought-out version control. Unit/E2E/UAT/etc. testing can only do so much and there’s always a possibility that a new build fails in production. A rollback to a previous version must happen fast if this happens, giving the team time to resolve the problems without significant downtime. A well designed backup&restore plan falls in the same category.
None of this will work without a 24/7 support team on call.
In the early days of agile development the most common question of new clients, especially enterprises, was how we can control the budget if we can’t exactly tell what we are going to build? Nowadays agile is more of an industry standard and a lot of data can support that projects tend to succeed significantly more often within budget than a waterfall approach can achieve. The question however remains.
The best answer is our Software Engineering Framework that helps to form a team most suitable for the project, i.e. equipped with the required set of skills, experience and knowledge, as well as achieving the best overall efficiency, both financial and productivity-wise. Additionally, it guarantees getting a product that fully meets business objectives with the least technical debt possible. This model provides full transparency on both resource and budget burn, allowing us to steer in the right direction.
Running costs can also increase and we perform, for instance, load tests to predict how many concurrent connections a system can handle and when it’s important to scale up and what costs are involved to do so. Predictability makes it easier for enterprises to attain business results.
Being ready is knowing what can be expected, how to prevent it and what to do when it happens. This all boils down to strict processes and documentation. At Lizard Global all of the preventing methods are standardized to the industry, most tasks are automated and dedicated team members make sure no shortcuts are taken throughout the agile development process. This is especially important for bigger companies that invest a lot in new products and may even need to be compliant (SOC2, ISO 27001, HIPAA, etc.), but not less important for startups that bet their life savings on the next big hit.
Final note: Does everything need to be Enterprise Ready?
No. Not all software is created with the same goals in mind. Being enterprise ready adds a lot of overhead to the total costs, costs that will be earned back in the long run. But not all products need to last forever. Lizard Global creates prototypes, proof-of-concepts and minimal-viable-products to raise funding or to convince the board of a corporation. But also small automation applications used internally hardly require to be ready for disasters.
We can advise on what level of “readiness” your next product requires and will make sure to provide the trust you need.
To receive more information about your enterprise ready custom software development project, get in contact with us now for free digital consultation advice!