1. An Operations Service System That Has Piled Up Beyond Repair Developing a corresponding operations service for a clear operations need, so that operations and business users can use it, is entirely reasonable. But if you are satisfied with only that, the following situation easily appears: Users constantly look for the entry point of each system, jumping back and forth between systems, busy hunting for buttons and copying parameters.

1. A Process Divorced from Responsibility Is Meaningless Software architecture matches organizational architecture, and this shows up not only in functional boundaries but even more in the division of responsibilities. Only clear responsibility boundaries can build good team collaboration and growth. Every team and every person should understand their own goals — what they should take on and what they should stay out of — and invest their time and energy in things that benefit the primary goal, rather than sinking into trivia.

1. Only Platformization Lets You Go Further As long as you respond to the market a little faster than your competitors and live a little longer, you can win more room to survive. A brilliant business model or market opportunity is more like magic: it can grow a company fast, but it is not something human effort can control.

1. Choosing a Communication Protocol Ops systems are better suited to HTTP than to gRPC. More ops and R&D engineers are familiar with HTTP than with other protocols. Once you know the HTTP protocol, learning a RESTful-style HTTP API is quick. Being familiar to more people and easier to learn means better communication and lower handover cost, because they share more common domain background.

1. Bloom’s Taxonomy Bloom’s taxonomy is a classification scheme proposed by the American educational psychologist Benjamin Bloom in 1956 at the University of Chicago. It classifies educators’ teaching objectives so that each objective can be achieved more effectively. According to Bloom’s theory, knowledge can be divided into the following three