Last week we ran a training session on the automated operation and maintenance management system. When referring to two cases, I suddenly realised that both of them, without prior consultation, had given top priority to configuration management when carrying out automated operation and maintenance. When I was organising the training materials, I didn't pay much attention to this order. But when I presented it, it was quite obvious that configuration management had been given such a high priority.
Why am I talking about this today? It's to promote our CMDB solution, of course. Those of you who are interested can read on, and for those of you who aren't, it's nice that you're here anyway. Thank you very much!
Ten years ago, building a CMDB was a massive undertaking, with the aim of being big and comprehensive. But as time has gone on, the big and comprehensive approach doesn't work so well anymore. Today, when people come to us to talk about CMDB, we're straightforward and say: if you want to build a CMDB, the way to do it is to be 'small and exquisite'. It's not that we're arrogant, it's just that if you don't do it that way, it's hard to succeed! We've all experienced the pain of the big and comprehensive approach and the emptiness that follows its implementation. We don't want to retrace our steps if we have to rebuild the CMDB ten years later. It really isn't necessary!
Looking at the changes in CMDB construction over the last decade, the most significant is that the CMDB is no longer just a configuration management database. It is becoming the data service centre for operations and maintenance, focused on providing data for consumption and connecting scenarios, services and data.
When we look at a product, we should focus not on its features, but on what problems it can solve and how it solves them.
Our CMDB team has technical skills, consulting skills, and product skills. This combination allows us to better solve the problems we encounter from an industry perspective, from user pain points, and from implementation pain points. Some people might say that I'm just talking nonsense, that there's no real substance to it. But what exactly is real substance? Is it just if I tell you how to sort out the classification, how to design the model, and how to build the scenarios that it's real substance? If there is no change in mindset, all the so-called "real substance" is just like the dry goods displayed in a store! From an implementation perspective, cooperation based on mutual understanding and agreement can achieve twice the result with half the effort. So we're looking for those who can recognize the "small and exquisite" approach to CMDB building. As we focus on the pain points of "blockage causing pain", focusing too much on functions will make us focus on the tools rather than the feelings of the main body. The original intention of customers to rebuild the CMDB is not to buy tools or models. What they want is to solve the problems of inaccurate data, insufficient supply and poor consumption. And that's what we're good at!
We insist on focusing on scenarios, guiding services from scenarios, and letting the services tell us what the data is and where it is.
Maybe you think what I'm saying is a little abstract. There's no way around it. If you can't understand it at that level, you won't be able to see the value behind it. The customers who recognize us have basically gone through ten years of agony and clearly understand what is appropriate and what is inappropriate in building a CMDB. Without their change in perception, it would be very difficult for us to build a scenario. Seriously! Our belief in "less is more" is inherently at odds with the "big and comprehensive" approach. Is it hard to implement a scenario? It depends on the specific design requirements within the scenario. Then how do we determine the boundaries and granularity of the design? That depends on what the customer's pain points are in using the CMDB. And analyzing, planning and designing these pain points is our strength.
Finally, let me say one more thing: Don't just focus on features when rebuilding the CMDB.
The above are just some random thoughts after the automated operations and maintenance training.
