What are platforms, and do I need one?
Back in the day, when I started my software engineering career, most of the custom enterprise applications were built using a single tech stack. A few of the most common ones were a Java stack with an Oracle database or a Microsoft stack with an SQL Server database. At that time, a typical enterprise system was a product family of desktop applications with a two-tier architecture organized in a monolith codebase.
Service
Industry
From frameworks to platforms
Since enterprise applications typically have shared concerns, such as handling database connections, localization, authentication and authorization, logging, release management, etc., the standard approach was to create a foundation framework for these capabilities to create a consistent architecture. Although this approach works reasonably well, the downside is that it often creates a steeper learning curve to understand its conventions and structures and might limit the ability to use more modern approaches.
Luckily, most of these development concerns have already been solved in modern application frameworks such as Spring Boot or ASP.NET. In most cases, those frameworks already offer most of the foundational capabilities, and they are extensible with commercial and open source to solve more specific use cases.
Software architecture has evolved a lot in the last 20 years. Instead of monolith applications, mainstream enterprise applications are collections of distributed (micro)services that communicate with each other via HTTP and are deployed to the public cloud. The same type of architecture is also widely used in commercial SaaS applications, and when done right, the distributed nature of the architecture is not visible to the end user.
Although distributed application architectures are more flexible and scalable when appropriately done, they also have tradeoffs with architecture and deployment complexity. While solving the increasing complexity of emerging architectures, the software industry has coined a new term, Platform Engineering, which is typically a set of services, tooling, and guidance for engineers to autonomously build new capabilities that meet domain requirements in a repeatable way. At its core, it is not very different from the old-school framework development, and the purpose is the same: let engineering teams focus on the application logic and streamline deployment and operations while maintaining alignment with the ecosystem.
What are internal development platforms and platform engineering?
The idea of Internal Development Platforms (IDPs) has roots in the original platform-as-a-service (PaaS) offerings like Heroku and Cloud Foundry and the internal development platforms built by large tech companies such as Google, Netflix, and Spotify. The fundamental goal is to reduce the cognitive load on developers by creating opinionated, pre-configured workflows that developers can use to deliver value faster while avoiding repetitive infrastructure setups.
Also, mainstream cloud providers like AWS, Azure, and Google Cloud have their own PaaS offerings. The latest generation of their PaaS products are container-based and serverless, with a usage-based pricing model that almost entirely abstracts away complex parts such as container orchestrations. PaaS services have an easier learning curve, but at the same time, they are less flexible and may not be cost-efficient when used at scale.
In addition to the general-purpose PaaS services, there’s also a movement to more specialized and higher abstraction level platforms, such as integration, low-code, and data platforms — some attempt to democratize the development process and allow more people to contribute. Good examples of these services are Microsoft’s Power Platform and Microsoft Fabric, which many Nortal customers are adopting now.
In most cases, internal development platforms are not built on bare metal; they are a combination of capabilities to deliver specific workloads. For example, an integration platform can provide capabilities different from those of a data platform. Still, both should offer APIs and self-service capabilities to allow multiple teams to deliver value independently without the ticket-driven approach common for traditional IT infrastructures. For the solutions running in the public cloud, the IDP can be a curated list of available capabilities or an enabling layer for on-prem infrastructure to build cloud-native services.
In this context, the platform engineering team is responsible for building, maintaining, and supporting the IDP for the rest of the organization. To some extent, platform engineering is an evolution from DevOps practices; instead of building non-functional system qualities in an ad-hoc manner, platform engineering is an attempt to productize and standardize these capabilities on the platform.
Team topologies and Platform Engineering
Any platform engineering initiative success heavily depends on the organizational structure and how teams interact. The principles of Team Topologies, a model developed by Matthew Skelton and Manuel Pais, provide a valuable framework for aligning teams with platform development and consumption.
The basic idea of team topologies comes from Conway’s Law, which states that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”.
In simpler terms, how your teams communicate directly influences the architecture of your software. The Team Topologies leverage this idea by offering practical advice on deliberately structuring the team to reflect the desired architectural structure. This approach is often called a reverse or inverse Conway’s Maneuver; instead of fighting against Conway’s Law, it leverages it to drive the desired change.
Team Topologies identifies four fundamental team types:
Stream-Aligned Teams
These teams are responsible for delivering end-to-end value to customers. They should be able to work autonomously and own their services throughout their life cycle.
Enabling Teams
These teams provide specialized expertise and guidance to Stream-Aligned Teams, helping them adopt new technologies and practices. They act as consultants and collaborators.
Complicated-Subsystem Teams
These teams handle complex or specialized subsystems that require deep expertise. They build and maintain components that are difficult for Stream-Aligned Teams to manage.
Platform Teams
These teams are responsible for building and maintaining the internal development platform. They provide the tools, services, and infrastructure that Stream-Aligned Teams need to deliver value.
Download the product sheet
for GenAI Regulatory Assistant:
The most critical team types in platform engineering are Stream-Aligned Teams and Platform Teams, where Stream-Aligned teams consume the platform and deliver business value. The platform team maintains and develops the platform itself.
Adopting Team Topologies' principles helps define clear responsibilities and create necessary feedback loops between the teams for continuous improvements. Team structures should not be set in stone so the team compositions can adapt when the platform matures or the business changes. Many times, it also makes sense to switch roles once in a while to understand different aspects and needs of the platform. For example, if applicable, it is helpful for platform engineers to work alongside the stream-aligned team to understand the pain points of consuming the platform.
Do you need a platform?
Creating and maintaining a platform is not a project but an internal product line that requires the same practices, principles, and lifecycle management as any other software product. This is a significant undertaking, so before deciding to build your platform, it is crucial to determine the benefits your organization seeks to gain with the platform and how applicable they are to your domain.
In general, platforms seek to benefit from economies of scale. The most obvious candidates for platforms are ecosystems with potentially multiple applications that require consistency or fewer applications but a considerable number of environments to deploy them.
A good example of a platform with multiple applications is an application suite that covers a specific domain with small, focused applications that aim to provide a consistent user experience. This consistent user experience gives the illusion of using just one application, although technically, different sections on the screen might come from various sources.
An example of many environments is an edge platform where applications can be deployed and updated automatically to the whole fleet of IoT devices or other edge services.
In short, consider these questions to determine if a platform is right for you:
- Do you have multiple development teams working on related projects
- Are you experiencing significant duplication of effort in infrastructure setup or deployment?
- Do you want to enforce consistent security or compliance standards across your applications?
- Do you have a large number of deployments?
- Are you going to be deploying to edge locations or devices?
- Do you need to provide consistent user experience across multiple applications?
The cost of not having the platform when you need one, is increased development efforts due to duplicated work, inconsistent security postures, and a slower time to market.
Where to start?
Regardless of the platform type, platform engineering seeks to deliver value more efficiently. To be truly impactful, this requires both strategic and technical thinking. While the technical side is concerned with having the right tools and infrastructure, the strategic side must align the platform with business goals, operational efficiency, and future growth.
Ideally, a good starting point should be well-understood, not overly massive, and offer measurable outcomes. This is always a balancing act between complexity and business value; making it too small won’t provide tangible benefits but making it too big too early increases the risk of failure. Either way, failure means losing the organization’s momentum. Therefore, it is best to start with an MVP platform to receive feedback and improve based on actual needs.
My advice is to come up with something that:
Aligns technology and business goals
Platform engineering isn’t just building tech to deliver even more tech but enabling the business to move faster and more efficiently. In essence, the question is: What does the business want to achieve, and how can technology help to get there?
Questions:
- What are your long-term goals (e.g., faster time-to-market, create new product offering)
- Can the platform reduce existing costs?
- Do you want to tap into new revenue streams? (e.g., monetize existing assets, utilize a partner network)
- Can the platform deliver a better customer experience?
Example: If a business goal is to enter new markets quickly, the platform should support scaling and deployments to multiple regions with reasonable cost and effort. Depending on the target regions, this might impact the platform for compliance and regulatory reasons.
Operational Efficiency
Very few companies worldwide don’t need to care about operational efficiency; it is not just about margins but also about staying competitive and providing better service at lower costs. Therefore, it makes sense to consider operational efficiency very early in the project.
Strategic goals:
- Normalizing the tech stack helps manage the technical debt
- Reusable assets help build new capabilities with lower costs
- Standardized software delivery to reduce operational costs and optimize resource usage
Example: A standardized cookie-cutter approach to delivering new applications means that each team creates the applications similarly, reducing errors and speeding up the delivery process.
Is future proof
Building a simplified user experience over a collection of open-source tools and various services requires pre-made decisions and defaults that limit the options that platform users need to make. The approach has a built-in trap; each simplification is one step away from the base platform and its APIs, and even when it seems like a simplification to the makers of the platform, it will be another layer of abstraction that consumers must learn. In most cases, it makes sense to use well-known standards and protocols.
Strategic benefits:
- Ability to react to market changes
- Ability to adapt and integrate with new technologies, like AI
Example: Modular architecture that communicates with other modules via well-defined APIs is adaptable to change, whilst the normalized platform allows for the maintenance of operational efficiency.
Conclusion
As with all architectural decisions, the platform approach has trade-offs, and it is impossible to recommend a one-size-fits-all approach. Well-executed platform architecture can offer multiple benefits, such as accelerated delivery, TCO per application, and consistent user experience. On the other hand, the platform has lifecycle costs, requires good engineering skills, and it is not easy to calculate the ROI beforehand. However, by focusing on measurable outcomes and continuous improvement, you can demonstrate the value of your platform over time.
To start your platform journey, it's crucial to approach platform development strategically and understand your organization's specific needs and goals. By starting small, focusing on measurable outcomes, and prioritizing alignment between technology and business, you can harness the full potential of platform engineering and build a foundation for sustainable growth. With the rise of AI and automation, platforms will become even more intelligent and adaptable, further streamlining development and operations.
Get in touch
Nortal is a strategic innovation and technology company with an unparalleled track-record of delivering successful transformation projects over 20 years.