Our goal is to increase the number of clients that we are able to help. There are two main ways to accomplish this:
-
Expand to New Markets - This includes expanding existing markets. This is accomplished by having easily configurable domain objects.
-
Saturate Existing Markets - Ensure that we have the capacity to service 100% of identified potential clients against the benefits and regions that we currently offer.
There are two main shortcomings of the existing software platform, which correlate to and inhibit the two approaches to the main objective.
- Benefit/Campaign Configurability - Benefit and Campaign configuration current lives behind an engineering wall. This adds a cumbersome middleman to creating and updating configurable content which delays expanding to new and existing markets.
- High Touch???? - Data can only enter the system and be processed via trained professionals (BOS, CBO counselors, etc). This greatly limits our ability to best serve interested parties to working hours, workforce capacity, and other manual processes.
Evolve systems out of existing systems. The preference would be in the following order:
- evolve current system
- breaking off into modular services inside monolith
- breaking off into microservice
- refactoring in place
- look to buy and integrate 3rd party
- building from scratch
Key ideas for this approach:
- Determine specific pain point, what we need to try to solve for
- From what we need to solve for, decide on the best plan of attack
- Use the existing/working system as a baseline to help guide the plan
- Address the plan in small, iterative, and immediately valuable units of work
Advantages of this approach:
- Lower the risk of wasted work by incorporating incremental changes into production significantly sooner.
- Does not allow for two implementations of common business processes to be in production simultaneously. Any existing process should immediately be decommissioned and removed from it's existing application before promoting a new system for that process to production. Evolving an existing system accomplishes this by definition.
- Deliver smaller features to production rather than larger features (which would essentially be product demonstrations of a hypothetical future). Product demonstrations can be subject to changes, delays, or abandonment.
- Each feature we ship to production will help inform future features.
- Generally considered the default approach to growing a monolith.
- Aligns closely with the Agile approach
Risks
- Bias towards existing implementations
Quick thoughts about various initiatives:
The primary reason that benefits and campaigns are not configurable is that they are defined in code. We would propose an incremental migration of hard-coded configuration into an updated database centered model. This is by far the most defined and clear objective currently and also has the most actionable and immediately valuable work output.
- Define an interim hybrid architecture that allows configurable content to remain hard-coded, but provides a facility for incremental portions of the configuration to be moved into the DB independently and transparently to the remainder of the system.
- Iterate over existing benefit configuration and convert one targeted configuration concern at a time. Update ALL benefits for one concern as one unit of work.
- Change the model as necessary in reaction to edge cases, and look for opportunities to generalize or share common chunks of configuration.
- Once a pattern in the configuration data storage format emerges, consider the simplest and most intuitive user interface to allow manipulation of that data.
- Look for opportunities to leverage learnings (code generation techniques, 3rd party tools) in response to the configuration requirements encountered.
- Allow the definitions of the 60+ existing PRSIM benefits drive the structure of the data required to communicate their configuration. Iterate over actual benefit definitions, and incorporate edge cases into the model as they are encountered, hopefully rendering them standard cases.
Direct client access to the platform would have the largest and most obvious effect. The first big requirement for this will be authentication and authorization. We need a lot more from product before we can go deeper into this, what are the problems we are trying to solve, what are the requirements, specifications, etc. A few ideas:
- Allow for unattended signup of client users (OAuth against external user databases such as Google or Facebook), separate from internal user creation (ActiveDirectory). These self service users would be able to add data into their own profile and possibly even be able to fully submit their own applications.
- Ensure client users are authorized to only view a single portfolio, and trigger a restricted set of operations (e.g. view but not generate letters) on that portfolio.
Another vague idea that we would need to converse with product more about. Initial thoughts include the oft mentioned chat bot. What other channels might we start thinking about?
- Direct Mail
- Telephone (IVR)
- Telephone (Live BOS)
- SMS Transactional
- Email Transactional
- Chat-bot (SMS and Web, automated and staffed)
- Alternate layout using React to provide main page frames (header, benefit status, interview, notes, letters) which initially pulls in traditional Rails partials.
- One frame at a time, develop React implementation, with alternate controllers to service their data requirements
We can evolve and expand on the existing data model. If we want to refocus all data around a client centric model, we can do that. The best approach would be to do this one migration at a time in the existing system. Quick thoughts on how:
- Migrate wholesale to new PostgreSQL DB (optional step, can also be done at any point).
- Clean up tables. Make sure each states DB is the same. Clear out unwanted tables, columns, etc. Reinforce relational integrity.
- Break larger tables into more specific domains.
- Historical Details:
- Convert into individual entity tables (people, household, incomes, etc)
- Create relational tables for each
We are already 90% of the way there. We can already run PRISM and access/shift portfolios between states and service sources. What data/portfolios I can see depends on my user permissions, which are already service source oriented. The only thing holding us back is deciding on if/can we consolidate on one DB or if we need to keep multiple DBs. The former would require a set of large migrations. The latter we have already addressed and had working in a staging environment.