-1

We are currently redeveloping a monolith application into a micro-services architecture.

So we will split one application into 20+ modules. Today we use a project to track all changes to the monolith. But we are having doubts on how to proceed.

These are our options :

  • Should we make an Epic for each module that will detach from the monolith ? This has the benefit of allowing us to track time in a centralized manner, but when we will have 25+ Epics and that the modules continue to evolve it will start getting chaotic (I think).

  • Should we make a new JIRA Project for the module to track all changes ? This means that in the long term we will have to juggle with more than 25 JIRA projects to track all changes, and all timetracking.

I don't know if JIRA offers other options and JIRA Portfolio really seems like overkill.

Do you have any suggestions ?

Improve this question
1
  • Hi Joze, welcome to pm.se. As your question stands, there's no specific problem statement. Changing the application design architecture isn't a "problem" to be addressed by a jira structure changes. I bet you have problems today that you want to avoid in the future. That's because I think it's hard to have an answer in a public forum when the answer needs to come from your team. The community can however help in case you pinpoint specific problems. For instance, the tracking time on each service... have you considered using Jira Tempo and tag services as components? Cheers
    – Tiago Cardoso
    Commented Nov 2, 2019 at 10:19

2 Answers 2

Reset to default
5

One project, multiple epics

I don't really see how 25+ epics will be more chaotic than 25+ projects.

Don't overthink things. Redeveloping a monolith application into a micro-services architecture will be challenging enough for your team, they shouldn't also be forced to analyze things from an organizational point of view to see where each task goes where. There will also be cross cutting tasks, like building a service bus for the services to communicate with each other, which will impact all projects (if you go with multiple projects) but won't fit into any of them. Will you create another project for "Platform" stuff?

Only you can answer your question. Do you actually need to keep track of time, cost, etc for each of the micro-service? Does it actually matter? Do you have separate teams working independently on the micro-services? Or do you work on any of them during the same Sprint? If, for example, the CustomerService takes twice as much and cost four times as much than the ShoppingCartService, does it really matter? These are the kinds of questions you should be asking yourself.

Figure out what is important and then figure out what form of organization would best fit that. If you don't think about what you need, then you might just as well flip a coin.

Improve this answer
1
  • Thank you Bogdan for your input and insight. You are right, we should focus on our needs first and then decide the best approach. We have enough issues to think about as it is.
    – Jose Luis
    Commented Nov 4, 2019 at 8:51
1

I don't think there's a right or wrong answer to this question, but here are the main factors I would consider:

  • How many teams will share the work? If you have more than one team (especially if they might end up using different types of workflows), it might make sense to create different projects.

  • How distinct will the modules be? Are there some general categories you could group them into? Different projects for groups of closely related modules can be a way to get a better view.

  • Will you need to report separately on teams or modules? If so, again, separating into projects would make it easier to create specific reports.

A massive project with everything in it might be manageable for now, but as time goes and things get more complex, it might become messy. I feel creating a few projects might make it easier to keep track of everything, but from your question I don't think it's necessary to go all the way and create 20+ projects right now. Or new projects could be created as modules get detached from the monolith and "take a life of their own".

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.