Building a Digital Ecosystem Platform from the Bottom Up

Posted December 22, 2020 | Industry | Leadership | Technology | Amplify
digi ground up
In this issue:


Thomas Gossler writes about how a digital ecosystem platform demands a solid architecture for data and infrastructure on top of which a network of stakeholders can engage in valuable interactions with each other. The journey from a pipeline business model to an ecosystem platform is no small feat, and Gossler shares the approach he and his colleagues at Siemens Healthineers took and the lessons learned in their seven-year digital transformation. In that time, their initial small cloud-based product has grown to a company-wide program for digital transformation of all of Siemens Healthineers’ major business cases. Gossler relates how the company learned to think in platform terms, avoided the “shadow IT” trap, and promoted exponential thinking to unleash the platform’s full potential. This case study provides many useful recommendations for others to follow in their own transformation journeys.


Technology advancements often enable new market entrants to disrupt existing pipeline business models and thus change the dynamics of entire industries. New market entrants do that by building their busi­nesses around a platform model using scalable tech­nology like the cloud that allows them to grow exponentially with very low marginal costs.

To counter this threat and to leverage such business models, large companies typically decide to start company-wide digital transformation initiatives with the goals of modernizing their ways of working and eventually establishing platforms of their own. Usually, the starting point is to build value-added services around their existing products with the help of a partner network and deliver them scalably to drive higher usage and adoption. Digital ecosystem platforms are all about interactions and value creation. Ensuring that the ecosystem partners benefit from the ecosystem helps in defending the existing product portfolio against new market entrants and preparing for disruptive changes in their industry.

A digital ecosystem platform enables interactions around core value units between users (producers and consumers) and is often composed of three logical layers: data, technology infrastructure, and network/marketplace/community.1 Not all companies are building their own platforms; many are hooking into one or more existing platforms and thus just contribute to one or more of these layers. Either way, the quality of data and the reliability, performance, and ease of use of the infrastructure is key for the user experience (UX) and for the ecosystem to flourish. It takes time to build such a mature foundation along the people, process, and product dimensions.

Approaches & Lessons Learned

Seven years ago, the company I work for, Siemens Healthineers, began exploring a new platform business model. We started by developing a small, cloud-based product that focused on key foundational aspects. Over time, this product has grown — bottom up — into a company-wide program for digital transformation of major business cases. This article describes the approaches we took and the lessons learned.

Start Small, Explore Opportunities Thoughtfully

There are many challenges ahead for a company that wishes to build its own platform. Digital transformation is different for every organization, which is why it is risky to just copy others. Before launching a costly change initiative for the whole company, it is vital to have a clear understanding of the “why” behind the effort. Embarking on the transition without a clear goal will only lead to exponential change instead of exponential growth.

When contemplating transformation, you should test your assumptions in a pilot project before betting the farm on them. Such a project should be chosen to have minimal impact on the company in case of failure, should be realistic to build with a small team, and should have high potential for growth.

When Siemens Healthineers launched its platform initiative, we started with a small project in a protected environment within the company that enabled us to explore possibilities and test our assumptions about predicted future changes in the business model. We identified and selected our potential business case carefully. The plan was to build a cloud-based product, from scratch, for existing customers around the globe. It would give them new, differentiating capabilities; offer the ability to leverage the latest technological innovations; and be offered under a freemium subscription model.

The objective was to discover what it takes to build, offer, and sell such a software-as-a-service (SaaS) solution with a fast time to market and a low total cost of ownership in a safe environment, where it would not compete with existing products. This approach — start small, learn fast, and focus on building a foundation with a small offering on top as a proof of concept — turned out to be a winning strategy.

Expect — and Allow Time for — One Learning Curve After Another

Although we chose the right strategy, the learning curve(s) turned out to be steeper and the planned learning phase much longer than expected — multiple years instead of one year in the end. And this was only for the initially small and isolated team of 25 people (which grew to about 60 over this period). For a bigger team, the learning phase would likely be even longer.

In the beginning, the challenges we faced involved tools and technologies. This led to a decision to keep the level of governance low and give the project team freedom to experiment and learn fast. For example, the team didn’t have to get up-front approval for all newly allocated cloud resources but was instead allowed to just create them and proceed quickly instead of having to wait for clearing of budget, naming conventions, documentation requests, and so on.

Soon the focus shifted to earning the necessary trust of customers in the company’s security and data privacy practices, which required not only technical changes, but also contractual and even procedural adaptations to comply with internal and external regulatory requirements and regional law. The longer-than-anticipated time to market led to heavy discussions about strategic investments because the initial business plan had called for an early breakeven.

Later, the low level of governance turned into another challenge because the costs for cloud resource consumption had outgrown the yearly budget earlier than expected, and we had to initiate a lengthy process of cleaning up the cloud environment and eliminating waste. Then, with a growing number of users and amount of feedback, the spotlight turned to operations after we realized how different the approaches are for delivering managed scalable services in contrast to products installed at scale. In addition, we had to revise our approach to storing and processing a growing amount of data to better support the use case scenarios and legal requirements.

Finally, we had to contend with cultural and political consequences once marketing and communications started to position the all-new offering prominently beside the existing product portfolio and probed the resonance on the customer side. People in the existing lines of business grew concerned when they began to see their customers express interest in the new platform offering, fearing they might lose sales of the products they were responsible for.

For all these reasons, we would have been well advised to plan more time for the initial learning phase.

Avoid Emergence of a Permanent Second Central IT Group

Although it makes a lot of sense to start a digital transformation initiative with a small, focused project in an environment of freedom with a lower level of governance and a strong business orientation, there are certain aspects on which you shouldn’t compromise. For example, it can be helpful to initially allow a kind of “shadow IT” for the pilot project to protect it from established governance entities that would fight the required changes in line with their responsibilities. But to prevent the accidental emergence of a permanent second central IT group, it is important to ensure regular informational exchange between both sides.

One goal of this exchange is to avoid unnecessary changes and possibly stay aligned with existing pat­terns and practices. Another goal is to trigger the timely buildup of necessary competencies in the existing central IT group. That way, it can support the new tools and technologies once the anticipated success of the digital transformation project leads to increasing demand throughout the organization. It is generally also a concern to define a company-wide cloud strat­egy early before separate groups start their own cloud initiatives independently and across different cloud platforms.

Furthermore, it is best to avoid a separation between company-internal IT use cases and external, customer-oriented use cases. There is no sharp division between these two in a platform business — it is a dynamic continuum. Establishing an enterprise architecture that considers both sides independently poses a risk. These aspects will be costly to change later and might cause unwanted redundancies, increase operational costs, and even impede the exploitation of new business models.

Enable the Needed Culture Shift

During digital transformation, an organization is typically trying to achieve faster time to market with frequent releases but without compromising on quality. A widely recognized way to achieve this is by adopting an Agile development approach and continuous delivery practices, including so-called DevSecOps. This abbreviation refers to an organizational setup that removes “walls” and fosters close cooperation of R&D, cyber­security (including data protection), and operations across all phases of the iterative development process.

Continuous delivery denotes a high degree of automation in software build, test, integration, and deployment and is key for being fast while keeping the quality up. It is important to understand that such an approach requires active support from top management and entails a change process of its own, consisting of changes in company culture that, of course, take time themselves.

After observing the pilot team struggle for a while, Siemens Healthineers decided to engage well-respected continuous delivery consultants over a longer period in all disciplines, covering even training for top management and pair programming with developers. This had a sustained positive impact on the way of working in the small team and later also in the broader organization when other groups followed the team’s example and started to adopt DevOps and continuous delivery practices.

Engage in Exponential Thinking

Migrating an existing classic application into the cloud without modification (lift and shift), for example, is often misinterpreted as an act of digital transformation. It might be an initial step on the way to a SaaS offering, but it is not even close to the actual idea and characteristics of such an offering. The “as-a-service” paradigm implies characteristics like permanent availability, pay-per-use, and low cost by leveraging economies of scale. None of these can be achieved by a simple lift-and-shift approach. This explains another necessary change of mindset from (only) traditional product pipeline thinking2 to (also) platform thinking.

A pipeline product is shipped to a customer and is used by one or more users independently from other such products shipped to other customers. A platform, in contrast, is a central service and is the basis for an ecosystem. Pipeline products can get connected through a platform, which may add value for the users of each individual instance of the product as well as for the users of the platform services. Such an ecosystem platform typically optimizes a few transactions between users instead of focusing on a set of features like pipeline products do. In combination, this enables new business models.

To leverage the full potential of this approach, it is advisable to teach all of the organization’s product owners about exponential thinking. Then encourage them to apply it in their daily work to identify scenarios in which connectivity to the platform or a new transaction on the platform can add value for the users (producers and/or consumers). More valuable transactions between users of the platform keep them engaged and attract new users. Such self-reinforcing effects can be acceler­ated by enabling and incentivizing activities that pull new users into the ecosystem. This can lead to exponential growth of users, transactions, created value, and revenue for producers and the provider of the platform.

Invest in Training & Maintenance to Prevent Innovation Overload

Digital transformation for most companies also means focusing more on their actual business by utilizing external services and components from other vendors or open source projects for non-differentiating things like standard IT. These other vendors are in the same situation, wanting to deliver value faster and more frequently and adapt to customer needs quickly. This results in an overwhelming amount of innovation over time and requires a systematic approach for continuous modernization.

Considering this constant investment into training and maintenance as a productivity loss and a drag on time-to-market goals is risky. This short-sighted mindset can lead to falling behind competitors, especially when they are better at leveraging the latest technology to offer their services at lower cost with higher flexibility. These rivals also become more attractive as employers because of their state-of-the-art technology and practices. To remain competitive, you’ll need to make the investments required to keep up with — and not be swamped by — continuous innovation.

Think in Platform Terms

A platform is different from a pipeline product. Organizations with a pipeline business model organize everything along a chain of product activities, including sourcing, sales, and service. Platforms facilitate inter­actions between users. This requires a different way of thinking and a different organization. It implies a clear user-centric design for keeping users engaged, while also attracting new users. Especially in the early days, users are almost as valuable for the feedback they provide as for the money earned from their subscriptions.

The best platforms are not born as platforms but as compelling products that eventually evolve into platforms over time. Sometimes it is necessary to integrate or even consolidate multiple products into a new service. However, many platform initiatives face the challenge of having to start out “empty,” which means without users and without previously created value. Even though this challenge can be overcome, it does mean that it potentially takes more time to make a platform successful than a product.

Achieving success with a platform may require a long-term strategy instead of a business plan that demands a short-term breakeven. The latter will cause recurring discussions about whether the platform endeavor should be stopped and puts the initiative under pressure, introducing additional risks like a lack of focus or reduced quality of the foundation. Low quality could be the result of lacking expected capabilities or growing technical debt that cannot be paid back.

Do Not Forget Operations

As mentioned above, users expect certain characteristics from a digital platform, such as permanent availability, responsiveness, and reliable interactions. Although these qualities are usually easier to achieve in a cloud environment, thanks to continuous delivery practices, it requires real-time monitoring and quick reaction to incidents. Furthermore, the continuous evolution of the software requires ongoing planning and adaptation of existing operational procedures or development of new ones.

In a pipeline-oriented business, operations are typically not a distinct discipline. In a platform business, they are. Recognizing that difference from the beginning (and acting accordingly) is an important part of digital transformation and will prevent negative surprises in the late phases of the service lifecycle. Depending on the reach of the offering, the target audience, and the use cases, a platform may require 24/7 support around the globe. Organizational structures need to be established to allow scalable handling of customer requests.

Siemens Healthineers has worked with its existing global support group to be able to provide first- and second-level support during typical customer working hours in all major world regions. New use cases in the platform may require extended support. It is advisable to introduce a cloud operating model with a service management orientation that defines a structured approach to defining, releasing, operating, and sup­porting digital services.

Ensure Data Protection by Design & Default

All sorts of software must adhere to the EU’s General Data Protection Regulation (GDPR) and the proper collection and storage of personally identifiable information (PII). That’s especially the case when it comes to platforms, which often want to enable the legal secondary use of customer or user data. This is where it gets challenging. The goal is to give every person control over which of his or her PII — if any — a system uses and to enable that individual to review and/or delete any or all of it.

GDPR specifically requires companies to protect the user’s PII through a “data protection by design and default” approach. This means that the software must be designed such that all settings and configurations are set by default so that no user information is collected without an explicit opt-in.

This mandate can come into conflict with the goal of enabling fast, easy interactions on a platform. We strive to handle these strict requirements in the software in a way that is compliant but not cumbersome for the user. At Siemens Healthineers, there is a central UX group that works together with all product groups to foster user-centric design and ensure a consistent UX across all products.

Establish a Comprehensive Data Framework

Besides complying with a comprehensive legal framework comprising regulatory requirements and regional law, it is also necessary to stay in control of where data is stored and how access to it is granted to whom, for which purpose, and for how long. The more data is distributed across many places, the more challenging this can be.

As part of its digital transformation, Siemens Healthineers is consolidating all systems and tech­nologies containing business, customer, or even clinical data into one highly available and scalable data lake. It features a comprehensive and similarly scalable access control mechanism on top as part of an overall data framework that augments the underlying data lake with additional services like data processing and analytics mechanisms and a data catalog. The latter enables simple data discovery across the enterprise.

Overall, the goal is a single and consistent approach to finding, exploring, accessing, and managing any kind of data, over its entire lifecycle, according to regulatory and legal constraints. Such a centralized approach to handling data is possible today with the help of cloud technologies, and it enables the buildup and later evolution of the platform.

Master Change Management

Establishing a platform in a large enterprise alongside an existing product portfolio implies significant change management. If this challenge is tackled by starting a platform initiative small and growing into it slowly, the probability is high that initial problems will also be smaller and that lessons learned can be applied along the way. This approach helps avoid large detours and ensures that the effort’s direction can be adjusted frequently based on feedback.

This method also helps defuse defensive reactions. Smaller projects are easier to accept and support in the company even if they have disruptive potential. A partial goal of a digital transformation should be the convergence or even consolidation of redundant products and services.

Key Takeaways

I hope that sharing how our company built our digital ecosystem and the experiences we had and the lessons we learned along the way will provide helpful guidance to readers from other domains. Here is summary of the key takeaways:

  • Before starting an initiative, understand the why and place end users at the center.

  • Beware of big design up front. Start small and explore business opportunities carefully.

  • Do not underestimate the time it takes to lay the foundation.

  • After an initial success, start developing competencies across the company right away.

  • Foster exponential thinking to unlock the initiative’s full potential.


1Choudary, Sangeet Paul. “The Platform Stack: For Everyone Building a Platform … and for Everyone Else.” Pipelines to Platforms, accessed December 2020.

2Van Alstyne, Marshall W., Geoffrey G. Parker, and Sangeet Paul Choudary. “Pipelines, Platforms, and the New Rules of Strategy.” Harvard Business Review, April 2016.

About The Author
Thomas Gossler
Thomas Gossler is a Certified Senior Software Architect and Principal Key Expert at Siemens Healthineers, currently assuming the role of Chief Architect for the teamplay digital health platform. He has worked in several different industries and roles, including a small startup company, long before joining the healthcare industry. Besides being responsible for the overall architecture and evolution of the teamplay digital health platform, Mr.… Read More