Is there a best practice to manage library changes for MEGA BPMN (or Process)? At my company we have two libraries - one for development and other for production, but it is a nightmare to control changes made in the development library, exporting the objects to production, etc.
It would be interesting to group transactions in a version 1 and then "put in production" that version, while analysts kept working in version 2, and another team started working in version 3...
Solved! Go to Solution.
I'm afraid without knowing a fair bit more detail of your environment and objectives from using Mega its a little hard to give a definitive answer to this.
Libraries can and are used in a similar manner in many of our UK customers. We work on the basis in my team that we examine each of the customers specific needs and deliverables and work back from there to develop a governance structure and methodology that supports these.
I am also interested in this. In particular, how we manage the mutiple and potentially unrelated business change processes being considered. For example, one team may be looking at an update to a sales process in the next quarter and another in the purchasing process in the next half year. So it won't be as simple as saying 'take all of this library in to production'.
Another related question is whether libraries is the way to do this or whether environments or repositories is the way to go?
These are interesting questions and highlight that whilst Libraries are hugely powerful and useful, they do require some thought as to how they're going to be used in practice at the time of implementation and, really, to be able to give concrete advice requires more than a forum post...
Firstly, a bit of a generic note about Libraries:-
I've dealt with Libraries in a couple UK clients as well as using them in my own content and the most important thig to realise is that they are simply a method of segmentation and grouping content within the tool. Because of this the actual groupings used from client to client differe depending on how they see the world. Sometimes the company takes a "Zachmann-style" view of the world with segmentation between Contextual, Conceptual, Logical and Physical (as well as such classifications as "Transformation" ) and sometimes the line is drawn between disciplines so "Infrastructure", "Application Portfolio", "Process", etc. . Neither of these are right or wrong. What should be said though is that in neither case was the stable structure created on the first go - there were a couple of iterations where the initial structure was too simple and then it became too complex to be easily used and, well, now they work.
So in summary, there is no right answer to libraries and there will always be some trial and error because the first thing you need to do is work out what questions you're trying to answer in your organisation and once you know the questions you can re-group to structure your world in a way that it does answer your questions.
So, lesson over () we can move on to the joys of migrating objects between libraries (jtinoco's original post). For this, let's imagine we have 3 libraries which we'll call "As-Was", "As-Is" and "To-Be". "As-Is" and "To-Be" are pretty self-explanatory, but "As-Was" is where retired objects and descriptions (diagrams) go. We also have a Library called "Transformation", which is where we keep our Project portfolio modelled using the "Project" object. This is the key to the whole solution.
When deciding the scope/calculating the impact of your new project you connect the objects and descriptions to be replaced which, of course, are in the "As Is" Library to the Project Object and define them as Changed/Replaced/etc.. As you create the new content that's going to replace the current project scope then you connect them to the Project object saying they'll be introduced (you're free to choose your own words for these terms btw.).
This all means that on Roll-Out Day you'll have two sets of objects in your Repository - The first is a bunch of objects in your "As-Is" Library connected to your Project. The second is a bunch of objects in your "To-Be" Library also connected to your Project. The first set of objects can (after the appropriate checks to ensure the content is correct) be moved to your "As-Was" Library and retired (but is still somewhere it can be re-introduced easily if needed - always have a back-out plan!) whilst the objects connected in the "To-Be" Library can be moved to the "As-Is" Library. Because you have that core connection that makes the scoping of what you need to move easily queryable this is much easier than before.
You may find that rather than connecting every single object impacted by a project to the Project object you may be better linking the high-level Applications, Systems, Organisational Processes and Org-Units and using the concept of Boundaries, which is something that falls into the category of "Product Engineer Black Magic" and is outside my knowledge-scope.
Simon adds an extra dimension of fun to all of this by asking about sequenced projects changing the same object. The approach I've outlined above helps with this as one should question if an object is marked as being impacted by more than one porject then maybe those project teams should be talking to each other (I know, I'm an idealist...) and you will know that the project witht he later release will be changing not the object as it currently is, but how it will be after the last release. In this case I would say that there's probably a case for a "Big, Distant Delivery"-type Library. This should CERTAINLY NOT be in a different repository because then you'll lose all the value of impact-analysis.
That's been a monster, but I hope it helps,
edits to sort typos and grammatical errors