Description: Informal summary of key outcomes from each session, with time for Q&A from the larger group
...
Rapporteur/Notetaker: Sarah
Notes from Session:
Where is the code at right now? What should the next implementation do?
- Next implementation needs a stable code base to start from
- Current "2.0" code base is really more of a development branch: not release tag
- Need to: clean up code, remove some code, etc. – a whole set of short-term activities that are targeted for completion by the end of 2015
2. To-be Architecture
Proposal
- TW proposed domain-driven architecture approach, based on micro services
- The group discussed this approach's pros and cons. There were differing opinion on the best solution.
- TW agreed to explore additional ideas - different commercial or open-source+commercial models, i.e. OpenERP with an add-on structure
- Would it be possible to incrementally move the code base over to this new architecture? likely no
- It would be quicker to rebuild the product from scratch rather than re-factor. Either way need to consider upgrade path.
- Proposal: take one module and do a POC using the domain-driven architecture approach
- Reporting & Analytics is a high-priority pain point – data warehouse module
- TW proposed they do a spike POC on new architecture
- Co-locating in DC or Seattle would be good.
Why Re-Architecutre?What - Would provide an estimate of how much time the rest of the work will take
Comments from larger group- What problems are we trying to
- solve: lack of extensibility; ease of development; accessibility for new developers to come in
- How will we measure success?
- Defining measures of success - product committee
- Technical committee raising andy trade-offs or options to the product committee
- Why are we having to pay for this again? Why didn't the initial implementation take this into account?
- This is common within enterprise applications - typically rewritten (often from scratch) 2 or 3 times before you get there
- Built as an application, mostly customized via the UI (this was understood to be the use case)
- Learned as community that the initial architecture didn't work in practice
- Example: Cote D'Ivore
- What about existing implementations?
- If the community says it is community supported, it's hypocritical to not support previous deployments
- No defined upgrade path (yet). POC could help understand this better.
- Will the new approach be the right approach? How do we know? What if we screw this up again?
- Re-Architecture Planning Considerations
- How much would it cost to change existing implementations to this version?
- How much time and money will it take to build the new version?
- Need visibility into key decision points
- Action Items
- Need to validate that selected architecture meets business goals Technical committee to raise trade-offs and present alternatives to product team - product team to verify and analyze how alternatives meet business goals
- Product and Technical committees to work together to define how we will measure success
...
- Need to identify any trade-offs
...