Iceberg Method for digital development

The idea of the iceberg concept is that the visible part, the user interface and services that the customers are seeing, is actually the minor share of the big picture. And this applies to boosting the customer experience as well, looking at the tip of the iceberg is not enough. To ensure a delightful user experience, a lot of work is needed under the surface. Very often the digital business is wrongly interpreted as polishing the topmost layer.

ESB & monolithic systems

At the bottom you have the legacy systems, Enterprise Services Buses, ERP, CRM, WMS and so on. These are of course basic building blocks of enterprise architecture. They are many times needed in ramping up your digital basic capability and core business “must-have” operations but this is not where you should be pouring your development budget into.

However, there’s one very important and valuable aspect to these systems: master data. If your master data is not in good shape and well-structured, you need to fix that first. Otherwise everything else that you will build on top of it will become that much harder.

It is hard to scale the development efficiently if you’re investing in these systems nowadays. Big systems, big cost.

Microservices and APIs

You should be offloading functionalities from the legacy systems to microservice and API layers. You still need the legacy systems on the bottom layer but use them via APIs and do the heavy-lifting and customization on the microservices layer. Building services this way makes them more manageable, easier to develop and flexible. This also prevents vendor lock-in and enables fast go-to-market times for new capabilities. You don't want to bloat your old monolithic systems, because otherwise they become a burden too heavy to drag along and within a reasonable budget, and above all very hard to replace/update.

Frontend

The frontend can be pretty much anything: self service POS system at the store, native application, web application, you name it.

The one top practice with frontend is component libraries. Use component libraries to create a consistent user experience in a multi-channel environment. In essence to simplify the case, it means that if you have a red “add to cart” button in all your digital channels, it really should act and behave the same in all the channels. You don’t want to build that button multiple times and that’s when the component libraries come into play. The best way to approach this is to build a unified library of UI elements and update it in a centralized manner.

UI & Design

This is the visible part that users usually see but there are multiple layers beneath enabling this layer. Here the key takeaway is using a design system. Combine it with component libraries, and develop them hand in hand targeting all team efforts to the single source of truth to avoid “rotting”(uncontrolled changes happening ad hoc) of different systems and UIs from customer perspective.

People & organization

The iceberg is a reasonable and sound technology approach, but nothing happens without people. That’s why the iceberg is surrounded by people and the organization. This is one of the most complex areas in IT. But if you get this right, everything else becomes a lot easier.

At best, a good organization can achieve all of the following:

• Cancelling noise from IT
• Focusing on continuous development instead of one-time projects
• Finding and allocating the correct competence for modern IT landscape
• Creating a clear path from idea to implementation
• Enabling business & IT cooperation through portfolios
• Efficiently prioritizing development items against budget

At one of our customers, St1, where we have utilized the iceberg method, the key for success has been business & IT dialogue. There we have helped create fora and routines where business and IT people meet and talk about the digital roadmaps. Too often the setup is that IT is doing their tech stuff at their own track and business is planning their roadmaps separately. Putting these two forces together, that’s where success comes from. It’s hard, there’s no question about it, but worth it.

The presented layers become alive, when the following principles are used. In a way, these can be deducted from the iceberg layers and interaction, but it is better list these because in many cases the principles might not be obvious.

UX is built on top of multiple layers

In order to get the full UX right, the layers beneath must cooperate and function seamlessly. Reaching this target and fixing the stack below often takes time and effort but once it’s done digital development after that is very efficient. You’ll have faster launch times for new services than ever.

Separated layers also bring flexibility. You can easily change a UI component or frontend client without hick-ups. Same goes for backend microservices, the layered structure enables easy changes. You can even change a base system like CRM but it does not cause any problems because all communication goes through APIs.

Projects and services can be seen as vertical lines going through each layer. However, each project should somehow contribute to the whole iceberg. Projects should have more value than just the substance outcome, instead, they should always advance the platforms in some way.

Do not unify systems, unify technologies

Modularization and separation of components can be done using same technologies. Services and systems can be separated into smaller parts but you do not need 10 different technologies to implement them.

This unification should apply to all layers of the iceberg. Pick one microservice framework and all development teams can collaborate using that solving common problems and accumulating your stack of digital goods in the long run.

On the frontend level you can unify technologies by using the component libraries. The same principle also applies to the design layer where the design system helps continuously grow the design value in a unified and future-proof way.

Focus on the iceberg, not legacy systems

Monolithic systems such as ERP are often cost-intensive but innovation-lacking. On the other hand these are often must-haves for operations and solid blocks to build digital competencies on, so completely getting rid of them at once is not a good idea. Still, rapid development and prototyping happens within the iceberg tech layers towards the top.

The new digital development stack is a way out from the slow pace of monolithic system development. You should be releasing twice per week, not twice per year!

Implementation size, scale and timeline can vary

Not all companies need the same setup when it comes to competencies and team size. Still, all the layers of the iceberg are present in some form or another in all companies. It’s important to remember that the correlation between efficiency and team size is not linear. The scaling of this kind of development will still be hard to do.