If you simplify it, you can categorize these approaches into two main categories.
1. The expert, know-it-all, one-solution and non-questionable approach
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:
- Such a model became enormous, even for a moderate-sized company.
- The model tried to describe a moving target statically. It’s also the case that a task like that becomes much harder when the moving target is enormous rather than if it’s small.
- The big model was more or less generic and therefore context-free and in reality, very hard to use.
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.
2. The tinkering way, not know-it-all with a collaborative approach - Agile
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
