The world of commerce is growing increasingly complex as new technologies can quickly enable disruptive business models and change how customers interact with us. Innovative products and services are introduced faster and with higher frequency in all industries. Disintermediation of supply chains causes old partners to compete and new partnerships to form. At the same time, millennials with completely different values and buying habits are starting to become a substantial part of B2C and B2B buyers.
All these are examples of complex challenges and phenomena that require constantly evolving business strategies and business models to stay competitive. Historically, most of the complex business problems have been solved with complex IT solutions that, in most cases, grow even more complex over time. Complex solutions are often monolithic in their approach and require huge budgets and a lot of time and sacrifice to get implemented in the organization. Say "big-bang ERP implementation” and most that have gone through one and survived will agree.
Race cars are optimized with one single objective in mind—to be as fast as possible. If we, for a minute, consider an organization as a race car and we think about what we need to do to make it fast and competitive, most of us will not think about adding weight or designing a hard-to-use cockpit. A race car is fast because it is stripped of everything that isn't necessary to reach the goal—winning the race. A race car's cockpit only contains the controls that are needed to drive really fast and provide the driver with an unobstructed driving experience. Adding controls in the cockpit for managing a front loader, or a towbar in the rear of the car, just doesn't make any sense as it will only increase the complexity of maneuvering and add unnecessary weight that will inevitably slow things down.
Complex and bloated processes and it's ugly sibling "the enterprise model," combined with all-in-one system support, adds time-consuming process steps and tasks, whether they are needed or not. Not only does complexity make things move slowly, it also makes things hard to change and is often the cause of inflexible organizations that leave employees disengaged and unmotivated. So not only is complexity the enemy of speed, but also the enemy of flexibility and innovation.
Amazon has been growing extremely fast and is now one of the largest companies in the world. Despite that, they are still moving and innovating much more quickly than their competitors in the traditional retail space. There are, of course, many reasons for Amazon's success, but complex processes aren't one of them. In a letter to shareholders, Founder Jeff Bezos wrote: "As companies get larger and more complex, there’s a tendency to manage to proxies. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations." When the process becomes “the thing” you end up with the all-encompassing enterprise model and its monolithic system support.
Instead, Amazon is laser-focused on what Jeff Bezos calls "True Customer Obsession." As the Amazon example shows, staying nimble and focused can help an organization move fast, grow quickly, and stay innovative. Simplicity requires a focus that encompasses everything, from organization and processes to system support. This is the opposite approach compared with yesterday's all-encompassing enterprise model, unfocused all-in-one enterprise software packages, and big-bang implementations.
Think of your organization as a race car and strip away the unnecessary weight of yesterday and focus on what's truly important. That way you can be the disintermediator instead of the disintermediated.
Johan Boström, Co-founder and Evangelist, inRiver
Recently we had a great day at our HQ with Nasry Angel from Forrester discussing our Roadmap and Visions. During the discussion, we talked about different approaches to architecting software.
If you simplify it, you can categorize these approaches into two main categories.
Here it is all about The Expert, and an assumption that this solution will handle everything from here to eternity. Or perhaps with this expert aura it simply becomes too many features within one solution, and too few that dare to challenge the solution. In the 90s this was a popular way of approaching software architecture. Trying to build and capture THE Enterprise Model that would solve everything and with that false expert know-it-all notion this could be done. Meanwhile, the business had to wait while the experts sat down and did their analysis, and after that it was done. The only thing that now remained was for anybody or somebody to implement their flawless design and voilà the one model was built.
To quote Jimmy Nilsson on why this did not work on the 90s and why it will not work in the future either:
This approach often leads to a big on-premise monolithic design. Over time this will not scale with new creative ways of solving real business challenges, but more be a war for preserving a state and design that was built and invented during the analysis and the creation of THE Enterprise Model.
Here it is all about knowing that we do not know what the future holds, hence we need to approach our domain with that notion. Understanding and accepting that everything we add will create complexity, so being very aware of what type of business challenge we are solving is paramount. Because we know that the domain and business challenges will change many times during the lifetime of our design. If other or tangent business domain opportunities arise, look for other services or collaborations to solve it. This approach of moving forward in small steps and failing fast, but with tiny failures that quickly will lead to a path towards an efficient design. In hindsight, this path will look crisp and clear, but without these small failures it would have been impossible to find it.
This approach often leads to a SaaS-based design with Microservices as base architecture, which often gives more flexibility and more purpose-built features . This often fits better within an organization. Because of the natural state of a IT-landscape where a lot of different systems and services often needs to coexist. To assume that ONE system would solve this challenge in the most efficient way is not very realistic. If you on the other hand are working with modern service-based solutions, this will put you in a much greater position to be efficient in maximizing the effect of your investments.
A couple of weeks ago me and our CEO, Niclas Mollin returned from San Francisco after attending the great event SaaStr 2017. The reinforced insight we left with was that all inRiver customers deserve a modern approach to delivering software. We have, for a long time, believed in a Cloud Service Approach, but with that transition we had to go through a lot of changes. To get where we are now, we have “killed a lot of darlings” on the way. With this I mean things that were thought of as absolute musts in our solution, and could not be changed. As always with these situations, time and commitment will help you in finding an alternate route. In this change process, The Microservice architecture is something that has helped us in our ambition to ― together with our community ― create an easy-to-use and fast-to-scale SaaS approach. The feedback we have received is very positive, the agility we can provide and the speed of change our design offers is very appreciated by our customers.
Think big – Start small - Scale fast
Jimmy Ekbäck, Executive Vice President Products & Services, inRiver