Independent YaaS services
Don’t depend on others.
Ideally, design your service with no code dependencies on other teams.
Developers have independent release cycles for faster delivery and can isolate failures to single components quickly.
The perfect service has zero dependencies.
Fully understand your system
Don’t guess. Know.
Know your system inside and out so you can fix downtime, track logs, and predict scaling before it becomes an issue with customers.
Customers want analytic data, insights into metrics, and a stable product they can trust.
Know the state of your services and system. Make it visible and easy to observe.
Design APIs with your customer in mind.
Design the API based on an early agreement with your users, and build functionality into it later.
Customers are happy because they are involved in the design of the product, and the maintenance costs are reduced with fewer revisions.
Focus on developing rich APIs based on customer needs, and develop the functionality later.
You own it, in every sense of the word.
Development teams are also trusted to interact with customers directly and act upon their feedback in a timely matter.
Valuable customer relationships are built, as is a win-win scenario with happy customers and a high-quality product.
You build it, run it, release it, scale it, maintain it, support it, and improve it.
Technology must scale
Each component must scale cost-efficiently and without limits.
Understand the scaling requirements of your solutions, and choose an appropriate technology to meet it.
Open technology landscape
Teams have the freedom to pick the right tool for the job.
Development teams choose the tools they want, because they know what tool works best for the job. When teams don’t want to choose, they can get input from the community or use the default tools.
Development teams are more efficient when they can use tools they like and are familiar with, and they are more committed to the project when they are not forced to use certain tools.
Release early, release often
Establish a deployment pipeline to deliver your product without the fear of breaking something.
The time to market is greatly reduced if you release early, get feedback, and then release again with the added improvements.
Releasing early reduces the time between development and bug reports. High test coverage and automation are key factors to achieving this.
Software only provides value when it's out in the market, so get it out there quick.
Teams own their product from design to delivery.
Development teams are trusted to work independently from the red tape of a big organization and therefore can develop a product quickly.
Team members are happy because they are trusted and not frustrated by processes and decisions that are out of their control. In return, teams take more pride and responsibility for the quality of their work.
You can take a concept to production with limited dependencies outside of your team.
Design for failure
Don’t design on hope.
Build resilient services that handle failure and recovery gracefully, instead of hoping they will never go offline.
Developers get to design services in a different way and focus on testing failures.
If the infrastructure or service can go down, it will go down. Design for failure and recovery.
Don't surprise your customers.
Development teams design UIs with straightforward and predictable interfaces using well-known technologies.
There are no hidden surprises for the customer, because the APIs and UIs are consistent.
Use predefined patterns and best practices to ensure a consistent API and UI.
Architect small, simple services
Keep it simple, yet the possibilities become endless.
Services are small and simple, which has a lot of advantages. They are easy to exchange, localize, and reuse. Although the services are kept small, they increase the complexity of the entire product landscape.
For developers, refactoring services becomes a normal task, and this simplifies development and maintenance.
The perfect service is small and does one thing.
If you find any information that is unclear or incorrect, please let us know so that we can improve the Dev Portal content.
Use our private help channel. Receive updates over email and contact our specialists directly.
If you need more information about this topic, visit hybris Experts to post your own question and interact with our community and experts.