A Chinese blogger has compiled a story about the enterprise app market. This story tells that When Tesla was about to launch Model S in 2012, because it was not satisfied with the flexibility and price of SAP’s ERP products, it chose to abandon SAP and use Mendix, a low-code development platform. It took 25 people and four months to build an ERP system by itself.
The hero of this story is Jay Vijayan, CIO of Tesla at the time.
The information system of an automobile manufacturing enterprise is undoubtedly very complicated. But by then, SAP’s automotive solutions would have incorporated the best practices of the global automotive industry and would have helped Tesla build its basic information architecture. A CIO making such a decision must distrust the enterprise software industry. But in fact, the Indian-born IT executive himself spent years in traditional enterprise software, from VMWare to Oracle. He is familiar with the enterprise Application Suite of integrated solutions such as SAP and Oracle. Since 2000, he has been responsible for ERP related enterprise suite development at two IT giants.
Would the CIO of another auto company have made a similar decision? I think most likely not. Almost all oems in the world can afford and use branded commercial kits, some choose SAP, some choose Oracle. These brand kits for automotive enterprise CIO, buy is a rest assured. To be able to make the choice to abandon the existing one and make it on your own is something that only the expert can do. It’s like ordinary people buying branded computers with fixed specs, but geeks buying accessories and doing it themselves. Vijayan, as a veteran of ERP product companies, chose not to buy ERP products, but to build them by himself. He had to convince Elon Musk, the boss, internally, probably based on his experience. If people who have worked at Vmware and Oracle for more than 10 years say they can do it themselves and not buy it, that’s more believable.
If you hear about a car company that spent a lot of money developing an ERP of its own, didn’t solve the problem, and bought SAP’s solution anyway, you might find that story more plausible.
The question is, why did Vijayan’s decision come true? Why didn’t self-built ERP become Tesla’s nightmare?
1) The abstraction requirement of self-built information system is greatly reduced
If you want to open a restaurant, you have to take into account the different tastes of the customers around you. You may have to prepare more than 50 recipes, which naturally requires a variety of ingredients. But if you want to cook dinner for your own family, you just need to buy something you love. There is always this complexity contrast between commodity services and consumer services.
This example may be overly simplistic, but the complexity of a software product boils down to its abstraction requirements. For example, if you use A CRM application, you can manage your own customer orders. Product details can be added to the orders. The product details can be selected from the product catalog, which contains A multi-level structure. If you’re offering a discount to a customer, you can do either a percentage discount or an absolute discount, or both. We can use software to achieve such flexibility because software manufacturers abstract such logic and structure from complex business practices, so that it can meet the needs of a large number of customers.
A DIY system removes some of the baggage of architectural abstraction. A certain level of abstraction is still required, but as long as it closely matches your own needs, you don’t have to consider the differences of other industries and other enterprises.
Also, DIY systems can be more bold with direct concrete rather than abstract naming. For example, Tesla is bound to involve the management of charging stations, and generally needs to use the abstract asset management module to manage the commercial suite. A charging station and a charging pile must belong to the abstract definition of “asset”, and the asset categories related to charging stations must be configured in the asset project. However, the self-built system can be called simply “charging station management”. This simplifies the structure and makes it easier for users to understand.
In other words, it’s not like a generic management software like SAP can’t be used in specific scenarios for specific industries. However, it has to establish a more complex level of abstraction for the needs of industry universality, so that the designers and implementers of industry solutions can achieve industry landing through configuration management. The implementation of Tesla’s self-built ERP does not require this overly complicated abstract process.
Tesla is even able to reasonably discard software modules based on its business model. For example, There is no Dealer Management System in Tesla, and Dealer Management is the core module of ERP in the automobile industry. Removing this layer will make the whole ERP system much simpler. Of course, Tesla also has its own unique requirements, such as the online upgrade of the vehicle software, and the selection of software packages should even be accurately related to the batch of the factory.
2) Vijayan has mastered mature architectural models
In addition to being able to subtract from commercial-grade ERP products, the CIO of Tesla also has a key asset to support his decision making, which is the knowledge of architectural models related to the automobile manufacturing industry. This intellectual asset is not a copyright of SAP’s software, nor does it belong to any other software company, and it is not protected by any intellectual property laws.
In information system architecture, the two most important parts are data architecture and process architecture, among which data architecture is more important, because it is the foundation of process architecture. This knowledge is the most important and useful domain knowledge for the development and implementation of mature ERP products. In many IT consulting projects, these are the most valuable parts of the implementation plan provided by the consulting company. I know a retired IT specialist in the UK who sells thousands of ER diagrams (entity relationship diagrams) of various commercial databases on his personal website. You pay him a few thousand pounds, he’ll give you the whole library on a disc. Vijayan certainly has enough experience to cover these parts.
Of course, don’t underestimate the scale of these models and the difficulty of implementing them. For such a complex collaboration as the automobile manufacturing industry, ERP software involves at least hundreds of data objects, as well as the intricate correlation between each other. There are at least thousands of processes around different business segments. All of this architectural knowledge ultimately translates into well-named, well-structured, and logically sound software development requirements.
A lot of complicated things will make ordinary people frightened, but the expert is not the same, he knows the inner structure of complex things, natural can use local materials, cunning. We hear stories of retired engineers building their own planes and it seems strange, but for an aircraft engineer, he really believes that the only option in the world is not just to buy a plane, but to build one.
3) Help from low code development tools
Even an expert would need tools to develop software to replace SAP’s commercial products in a short period of time. In Vijayan’s interview, he mentioned that Tesla had very limited time to complete the development of its own ERP system before the Model S was released in 2012, so he chose a Mendix low-code development platform known in the manufacturing industry (later acquired by Siemens). Low code development platforms do a lot of up-front encapsulation for the implementation of enterprise relational data applications. Creating a data table, creating a form for entry and query, and creating a workflow for adding, deleting, and reviewing data almost all require no code duplication. That’s why Vijayan was able to do it in four months. The speed doesn’t surprise me. Today’s low code/zero code tools can do very complex and large applications at the four-month scale. Besides, by his own account, it took 25 men. These 25 people are no doubt designed to create a large number of data tables and processes synchronously by dividing the business segments, thus shortening the overall project cycle.
Enterprise applications that can be implemented by low-code development tools are indeed very formal, but the vast majority of enterprise applications are themselves formal. Especially in the background application like ERP, it is composed of data architecture, view permissions, statistical analysis, workflow and other components. 99% of user operations can be abstracted into the operation of adding, deleting, checking and modifying data. This is why enterprise application development is bound to move in this direction of modeling rather than relying entirely on the native technology stack.
In fact, even SAP, Oracle, and Microsoft enterprise applications all support low code application customization. Salesforce’s Lightning, Microsoft’s Dynamics, and Oracle’s APEX are all similar tools. SAP, perhaps the latest of the big players to follow this strategy, also released a public beta version of RUUM this month. While it is positioned to meet the personalized needs of the long tail of SAP customers, the same logic is used to address backbone scenarios.
After 2014, Tesla still returned to the strategy of native development, changed to Microsoft’s technology stack, using. .net developed the final version of the internal ERP system, called WARP. However, I believe that Tesla is still using low-code products to solve many problems, and it is impossible for all requirements to go to the software development team to queue up. The traditional DevOps process is bound to be expensive. In China, NiO’s technical team even developed a low-code platform called red Rabbit to respond faster to internal IT needs.
Similarly, I’m sure Tesla would never be foolish enough to dispense with commercial software products altogether. Just because ERP can be self-built does not mean that all applications can or need to be self-built. Tesla, for example, would never have developed its own industrial design software, nor would it have needed to develop its own Office applications. These proprietary products should just be bought out of the box. Flexible choice is always the most rational choice.
Vijayan, who left Tesla in 2016, is said to have been working on a new start-up but has kept it a secret. I’d venture to guess that he was working on a zero-code application development product for large enterprises, and maybe he had a lot of complaints about Mendix back in the day.
The author is the founder of Mingdao Cloud, which is a zero-code/low-code enterprise application platform. The fact that MINGdao Cloud is not mentioned in this article does not mean that I do not want to promote mingdao Cloud for everyone to try. On the contrary, I find Mingdao Cloud to be a more user-friendly application platform than Mendix for Chinese users. Click to read the original article to visit Mingdao Cloud.