I'm looking for advice. For the past two years, I've been implementing Flare at our organization, which has over 10,000 employees. I've been helping to set up sites within different business units, and training folks within those business units to help maintain the content. We do not have a central technical writing team keeping this content updated for the business. Instead, employees and contractors help initially to build the site (move their content into it), and then the business maintains it after that.
So far, we have six separate projects that we're managing, plus a master project that I'm managing. More is in the queue.
My problem is that in looking towards the future, and knowing there is a desire to share information between these sites, I'm not sure the best way to handle the architecture. Should I combine all of these sites into one giant project, which makes sharing content very easy but adds some complexity to the permissions levels around folders within the project and size of space required on a person's computer when they check this giant project out of Subversion. Or, should I continue to have a collection of projects that I either don't share content between other than to link out, or do share content between but then need to set up an elaborate spiderweb map of shared content that we have to manage and communicate about.
What has your experience been? Have you worked in this type of environment and needed to make these types of architecture decisions, and what did you do? Any Pros/Cons, lessons learned, you can share?
Advice - Large Org Architecture Model for Flare
Advice - Large Org Architecture Model for Flare
Victoria Clarke
-
wclass
- Propellus Maximus
- Posts: 1238
- Joined: Mon Feb 27, 2006 5:56 am
- Location: Melbourne, Australia
Re: Advice - Large Org Architecture Model for Flare
No, don't combine them.
The last place I worked at had a similar size. We ended up with separate projects and used global project linking to share common information. We stored the source in GIT and used automation tools to trigger builds to publish to the output locations.
We tested a combined project at one point but did not have success with that.
We had over 100 projects for application help and process information - while some were small we had large ones with over 5000 topics.
We decided to keep them separate - was much easier for maintenance and managing what needed updating. Testing of the huge single project showed we needed way too many targets, and build times were much longer. And getting the build tags right was difficult to implement and to teach.
We had 3 major project templates as we had a few different types of help needed. These templates were used to base new projects and also used as global projects where we could share common content. We could easily share style sheets, glossaries, dictionaries, as well as common snippets for errors and so on. We also shared some common content topics. We found this worked really well. Depending on exactly what content you need to share, you might need to look at external resources as well as / instead of global projects for sharing. We found the sharing quite straight forward and not a "spiderweb map" at all.
We had up to 4 tech writers working on the Flare side, but lots of the content was generated by other staff in Word files that we imported. It is much easier for multiple Flare users to work on separate projects - experienced users had problems with coordinating updates so I would only want to get inexperienced people working on their own projects. Once GIT was in place coordinating was much easier.
The update cycles of all the projects was very different - some apps were updated each month while the older ones may have been changed only once a year.
So in the end, what drove our decision was the management of the creation and update processes, especially as sharing content is quite easy.
The last place I worked at had a similar size. We ended up with separate projects and used global project linking to share common information. We stored the source in GIT and used automation tools to trigger builds to publish to the output locations.
We tested a combined project at one point but did not have success with that.
We had over 100 projects for application help and process information - while some were small we had large ones with over 5000 topics.
We decided to keep them separate - was much easier for maintenance and managing what needed updating. Testing of the huge single project showed we needed way too many targets, and build times were much longer. And getting the build tags right was difficult to implement and to teach.
We had 3 major project templates as we had a few different types of help needed. These templates were used to base new projects and also used as global projects where we could share common content. We could easily share style sheets, glossaries, dictionaries, as well as common snippets for errors and so on. We also shared some common content topics. We found this worked really well. Depending on exactly what content you need to share, you might need to look at external resources as well as / instead of global projects for sharing. We found the sharing quite straight forward and not a "spiderweb map" at all.
We had up to 4 tech writers working on the Flare side, but lots of the content was generated by other staff in Word files that we imported. It is much easier for multiple Flare users to work on separate projects - experienced users had problems with coordinating updates so I would only want to get inexperienced people working on their own projects. Once GIT was in place coordinating was much easier.
The update cycles of all the projects was very different - some apps were updated each month while the older ones may have been changed only once a year.
So in the end, what drove our decision was the management of the creation and update processes, especially as sharing content is quite easy.
Margaret Hassall - Melbourne
Re: Advice - Large Org Architecture Model for Flare
I think will it depend a lot on the content itself - separate projects are not always a viable alternative to a single project.
Separate projects work fine when the content in each project is also largely separate from the content in other projects.
So separate projects don't work well when:
* You need to have links (xrefs and hyperlinks) between the content in those projects, because you can't easily have links between the content. You can't use xrefs at all, and hyperlinks must be set up as external links, which is a hassle and very prone to error.
* You need to produce a single output that combines content from different projects. Flare only supports project merging in HTML5 Tripane, but not in any other HTML5 skins.
* The outputs in your separate projects have a lot of shared content; e.g. they have shared topics, snippets, and other resources. Although you can import shared content, you have to weigh up whether the effort in setting that up is worth it.
A single large project makes sense if:
* The content (that would otherwise be in separate projects) is linked to each other (xrefs, links).
* The content (that would otherwise be in separate projects) needs to be included in the same output.
* The outputs from the project include a lot of shared content; e.g. they have shared topics, snippets, and other resources.
Separate projects work fine when the content in each project is also largely separate from the content in other projects.
So separate projects don't work well when:
* You need to have links (xrefs and hyperlinks) between the content in those projects, because you can't easily have links between the content. You can't use xrefs at all, and hyperlinks must be set up as external links, which is a hassle and very prone to error.
* You need to produce a single output that combines content from different projects. Flare only supports project merging in HTML5 Tripane, but not in any other HTML5 skins.
* The outputs in your separate projects have a lot of shared content; e.g. they have shared topics, snippets, and other resources. Although you can import shared content, you have to weigh up whether the effort in setting that up is worth it.
A single large project makes sense if:
* The content (that would otherwise be in separate projects) is linked to each other (xrefs, links).
* The content (that would otherwise be in separate projects) needs to be included in the same output.
* The outputs from the project include a lot of shared content; e.g. they have shared topics, snippets, and other resources.