Our team redesigns the legacy software and there are a lot of design meetings going on. Many of them are not very effective and lack good analysis of the proposed design. Is there any formal way to approach this kind of discussions to make them more effective? I heard about SWOT for example, but afaik it is used more for business projects.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as too broad by gnat, MichaelT, GlenH7, Kilian Foth, BЈовић Jan 17 '14 at 11:12
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
What you probably want is to define a set of interfaces that speak your business story, all the while ignoring the existing code, plug them in with a minimum rewrite, and then slowly reimplementing more and more of these interfaces. The formality in the process ends there, but I hope its practicality is obvious.
I assume you want the redesigned system to behave exactly as the legacy system, at least in the beginning. This means to need to capture the concepts and behavior of the legacy system first as precisely as possible. I recommend to create architecture models and use them for discussion. Everybody should have a good understanding of the modeling language you use.
Check out the methology we use at SAP, which is described in this 2 part blog post: http://scn.sap.com/people/bernhard.groene/blog/2008/01/09/how-to-communicate-architecture-technical-architecture-modeling-at-sap-part-1
Don't just create the block diagrams. I recommend to start with entity relationship diagrams and also add definitions of the entities. Then do the block diagrams - don't forget to describe protocol boundaries, and add a short description what each block does. Last thing should be one of the dynamic diagrams. Use the other diagram types if you need them.
What you will experience are lively discussions e.g. if there is a 1:* or a 1:0..* relationship between two entities. Or you will learn a lot about dependencies between components if you try to figure out where you could establish a system boundary, and so on.
If you use vague powerpoint drawings of your legacy system architecture, everybody will have his own interpretation and understanding, so you won't make much progress, and your new system will probably not reflect the legacy system.
I blogged a couple of years ago about never rewrite a system. Basically like Strangler Application it is about inserting transparent facades in front of interfaces to the existing systems and incrementally grow this redirection to the new system until the old system is no longer in use.
And never re-writing the whole system in one go as that will take way too long with no business benefit at least for a long while. You need to deliver business value along with replacing the existing legacy system.
As for the actual estimations, you can apply many time consuming in-detail estimations using various techniques. However they will all just be as wrong as a finger in the air estimate, just now wrong in detail as Dan North would say.
Create a few prioritised epics of what features are needed initially, break them up further if needed but not much more. Then just throw some order of magnitude estimates of various parts of the job (t-shirt sizes, 1-10-100 story points or days or whatever). Applying StranglerApplication and then deliver some tracer bullet stories to get a much better idea of the actual complexity and viability of the project.
Try going back to the basics:
Ineffective meetings are a sign of lack of purpose and commitment. Meetings should have a clear objective and commitment by those to reach it. For some of the best examples of how to run a meeting, look to professional sports. They are some of the best run meetings in the world (on time, 100% attendance from participants, commitment, engagement, clear rules and outcomes). Where possible try to emulate that.
A lack of good analysis is normally struggling to understand the problem. If you're not addressing the root cause of the issue, you are not really creating a solution. And if you are not creating a solution, you are just creating another problem.
There is a lot of process, methodologies and diagram to help with this process. OpenUP is not a bad place to look at methodology documentation if you haven't before. That should at least provide some structure and templates to implement some of the above. Another resource I find myself coming back to is Alistair's Awesome guide to pretty much everything.With those and the rest of the internet at your finger tips, you'll be off to a great start