Platform mindset
Capabilities over documentation
A platform mindset in software design refers to the approach of creating software that serves as a foundation upon which other applications, processes, or technologies can be built.
Agile manifesto values working software over comprehensive documentation. What it means in practice for architects?
Architecture should not focus on providing documentation on different standards and patterns but should focus on building capabilities that follow agreed standards by design, without additional effort.
It should be difficult to not follow architecture principles. Software teams should be building on top op standard capabilities such as:
- infrastructure
- aligned with technology radar
- provisioned with infrastructure as code approach
- aligned with company-wise network design
- CI/CD based on standard templates
- transparent code repositories
- standard quality gates
- security scanning
- versioning
- observability
- central infrastructure gathering logs and metrics
- central dashboards and alerting
- other cross-cutting concerns:
- Authentication and Authorization
- Configuration Management: Managing application settings and configurations in a centralized and consistent manner.
- Auditing: Tracking and recording user actions and changes to the system for compliance and analysis.
- Performance Monitoring: Measuring and analyzing the performance of the application to identify bottlenecks and optimize resource usage.
- Internationalization and Localization: Supporting multiple languages and regional settings to make the application usable in different locales.
- UI Design System and Components Library
How to implement architecture standards as capabilities?
Architects should stay close to the software development lifecycle in the organization.
Architects should have established ways of working with product owners / product managers / business owners, that would allow architects to contribute work packages related to standard capabilities to the backlog.
These work packages should be prioritized as any other work, based on business value. The bigger the organization, the more business value will typically come from investing in shared capabilities:
- reusability of standard capabilities enables teams to move faster
- expertise is centralized in the teams owning capabilities, that leads to more secure and robust implementation vs every team working for example on things like authorization framework by themselves
- improving operational excellence
- reducing infrastructure costs
Business teams focused on end-user functionalities and individual Product Owners responsible for those teams will typically see less value in working on shared capabilities, as making the capability reusable and adoptable by other teams usually requires extra effort that is not contributing to local goals.
That's why it is crucial to have allocated capacity, ideally whole teams, that focus on enabler type of work / shared capabilities. Product owners allocated to those teams will be able to more easily identify repeatable work that happens in other teams over and over again, and convert such work into reusable capabilities available out of the box. Architects can often play a role fo technical product owner in such teams.
If as an architect you agree to take such role, you should not forget about thinking about business value when prioritizing work packages related to capabilities.
Product mindset is needed also when building platforms / capabilities. It is crucial to think about:
- business value (how much time / money it will save? etc)
- adoption - how other teams can use it? that requires user documentation, code samples and internal marketing!
- rollout - how to switch existing production systems to use new capability?
- ownership, SLA guarantees and change management
Capabilities development cannot be prioritized only because it is a good technical practice. Business value needs to be proven as for any other things. Time spent on building capabilities is not free, there must be return of investment form that work in foreseeable future.