Documenting the re-write of our client management system

This and any subsequent or linked posts are living documents and are subject to change often.

The plan is to create a highly accessible ¹ monolithic system first ² that would include any other functionality that is needed at the agency and then peel them off as microservices ³. The “any other functionality” would include volunteer management, resource development, time sheets, central knowledge base etc.

  1. Vision of SLATE 2.0 
    [Client management and “any other functionality”]
  2. SLATE 1.0’s current scope and schema
    [Why it sucks]

  1. ^ By accessible I mean that it should be easily usable by co-workers who are blind and sometimes less technically proficient: as little clutter as possible to be picked up by screen readers and straight-forward design. Easier said than done.
  2. ^ Aw, yiss, the panacea that gets refuted on the same site: monolith first or microservices from the beginning. Although my situation is easier because (1) I know only the basics of microservices and (2) I still have to learn a lot of technology stacks in the meantime, not to mention (3) the overall complexity of figuring out how to model an agency of so many of inconsistencies.
  3. ^ This would be another good article on how to convert monoliths to microservices, besides the ones at [²].