Think ecosystem

Organizations in the Middle East and Africa are increasing their innovation capacity by expanding their research and development (R&D) footprint from being inward-looking to ecosystem-integrated thinking. It has opened new areas of collaboration with various stakeholders such as the government, public institutions, start-ups, and other private entities. For instance, a leading telecom provider in Middle East & Africa is building a super app involving their retail, banking, and insurance partners. This POV will explore how ecosystem solutions or super apps need consumer-centric quality assurance to guarantee a superior end-user experience. 

The traditional IT lifecycle of application development includes assessing requirements, design, development, testing, and production deployment. Most teams focus on the shift-left agile software testing method to identify issues early. 

However, in ecosystem-integrated projects, there is an extra focus on the spectrum’s right (the shift-right approach) through continuous monitoring of the end-user feedback and the use of various real-world chaotic scenarios in the production environment to enable the business to evolve.

Evolution of application design philosophy

The traditional engineering mindset and design systems have worked on these time-tested assumptions:

• The application resides in a known, controllable data center
• The data center is secure
• The internal network is scalable
• Complete control of the entire environment is with a known team
• All changes are well planned, and structured change management is in place
• A successful user acceptance testing almost guarantees success in production 
• Plan everything; anything outside the plan is out of scope 
• Functional testing largely ensures success

This shift-left quality assurance model with early engagement in the development lifecycle still thrives in traditional in-house controlled environments. However, as more and more applications adopt the ecosystem design approach and integrate with environments in which they have little or no control, the assumptions above need reimagining. 

Organizations must expand the universe of faults covering every possible chaotic condition from systems and business scenarios. Subjecting the application to these test conditions helps uncover all permutations and combinations of real-world issues delivering a more stable system. Chaos engineering is a branch of software engineering that tests the reliability of distributed software by introducing failure and faulty scenarios to assess its ability to withstand random disruptions at various stages of software development and in a controlled way in production environment

Chaos scenarios are ecosystem-specific

Every ecosystem is unique, and the scenarios in the universe of faults should cover general chaos and ecosystem-specific issues. 

System scenarios

1. Server failure
2. Storage I/O failures
3. Varying network bandwidth (from an end-user perspective)
4. External interface failure
5. Security breach
6. Memory spike due to security flaws on the server
7. Threshold breach by incoming requests from external interfaces

Business scenarios

1. Spike in customer order
2. Varying load in different customer channels
3. Window shopping on the app not resulting in new orders
4. Performance of order fulfillment systems at peak load
5. Functioning of payment systems at peak load
6. Partner system’s inability to fulfill its obligations

A comprehensive universe of faults brings normalcy to the chaotic possibilities.

How chaos engineering can benefit organizations

Switching from traditional, controlled application development to next-generation ecosystem application development is a step change. Understanding and applying chaos engineering principles requires significant upgrades to the existing engineering organization structures.

Organizational structure: Chaos engineering is a specialized field like performance engineering. It must be factored in with defined roles and responsibilities, requiring a change in the organizational structure.

Shift-right cultural change: Most organizations are comfortable with the shift-left approach and have less hesitation in experimenting in development and test environments. However, a controlled test in the production environment in the shift-right method requires a significant cultural change.

Ecosystem partner sensitization: Ecosystems are vulnerable to byzantine complexities resulting in different interpretations by stakeholders in the case of a failure. Every partner in the ecosystem needs to apply chaos engineering principles to ensure the general stability of the ecosystem. 

Business partnership: A clear business definition of what is ‘normal’ in a complex environment is vital to creating an adequate fallback mechanism. 

Tools: Several proprietary and open-source tools cover different aspects of chaos engineering. Organizations should upgrade to address the ever-increasing universe of faults. 

Conclusion

The ecosystem application development model has become an essential element of strategy in several forward-looking organizations. It requires a comprehensive review of all aspects of the software development lifecycle. Chaos engineering ranks high in priority, like security and performance engineering for building ecosystem-ready applications. A suitable investment will ensure a smooth transition to building ecosystem-ready applications and deliver a consistent end-user experience.