Techniques adoption and the growing attention to FinOps practices. Many commercial platforms provide tools that can consolidate and clarify cloud costs for business leaders. Some of them are designed to show cloud run costs to finance organizations or originating business units. However, cloud consumption decisions are usually made at the engineering level, where systems are designed. It’s important that the engineers making design decisions have some way of predicting the cost impact of their architectural decisions. Some teams automate this prediction early in the development lifecycle. Tools like Infracost help teams predict cost impact when thinking about possible changes to infrastructure as code. This computation can be automated and woven into the CD pipeline. Note that cost will be impacted by architectural decisions combined with actual usage levels; to do this properly, you need good projections of expected usage levels. Early and frequent feedback on run cost can prevent it from soaring. When the predicted cost deviates from what was expected or acceptable, the team can discuss whether it’s time to evolve the architecture. 5.Accessibility annotations in designs Trial The earlier accessibility is considered in software delivery, the easier and cheaper it is to ensure what’s built works for as many people as possible. Tools that help communicate accessibility annotations in designs help teams consider important elements like document structure, semantic HTML and alternative texts from the beginning of their work. This enables them to ensure user interfaces meet global accessibility standards and address common failures that are actually fairly easy to avoid. Figma offers a range of accessibility notation plugins: The A11y Annotation Kit, Twitter’s Accessibility Annotation Library and the Axe toolset’s Axe for Designers. 6.Bounded low-code platforms Trial We’ve always been advocates of writing less code. Simplicity is one of the core values underlying our sensible defaults for software development. For example, we try not to anticipate needs and only introduce code that satisfies immediate business requirements and nothing else. One way to achieve this is to create engineering platforms that make this possible on an organizational basis. This is also the stated aim of many low-code platforms surging in popularity right now. Platforms like Mendix or Microsoft Power Apps can expose common business processes for reuse and simplify the problems of getting new functionality deployed and in the hands of users. These platforms have made great strides in recent years with testability and support for good engineering practices. They’re particularly useful for simple tasks or event-triggered apps. However, asking them to adapt to a nearly infinite range of business requirements brings complexity. Although developers might be writing less (or zero) code, they must also become experts in an all-encompassing commercial platform. We would advise businesses to consider if they need all the functionality these products bring or if they’re better off pursuing bounded low-code platforms, either by developing their own platform as an internal product or by carefully constraining the use of commercial low-code products to those simple tasks at which they excel. © Thoughtworks, Inc. All Rights Reserved. 13