Setting up a repository for starting teams

By Han van Roosmalen Enterprise Solution/Application Architect

Session Recording

Downloads

Questions and Answers

Isn't it more reliable an automation-friendly to handle "AS-IS" - "TO-BE" using states, or some other attribute instead of package structure?

Yes, that could be. In many situations starting teams will start with nothing so using Phase or Version to keep their state is handy enough. When applying filters, it becomes really visual. If this works for the team it is probably wise to change this approach. I like to use Sparx as much out-of-the-box as possible, so no fancy things, those are for later.

How does the Expert handle the amount of data when using one master repository with hundreds or thousands of projects? We tried that approach but noticed significant performance issues?

Yes, everything works till a certain level. After that you have to switch to a different approach. The larger the scale the more "formal" work is required to keep the repos aligned. So, a structure of repos containing specific parts of models is required for large teams. Tools like the Reusable asset service might be handy to have then. Also, it is important to remember that modelling information is required for only a number of teams and not all of them. So trying to put everything in one basket is not the way to go. Think about arranging in domains. And only exchange the top-level information of that domain. Abstraction is king! here.

Great way of setting up EA. How do you find the repository handles large number of architects / elements? For example, > 200 architects, 50k data attributes?

Well there are things important as I tried to explain. First of all: Structure, Structure and Structure. Finding things in the repository should be self-guidance. Like: I expect to find elements about subject X there, so it should be there. As I said when you read a catalogue you know where to find something after you understand the structure. So, when required restructuring is necessary
So, if working with many architect’s time has to be said aside on how to make the structure work, now and in the future. So, keeping track of the quality of an element is becoming important. Promote elements that are verified.
About repository size. I have seen large repositories but hardly seen any performance issues (at least not for repositories that are in a DBMS in a "local" network. If have seen some performance issues on cloud-based repos (AWS and Azure), but less with those if put in the right data centre and with a more dedicated connection.

Please provide your contact details as we require any additional information?

If anybody interested, I could demo you some real repos and talk about the stories behind it. You can contact me via: han@eaxpertise.nl or call me +31610148933