In 5 years, 5 computer science students will be able to build a fully fledged ERP enterprise-grade in 5 weeks. Exactly, how the business wants and needs it. Wondering how are we going to achieve this? This article looks into the Humanitec' s 5–5–5 foresight and how to get there.
Even in 2019, the development of customized enterprise applications is a highly individual process. In most cases, either the IT department itself or — even more common especially in Germany — an external software development agency is building a one-off solution to satisfy individual business requirements. This process is vastly redundant and both, costly and resource-intensive. As corporates step into the next level of digitization, demand is growing by 42% CAGR¹ and we are at least 500k short in engineers by 2020 on a global scale². After years of experience as a consultant at McKinsey and as a former Senior Vice President at XING, I am happy to fully dive into this opportunity as CPO of Humanitec. Our vision can be summarized by the 5–5–5 foresight: In 5 years, 5 computer science students will be able to build a fully fledged ERP enterprise-grade in 5 weeks. Exactly, how the business wants and needs it.
Wondering how are we going to achieve this? Our approach is a combination of a revolutionary new IP model that allows developers to reuse and monetize microservices on our marketplace, Core-APIs that auto-detect and fuse these services, and deployment automation to mount them to an infrastructure. From thought to app in seconds.
Our deployment platform Walhall is using a scalable open-source microservice architecture and state-of-the-art automated deployment processes to make customized enterprise software development much faster, more reliable, and easier to maintain while keeping the intellectual property where it should be, with the developer and the customer.
Humanitec started off in a camp in Afghanistan, where our CTO Greg Lind hacked together a project management software for NGOs, called TolaData. TolaData’s open source version is rolled out in 35+ countries and has a paid solution on our platform. This microservice-based software helps NGOs to keep track of their initiatives and — even more important — the results for each of them. We built this software using a standard approach to modern software development: a dedicated developer team and 2-week sprints in a standard SCRUM approach.
From this 1st software product, we expanded into a second use case, field-force management software for a German corporation. While the two use cases seem to be quite different, they are using a very similar set of microservices in the backend. Like many other software companies, we started to reuse our existing microservices from the project management use case and modified them for the CRM use case. We ended up with two teams both working in 2-week sprints. Right from the beginning, we used the same core service in our backend setup and established frequent knowledge exchange sessions. But still, code reuse was nowhere close to where it could be and we struggled to align the two teams on a day-to-day basis.
The shared set of backend services and the inefficiencies in reusing our own microservices were the starting point to invest into a platform that would significantly increase reuse and could help to significantly speed up development time by providing automated deployment and a central approach to code management for individual microservices. By now, we are close to providing this platform, namely Walhall, to other software development teams in a closed beta.
We truly believe in the strategy to “eat your own dog food”, i.e., we are in the process of moving our existing software products to Walhall and the respective standardized microservices. By doing so we needed to fundamentally re-think our approach to product development and team setup. We used to work in a very common setup, with dedicated teams for each of our products (i.e., project management, field-force management, and the platform). Each team had its own set of meetings and tools, from the backlog all the way to sprint reviews and post-mortems. I quickly realized that this approach has a number of significant drawbacks:
There are a lot of interesting and partly well-tested concepts out there how to set up and manage a service-oriented development organization. The most interesting are matrix organizations and setups with tribes and squads. Unfortunately, we are lacking two important elements to easily implement solutions like that: (a) scale and (b) a large enough number of experienced senior tech leads. It will take us a while to develop these two elements but I am sure we will get there.
Meanwhile, we are in the process of implementing our own solution to a service-oriented approach that we believe will overcome the challenges mentioned earlier:
Especially the virtual service teams are very important for us. Combining engineers from the team developing the core modules with engineers that work on customer-specific UIs and making these teams responsible for generic microservices offers a lot of advantages: (1) it brings the frontend engineers working for any individual UI much closer to the platform, (2) it ensures that the product manager and the teams need to consider much broader use cases when developing a new feature, and (3) it significantly increases the re-use of designs across different teams.
Furthermore, we implemented some other changes to become more agile (e.g., one-week sprints) and allow for more focus on the most important topics. We try to keep complexity to a minimum. 1st results from this new structure are already looking very promising and we are eager to learn more over the next weeks and months to come. Please do not hesitate to reach out to me (email@example.com) in case of any questions or recommendations and stay tuned.