---
# System prepended metadata

title: ezyVet Architecture Plan

---

# ezyVet Architecture Plan
## Challenges
* Knowledge/communication bottleneck = too many dependencies = lack of clear responsibility = inability to give clear ownership = ineffective engineering
* Complex legacy code - Difficult to offload ownership, document, test and innovate. Lacking a strategy to tackle this.
* Messy data model, ad-hoc, needs to be untangled.
* Inconsistent language - Creates unnecicary cognitive load, creates barrier between engineering and the rest of the business.
* CI Team - pushing hard tasks that are large scope and short term resolutions

## Plan
### 0-12 Months
* Improve system architectural knowledge, implementing architectural strategy.
	* Make large architectural changes possible, through long term thinking/planning.
	* Improve our ability to develop & communicate our architecture.
	* Make architectural decisions based on a shared understanding. 
	* Ensuring projects align with architecture.
	* Ensuring architecture meets current requiremnts.
	* Ensuring architecture supports buisness agility. 
	* Work towards the sotfware architecture a key aspect of the buisiness strategy
		* Establish trust and support from the company for bold initatives.
		* Ensure system architecture supports the business strategy.
* Building a cononical data model.
	* Used for interservice communication including our federated graph gateway.
	* Requires that we define have consistent, unambigious language
* Ubiquitous language
	* Ensure the consistent use of terms within the UI, code, data, API & support documentation.
	* This will also require some untangling of ambiguios terms. e.g. invoice comments
	* This will improve communication in the organisation, which has been a no. 1 issue raised at strategy days. This is particularly important for us as we have a fairly rich set of features to reason about.
	* This will reduce cognitive load of our engineers, product, support, documentation & our customers, by using clear & consistent terminology that matches documentation.
	* Removing a lot of ambiguity is also a requiremnt cononical data model.
	
* Optimzing architecture for speed/scale
	* Modularising system, decoupling to create independent deployablility
		* Reduce feedback loop time.
		* Bridging the gap between engineers and customers.
		* Interchangability/feature flags for feature experimentation.
		* Releasing at different speeds based on requirements.
			* Core features can be more cautious. e.g. Invoicing, appointments
			* New features can release on demand.
		* Increase team autonomy. 
			* Reduce need for communication/alignment meetings
			* Increased ownership over feature.
			* Team have deeper understanding of domains.
			* Unconstrained/unburdened by the rest of the application.
			* Making teams responsible for their own components, having a direct feedback loop. Fix their own issues, paged at any hour to increase a focus on quality.
		* Building MVP for expermentation, not constrained by requirements of sustainability. 
			* If proven valuable we can rebuild to well tested, modular & maintainable code. 
			* If lacking sufficient value, we can drop the feature.
			* Minimal investment to validate, significantly less risk than building the wrong thing the right way.
		* Imporving ezyVet piece by piece.
			* As we learn new approaches, we can improve each module without the need to do a full rewrite.
			* We can experiment with new technologies, withing a limited scope.
			* We can potentially keep unsupported legacy components running, without polluting the codebase of activlly supported components.
	* Observability
		* As our architecture landscape increases in complexity, we need to also invest time in having good monitoring tools.
		* To support team ownership, and page those responsible. 
	* Telemetry
		* We need to invest in telemetry to ensure we have fast feedback from features, and allow us to iterate faster.
		* Allows us to have better insight into our users behaviours, this will also be improtant as we add pet owner support, whom we may have less intimate contact with.
	* 
* Optimise API for performance to support conversions as well as pet owner offerings.
* Open API, JSON Schema standards for REST endpoints
* Determine scope of pet owner offering
	* Design & build infrastructure
	* Adapt ezyVet users/permissions to incorperte pet owners(also suppliers, referring vets).
		* All of the above should be considered users.
		* Will likely need to add record based access control to do this well.
			
* Technologies/pardigms/frameworks to invest
	* Federated GraphQL API Gateway aka Data Layer
		* Allow us to provide a static interface for applications while changing the internal workings of our internal services, i.e. Stangler Pattern (Agility)
		* Reducing the blast radius of failures, API can function without other services, we can utilise caching for data retrieval. (Risk Managment)
	* Event/Messaging system 
		* Reduce coupling (Agility)
		* Reducing the blast radius of failures, sytems can funcution (Risk Managment)
	* UUID
		* Decouple database/internal database structure from the API(Agility).
			* If we restructure the database, it doesn't matter(Agility)  
			* If we use a graph db or nosql, the internal id does not matter(Agility, Performance)
		* Communicate the story of the record before it is saved to the database(Observability).
		* Mechanism to centralise data sources & replicate data between services to reduce communication loads(Agility, Performance).
		* Used for handling 3 way merge from concurrent record editing(Customer Value).
		* Remove forclass, forid construct, as the UUID provides something that is unique enough.
			* File attachments could use this as it has no concern of the user.
	* REST API Caching
		* We need to eliminate unnecicary database queries.
		* As we move to having services responsible for their own data we need to ensure that also provides a good cache invalidation mechanism.
		* The gateway will not know about this, but could eventually have it's own caching.
	* Contract testing
		* https://docs.pact.io/
		* Required to ensure we have stability as we move to having indpendent services.
	* Observability & Telemetry TODO
	* Reactive programming
	* TOGAF
	* DSL To Support thinking/capturing the right information speak the same language, mental template. BDD reuse for testing. Investigate

### 12-36 Months
* Async API
TODO: Get input from architects @ Idexx, understand what their current strategy is. I think moving to well defined micro services for any products we want to bring forward, particularly those we want to integrate, will help the enterprise be a large scale agile software company.
* Improve enterprise architectural knowledge, incorperate ezyVet into Idexx architecture landscape.
	* Discover opportunities to consolidate services
	* Align business & technical strategy
* Increased investment into pet owner application.
* Continued modularisation of ezyVet. 
	* Breaking up ezyVet into services 
	* Breaking up ezyVet site databases for each service.
		* To remove DB level coupling. 
		* Allow DB to be the right type for the purpose of the service. 
		* Horizontal scaling.
	* And scaling out software engineering.
* Machine Learning
	* Investiagate Machine Learning and opportunities for vet practices, pet owners & ezyVet.
	* Incorperating identified Machine Learning opportunities into our architecture strategy/technology roadmap. 


### 36-72 Months
* Consolidating ezyVet & Idexx services.
* Exploiting dig data & AI.