Summary: If you can define something (say an XML file) as your source code, then you could apply the LGPL license to your archetypes, and treat them as software libraries. Your archetypes can then be modified and/or included in any work (including a proprietary work), as long as that work are distributed with a source code version of the archetype.
If your primary scenario is vendor-controlled networked applications (e.g. a centralised web application) then the same argument applies to the GPL (which does not require sharing source code over a network).
Modifiable source requirement
It sounds like access to a modifiable version of the source code of an archetype (say an XML file) is one of your requirements. In this case you definitely want to consider AGPL, GPL (as Zizouz212 mentioned) or LGPL, rather than CC BY-SA. (CC BY-SA does not require source code access.)
From https://www.gnu.org/licenses/license-list.html#GPLOther :
The GNU GPL [and by extension the LGPL and AGPL] can be used for general data which is not software, as long as one can determine what the definition of “source code” refers to in the particular case.
Picking one of these licenses would mean that any derivative work "compiled" from the archetype must be bundled with the original archetype file (so that it could be modified and/or "re-compiled").
The GPL, LGPL and AGPL also satisfy your copyleft (share-alike) requirement.
Inclusion in other (possibly proprietary) works
If the archetype or derivative work is going to be copied into some independent work (another piece of software that is not a derivative work, but links to the archetype), and you don't want to place any requirements on that independent work, then the Lesser General Public License (LGPL) is what you're looking for.
With the LGPL, the independent work must still include the original archetype file and the source for any derivative work (see example below), but the independent work doesn't have make it's source available. It could be any license, including a completely locked-down proprietary one.
Note that the second work must also include some mechanism by which the LGPLed work can be replaced. (Easy examples are a DLL, if you're familiar with Windows, or a jar file, if you're familiar with Java.) This provision allows someone to take the archetype source file, modify it, "re-compile" it, and replace the "compiled" version used in the second work.
I am working on the conservative (risk-averse) assumption that the XML -> class transformation would constitute a derivative work. If it doesn't, your vendors are under no obligation to share even that part of their software source code.
I'm not sure that it applies, but it would be remiss of me to not mention "Why you shouldn't use the Lesser GPL for your next library" (an argument for preferring the GPL over the LGPL in most cases).
If you are looking at web/network applications then the same arguments apply to the GPL, and you could use that. (You do not need to share code over a network.) However, this would mean that any desktop or mobile software derived from the archetype must be GPL (this would not include a dumb client that is basically a web browser).
Let's say you define your LGPL archetype as an XML file, and vendor X uses that file as a template to create a Java class with getter/setter methods for the attributes, and basic database read/write functionality. They bundle a collection of such classes into a jar file. They develop an independent piece of software that links to this jar file, creates instances of these classes, processes and modifies them according to business logic rules, and calls the save method to store the results in a database (or to file or whatever).
When they permit me to install their proprietary work, they must give me: the jar file and the source code for the jar file (and probably the original archetype XML file too). They must provide sufficient instruction that a software developer could literally recompile the source code and get the same jar file. I am also free to inspect and modify the source code and compile my own jar file. If I break it, that's my problem. I have no access to their proprietary business logic.
(To be clear, the functionality I have described the jar file as having is trivial, it's the business logic that matters.)
I am also free to inspect the archetype itself, use it for research or whathaveyou, as long as I share my modifications, which I believe was your original goal.