Here at Fathom, our project implementations use an agile methodology that draws on aspects of various well-known methodologies without actually following a particular one. Below, we outline the elements of our methodology. We mostly avoid describing the actual product or technology being used as these may change from time to time, as we prefer new products and services. Nevertheless, the principles of our methodology are expected to be longer lived.
Our projects are implemented by small self organising teams. While all teams use a common approach, teams do have the flexibility to modify the detail of how they apply the methodology. As all of our developers are full stack engineers, they are all comfortable assuming different roles, as required by the task in hand.
A customer representative works closely with the team to define and re-define requirements and priorities as the project progresses.
Our projects use a task board. This is similar to the well-known Kanban boards. Usually, our teams use an electronic version of the board, linked to our issue tracking system, rather than a physical board. While we appreciate that there are definite advantages to a physical board, they are, in our case, outweighed by the advantages that an electronic board brings to remote customers or remote developers.
Projects are executed as a series of sprints. Normally, our sprints are one week in duration. Each sprint will complete and deliver a set of requirements, moving the project forward in a deterministic manner and allowing the customer to evaluate the current state of play before moving to the next sprint.
The sprint demo occurs at the end of each sprint, where the team will demonstrate to the customer, other team members and other Fathom staff what has been built during this sprint. A sprint retrospective and a pre-planning meeting occurs immediately after the demo. There, we determine if the output meets the objectives and do any priority re-ordering that’s needed before the next sprint.
We implement automated testing in all of our projects to ensure that features are tested on an ongoing basis and to guard against regression. We have a pragmatic approach to testing and don’t test for the sake of it. As such, we do not consider coverage to be a terribly useful metric and treat it cautiously. Our regression tests are generally executed as part of our CI/CD lifecycle that is described below.
Continuous Integration / Continuous Deployment or CICD is a process, whereby every proposed update to a software module or code base is automatically linted and tested against the rest of the module or code base (CI) and, if all tests pass, then the software is automatically deployed (CD).
Fathom uses CICD with all of our projects. Mostly, the fully automated deployment only deploys to a staging environment and there is a final manual push button to deploy to production. CICD also facilitates fast rollback in the unlikely event of an issue being discovered post deployment.
All of the software that Fathom develops is stored in a source code repository that is shared with our customers and available to them at all times during project development. Customers may choose to take control of the source code post development.
At the heart of the Fathom Way is a building blocks approach, where we create and maintain a library of re-usable building blocks that can be applied to many of our implementations. These building blocks exist across various project domains.
For example, infrastructure building blocks allow us to set up new infrastructure environments (test, staging, production etc.) quickly and in a repeatable manner. Our scripts set up DNS entries, SSL Certificates, storage buckets, CDN (Content Delivery Network), API Gateways, serverless functions, database servers, application servers etc. Project generators allow us to generate new skeleton projects for new APIs, new User Interface applications, new chatbots etc. Our project generators deal with standard functionality such as sign up, login, API security and other features in a repeatable manner.
Tooling is closely related to Building Blocks and our generators will put relevant tooling in place. Tooling helps us to preview and prototype our various project artefacts. For example, we generally prefer React for our User Interface development. React facilitates a component based approach. We use a tool called Storybook to allow these components to be previewed outside of the final application. This can be very useful in helping customers to visualise what the components do. Storybook also supports other UI frameworks i.e. Vue and Angular.
At Fathom, we believe in maximising software re-use, both for our own and our customers’ benefits. We embrace Open Source Software for the benefits it provides. We work with and have worked with many OSS packages and you can benefit from our knowledge of the better packages to use for particular use cases.
The Fathom Way ensures that the solutions that we build are secure both by design and in deployment. By deploying to the cloud, we take advantage of the best practices implemented by the chosen cloud provider, in terms of physical data centre and core infrastructure security. For example, AWS security standards and compliance certifications include PCI-DSS, HIPAA/HITECH, FedRAMP, GDPR, FIPS 140-2, and NIST 800-171, helping satisfy compliance requirements for virtually every regulatory agency around the globe.
By using Fathom’s re-usable building blocks and generators, we ensure that every project and project component builds from the same baseline set of secure components that we have regularly tested, verified and improved in many previous projects. With a common approach to authentication and authorisation across all of our APIs and User Interfaces, we ensure that security is an inherent characteristic of projects from inception and not an after the fact bolt on.
In those cases where our customers have chosen to carry out third party validation, our projects have achieved excellent security ratings, conforming the validity of our design choices.
Generally speaking, our implementations are targeted towards Cloud Deployment. Use cases vary between customers that are already fully cloud deployed to customers who we are helping to move their infrastructure to the cloud for the first time. In between, are the customers that have moved their compute instances to the cloud but are not yet reaping the rewards of the many high level services and fully managed infrastructure that are offered by cloud providers.
While we have worked with different cloud providers, we are an Amazon Select Partner - Read more here.