When building workloads in the FileMaker platform, what does it mean to be “Well Architected?” I mean, you can say that you are, but how do you prove it? Let us look at how that can be measured and how you might apply some of the same methodology to measure how well-architected your FileMaker workloads are.
Well Architected Frameworks
Other practices and cloud platforms have Frameworks that are a collection of best practices, design principles, and standardized methods to follow when architecting in those platforms. Those include AWS, Azure, and Salesforce, among others. Typically, those best practices are organized into key pillars like Security, Reliability, and so on.
Ideally, each pillar is generally considered to be equally important but can be prioritized according to business context and workload requirements. Further, there are industry-specific “Lenses” that contain additional collections of best practices that can be applied as necessary. These can be industry-specific or even custom-uploaded that may contain internal development standards, for example.
While FileMaker does not have a formally organized framework, there is a depth of knowledge base articles and published best practices. Especially when you take into consideration the contributions of the vibrant FileMaker community at large, there is a lot available.
Well Architected Tool
AWS, in particular, has a freely available Well Architected Tool that allows you to perform a review of your workloads. With that tool as a guiding principle, you can use the freely available FM Well Architected Tool from the GitHub repository: https://github.com/SoliantMike/FM-Well-Architected-Tool
The above tool contains a couple custom lenses that can be applied to your own workloads by using the tool to perform your own well-architected review. Reviews are not meant to be audits but more of a collaborative effort to improve the overall software system.
We humbly make this available to the FileMaker community to improve all FileMaker-related work in general. We are hopeful to find contributors interested in furthering the development of a FileMaker-related lens that can be used. This is an attempt to give back to the community in the spirit of “a rising tide lifts all boats.” We feel having a consistent way to implement best practices and standards benefits everyone.
It can be a lot of work to keep this up to date and adjust for newly available features and the like. You are under no obligation to use the provided lenses, but you can also use this tool to make your own.
In fact, Mislav Kos presented this as a session at Claris Engage 2025. If you missed his session, look for it when it is posted. Mislav has been instrumental in assisting in the development of this file, providing important feedback, and contributing to building a custom lens.
Custom Lenses
In addition to the included custom lenses, the tool provided in FileMaker (linked above) gives a user interface to author your own custom lenses as needed. These follow the format outlined by AWS for developing a custom lens for their Well Architected tool. Specifications for building the JSON for your own custom lens can be found here [https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-format-specification.html]
Building your own JSON by hand can be tedious and daunting. Using the tool to craft your own custom lens saves some time in helping to enter required fields and organize questions into pillars, providing helpful links and improvement plans, and evaluating risk rules. Once completed, you can export the custom lens in JSON format and import it into AWS’s WA Tool, should you want to do so.
You can also preview or use the tool to perform your own reviews. This gets at the crux of the purpose of using the tool in the first place. That is to provide tangible data in the form of milestones and improvement plans meant to track changes and measure progress over time.
Improvement plan
Creating a milestone marks a snapshot in time for a given workload review. Doing so logs all answers given and the risk assessment at the time the milestone was saved. Perhaps most importantly, saving a milestone also provides an improvement plan. By Identifying medium and high-risk items, a report is built indicating what items need improving and helpful text and/or links to remediate or make improvements.
With an improvement plan in hand, your team has actionable data that can be prioritized to identify effort toward making changes in your workloads. If you use project management software to plan development, this tool can be used to update such a tool and could even be modified to directly create tickets in a tool like Jira.
Takeaways
Hopefully, you will find value in using this tool and applying the best practices and principles in an organized and consistent way. Even if you do not, hopefully, you gain some insight in some respects and become more familiar with what best practices and design patterns are so they can be considered in your future efforts.
References
- Lens format specification in AWS WA Tool:
- FM Well Architected Tool from the GitHub repository:
