# 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.