[mcherm]

Well, for instance I currently have a talk mostly assembled which would cover the way in which our team architected a system to allow small components of a complex stateful system to be deployed independently with minimal risk to the other components of the system. This could be classified under "Devops" or "System Architecture".

[ZenoArrow]

Okay, so if you had to summarise the lessons learned from overcoming the challenges you faced, what would you say they were?

[mcherm]

* Isolating the effects of one team's functionality from another team's is essential if each team is to be allowed to deploy independently.

* Doing so in a way that still allows your entire app to appear to be a coherent whole is tricky.

[ZenoArrow]

Thanks for your reply.

To be clear, to have a talk that makes an impact there should be general lessons that can be extracted from the specific experiences you went through. The title of your talk should address the general lessons rather than the specifics.

Based on what you've shared so far it sounds like a potential title for your talk is 'Coordinating Modular Development'. Is that the general idea behind the talk you had in mind?

[mcherm]

I'm not sure that is the exact title I would use, but it is certainly a good description of the content I would put in this talk. (My only concern with the title is that the talk I am envisioning would cover the specific technical details of ONE solution to coordinating modular development, rather than an overview of many possible solutions.)

I do, however, understand and appreciate your point that the title of the talk should put the talk in a broader context, particularly addressing why the listener would be interested.