Latest news with #platformengineering
Forbes
a day ago
- Business
- Forbes
Platform Engineering At A Crossroads: Golden Paths Or Dark Alleyways
Following the golden path to platform engineering success is not without its pitfalls and pernicios ... More passageways. getty Automation equals efficiency. It's a central promise that's now permeating every segment of the software application development lifecycle. From robotic process automation accelerators that work at the user level, through encapsulated best practices applied throughout the networking connection tier used to bring applications to production… and onward (especially now) to the agentic software functions that can take natural language prompts (written by developers) and convert them to software test cases and, subsequently, also write the code for those tests. Automation represents a key efficiency play that all teams are now being compelled to adopt. As an overarching practice now carrying automated software development tooling forward, platform engineering is widely regarded as (if not quite a panacea) an intelligent approach to encoding infrastructure services and development tools in a way that means developers can perform more self-service functions without having to ask the operations team for backup. Platform engineering encapsulates the deliberate design and delivery of internal software application development tools, services and processes that define how software engineers build software. It's a holistic approach that covers the underlying processes, people and (perhaps more crucially of all), the cultural workflow mindset of an organization. At the keyboard, platform engineering is not necessarily all about implementing new technologies (although the omniscient specter of agentic AI will never be far away); it's about fostering consistency and a shared understanding across diverse teams. Devotees who preach the gospel according to platform engineering talk of its ability to lead towards so-called "golden paths" today. These can be described as standardarized workflow routes where infrastructure and configuration parameters for software development are encoded, ratified and documented. Often referred to as an 'opinionated' software practice (i.e. one that takes a defined path and does things one way, not the other way) that help individual software engineers stay close to tooling and processes that will be used by all other developers in a team or department. 'One way to think of a golden path is to imagine baking a cake. The steps required to bake a cake include pre-heating the oven to a specific temperature, gathering the right baking tools… and having the necessary ingredients. It's more than following a recipe, it's also making sure you use the right tools and techniques. If you want more people to bake the same cake, you find ways to become more consistent and efficient, explains Red Hat , on its DevOps pages. According to Derek Webber, VP of engineering at AI-enabled software quality engineering company Tricentis , platform engineering does have the potential to be golden, but it can also lead teams down a dark and dusty track into the Wild West. Why The Wild West? 'Yes, the promise of platform engineering lies in creating golden paths for software delivery. However, the absence of a traditional structured approach to software development often leads to what can only be described as the 'Wild West' of software development, particularly within large, scaling enterprises,' stated Webber. 'In such environments, each product team might independently craft their own unique pipelines, tools and processes. While this might afford initial autonomy, it inevitably leads to fragmentation. As organizations grow from a few dozen to hundreds or thousands of engineers, the tight-knit integration and level of shared understanding that characterizes a startup are lost. Developers become isolated, building 'unique snowflakes' of software pipelines that are difficult to maintain, understand and transfer knowledge across.' This fragmentation might be argued to severely hamper an organization's ability to be flexible and nimble, with an ability to move fast (remember the pandemic, yeah, that kind of change). Why would this be so? Because every new feature, every bug fix and even basic team reorganization becomes a slower and more laborious task. This can happen because of cross-team dependencies when everything is so formally encoded, it can happen because developers see their work as a project, rather than it being a product… and it can happen simply as a result of poorly documented tools in the platform engineering firmament. A fragmented coding landscape also obviously presents challenges to an organization's security posture, making it more difficult to ensure consistent compliance and vulnerability management across all services. DevEx, The Software World On Time 'The true power of platform engineering, especially when championed by a dedicated developer experience (DevEx) team, comes when it is able to balance two critical, often conflicting, objectives: speed and quality. This can be achieved by providing the necessary checks and balances that promote operational consistency and efficiency at scale,' said Webber. 'A core tenet of effective platform engineering is, therefore, the integration of testing from the outset to ensure quality is inherent, not an afterthought. While the industry has long advocated a 'shift left' approach, empowering developers to take on more testing responsibilities earlier in the development lifecycle, it's vital not to overcorrect.' Shifting everything left without considering the end-to-end product can lead to a different kind of fragmentation further down the line. The suggestion here is that platform engineering, via, through and under the auspices of a DevEx team, enables a more holistic approach. Webber says he's convinced that the DevEx team plays a pivotal role in creating a consistent testing framework when applied in the realm of platform engineering. It works by providing developers with readily available, uniform tools and processes. It bridges the gap in domain knowledge that often plagues large organizations, ensuring software engineers have the context needed to build robust solutions that actually work and actually scale. By providing pipeline automation, self-serve tools, environment management and established practices for observability and compliance, the DevEx team frees developers from the burden of figuring out how to build the pipeline and hook in tools. They can instead focus on what they build: the core product functionality. 'This shift in responsibility is transformative,' enthused Tricentis' Webber. 'When developers aren't forced to create their own 'special flavour' of every operational component, they gain immense speed and agility. They can move faster, knowing that the underlying platform provides reliable, secure and quality-assured foundations.' It appears that the consistency instilled by platform engineering, not just in tools, but in processes and mindset, becomes the bedrock of what this approach means. Webber and others agree that this could be particularly critical in an era where advancements like AI (and the future allure of can rapidly generate code, necessitating robust and consistent guardrails to maintain quality and security. CNCF Overview View 'We're seeing real traction in the CNCF ecosystem where platform engineering, when paired with strong developer experience practices, helps teams improve efficiency and avoid fragmented tooling. The goal isn't rigid standardization; it's creating shared, supported paths that scale with the organization. Especially as AI speeds up engineering development, having consistent, observable and secure platforms in a cloud-native fashion is what keeps innovation sustainable,' said Chris Aniszczyk , CTO, Cloud Native Computing Foundation, a global non-profit dedicated to promoting open computing standards and platforms. Will Fleury, VP of engineering at enterprise AI coding agent company Zencoder sees platform engineering as an opportunity and a challenge. "One squad [developer team], one technology stack each? That's a tax on every software development sprint," he observes. 'The real price of skipping platform engineering isn't the complexity it might add, it's the chaos that fills the gap if we do it wrong. Building and running an internal developer platform takes effort, but letting every squad roll its own infrastructure, compliance hooks and operational plumbing burns far more time, money and ultimately complexity.' Golden Path, Tunnel Vision? It's important to remember that the focus on internal workflows can miss a critical dimension. Platform discussions obsess over shift left (test early) but equally important is what Soham Ganatra , co-founder at Composio calls 'shift out' i.e. when a new service has to handshake with a payments rail or partner API. "If your platform can't make that external connection trivial, developers will tunnel under a paved road and the whole notion of a golden path collapses,' said Ganatra. He saus he has seen teams spend months perfecting internal developer workflows only to watch everything fall apart at the network boundary. 'A beautiful continuous integration and continuous delivery pipeline means nothing if deploying to production requires three Slack messages, two Jira tickets and a phone call to someone in a different timezone just to get firewall rules updated. The platform needs to extend beyond an organization's own chart; it has to anticipate and smooth over the messy realities of partner integrations, compliance audits and the fact that your biggest customer is still running Internet Explorer 11 in production," he said. Shared, standardized, supported software What this whole discussion aims to champion is not DevEx instead of platform engineering, but platform engineering with a crucial developer experience element in it to help avoid the use of isolated or custom-built tools in a shared, standardized and centrally supported ecosystem. For developers following the yellow brick road towards what they hope is elevation to a platform engineering golden path, we need to engineer people, processes and product just as much as we do platform. As the use of AI coding tools deepens across the software industry, it's actually the cultural human workplace factors that will now have an amplified effect on whether software projects succeed or fail.
Forbes
6 days ago
- Business
- Forbes
How To Build Scalable, Reliable And Effective Internal Tech Systems
In many businesses, platform engineers serve two sets of customers: external clients and internal colleagues. When building tools for internal use, following the same user-centered design principles applied to customer-facing products isn't just good practice—it's a proven way to boost team efficiency, accelerate development and improve overall user satisfaction. Below, members of Forbes Technology Council share key design principles platform engineers should keep front and center whether they're building for clients or colleagues. From prioritizing real team needs to planning ahead for worst-case scenarios, these strategies can ensure internal systems are scalable, reliable and truly supportive of the teams they're built for. 1. Minimize User Friction The one core design principle platform engineers should keep front and center when building internal tools is minimizing user friction by streamlining the journey and improving cycle time. Additionally, internal tools should include clear feedback mechanisms to help users quickly identify and resolve issues, along with just-in-time guidance to support user education as needed. - Naman Raval 2. Build With External Use In Mind You should always consider the possibility that an internal tool may eventually end up being an external tool. With that in mind, you should try not to couple core logic to internal user information. - David Van Ronk, Bridgehead IT Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify? 3. Design With Empathy It's important to design with empathy. Internal tools should prioritize user experience for the engineers and teams who rely on them. Simple, intuitive interfaces and seamless workflows reduce friction, enhance productivity and encourage adoption—making the tool not just functional, but loved. - Luis Peralta, Parallel Plus, Inc. 4. Focus On Simplicity Ease of use and intuitive design must be front and center when building internal tools. Features that are overly nested or require significant learning time directly impact productivity. This inefficiency can be quantified in terms of human hours multiplied by the number of resources affected, potentially leading to substantial revenue loss, especially for larger organizations. - Hari Sonnenahalli, NTT Data Business Solutions 5. Adopt Domain-Driven Design And A 'Streaming Data First' Approach Platform engineers should prioritize domain-driven design to explore, access and share data seamlessly. As cloud diversification and real-time data pipelines become essential, embracing a 'streaming data first' approach is key. This shift enhances automation, reduces complexity and enables rapid, AI-driven insights across business domains. - Guillaume Aymé, 6. Build Scalable Tools With A Self-Service Model A self-service-based scaled service operating model is critical for the success of an internal tool. Often, engineers take internal stakeholders for granted, not realizing they are their customers—customers whose broader use of an internal tool will make or break their product. Alongside scalable design, it will be equally important to have an organizational change management strategy in place. - Abhi Shimpi 7. Prioritize Cognitive Leverage Platform engineers should prioritize cognitive leverage over just reducing cognitive load. Internal tools should simplify tasks, amplify engineers' thinking and accelerate decision-making by surfacing context, patterns and smart defaults. - Manav Kapoor, Amazon 8. Empower Developers With Low-Dependency Tools The platform engineering team should strive to minimize dependencies on themselves when designing any solutions. It's crucial to empower the development team to use these tools independently and efficiently. - Prasad Banala, Dollar General Corporation 9. Lead With API-Driven Development Platform engineers should prioritize API-driven development over jumping straight into UI when building internal tools. Starting with workflows and backend design helps map data, avoid duplicated requests and reduce long-term tech debt. Though slower up front, this approach creates scalable, reliable tools aligned with actual business processes, not just quick fixes for internal use. - Jae Lee, MBLM 10. Observe Real Workflows Platform engineers should design for the actual job to be done, not just stated feature requests. They should observe how teams work and build tools that streamline those critical paths. The best internal tools solve real workflow bottlenecks, not just surface-level asks from teammates. - Alessa Cross, Ventrilo AI 11. Favor Speed, Flexibility And Usability You have to design like you're building a food truck, not a fine-dining kitchen—fast, flexible and usable by anyone on the move. Internal tools should favor speed over ceremony, with intuitive defaults and minimal setup. If your engineers need a manual just to order fries (or deploy code), you've overdesigned the menu. - Joel Frenette, 12. Ensure Tools Are Clear, Simple And Well-Explained When building internal tools, platform engineers should focus on making them easy and smooth for developers to use. If tools are simple, clear and well-explained, developers can do their work faster and without confusion. This saves time, reduces mistakes and helps the whole team work better. - Jay Krishnan, NAIB IT Consultancy Solutions WLL 13. Embrace User-Centric Design Platform engineers should prioritize user-centric design. They must focus on the needs, workflows and pain points of internal users to create intuitive, efficient tools. This principle ensures adoption, reduces training time and boosts productivity, as tools align with real-world use cases, minimizing friction and maximizing value for developers and teams. - Lori Schafer, Digital Wave Technology 14. Prioritize Developer Experience Internal platforms must prioritize developer experience above all. The best tools feel invisible—engineers use them without friction because interfaces are intuitive, documentation is clear and workflows are streamlined. When developers spend more time fighting your platform than building with it, you've failed your mission. - Anuj Tyagi 15. Bake In Observability Platform engineers should treat internal tools as evolving ecosystems, not static products. A core design principle is observability by default—bake in usage analytics, error tracking and feedback hooks from day one. This ensures tools organically improve over time and are grounded in real-world behavior, not assumptions, creating systems that adapt as teams and needs evolve. - Pawan Anand, Ascendion 16. Leverage Progressive Abstraction Progressive abstraction lets internal platforms scale with developer maturity. Engineers can start with guided, low-friction 'golden paths' for beginners while enabling power users to customize, script or access APIs. This balance avoids tool sprawl, supports growth and keeps platforms inclusive, adaptive and relevant over time. - Anusha Nerella, State Street Corporation 17. Streamline Processes Through Predictable, Intuitive Interfaces Internal tools must streamline processes instead of creating additional obstacles. Focus on clear, intuitive interfaces; fast onboarding with minimal documentation; and solid default settings that include advanced options for experienced users. Build in observability and self-service support, and strive for consistent, predictable behavior. - Saket Chaudhari, TriNet Inc. 18. Design Easy Authentication And Authorization Systems There should be ease of authentication and authorization. When building internal tools, you shouldn't design in silos. You must consider how many clicks it takes for an analyst, mid-call with a client, to launch what they need for troubleshooting. Seamless access, least privilege and contextual authentication aren't just security features—they're reflections of good architecture and thoughtful design. - Santosh Ratna Deepika Addagalla, Trizetto Provider Solutions 19. Engineer For High-Stress, Critical Scenarios A word of advice is to engineer for the worst day, not the average day. Internal tools become critical lifelines during incidents, yet we often design them for sunny-weather scenarios. When a system is melting down at 3 a.m. and the on-call engineer is bleary-eyed, that's when your tool's UX truly matters. Simple interfaces with clear error messages become worth their weight in gold. - Ishaan Agarwal, Square 20. Ensure Users Don't Need Deep Platform Knowledge Design for self-service and extension. Internal tools should empower teams to solve problems without deep platform knowledge. Engineers should hide complexity behind sensible defaults and include clean abstractions that allow extensions and clear documentation. Platforms succeed when others can build confidently without needing to ask for help every time. - Abhishek Shivanna, Nubank
