Regarding Frameworks and Implementations
Hello Team,
Following scenario, if you can suggest me something of whats a better approach:
Consider A,B,C,D as 4 different LOBs (implementation rulesets). A, B, and C depend upon framework F1 (ruleset with ~10000 rules) while D depends on framework F2 (ruleset - mixture of rules from F1 + new 10000 rules ~ 20000 rules).
The requirement is to defragment F2 to remove its dependency on F1 and take out those 10000 rules specific to implementation D.
What's better?
1. Move these 10000 rules to Implementation Layer D?
2. Create a New ruleset which could exist below D and contain all these rules?
Any thoughts/ideologies or opinions are welcome.
Kind Regards,
Ashish
Pegasystems Inc.
US
Ashish,
I don't think I have a strong opinion about which approach is "better" though I don't really understand the underlying business need you are trying to address. I guess the big question in my mind is, how many of the rules in F1 do you *really* use in F2? Either way, if you move them in bulk you still have 10,000 rules, many of which you don't want cluttering up your system. Or if you are using the majority of them, why do you need to break the dependency? What is the harm of keeping it? What do you gain by removing it? Is F2 being moved to its own server with its own database? Your different lines of business users should have their own access groups so they should already be restricted to just the applications they have a business need to see.
Thanks,
Mike
Capgemini
NL
Hi Mike,
Thanks for your response. Following details to your questions:
How many of the rules in F1 do you *really* use in F2? --- 65-70% rules of framework F1 are exactly the same in F2 are being used by the implementation D
Why do you need to break the dependency? --- To explain you clearly, this needs to be done to clear out redundant rules in F2 (which are exactly same as F1). By dependency, I actually meant removing duplicate rules present in F2. Following example of before and after scenario of app stack:
Current app stack:
- Implementation D
- Framework F2 (F1 + D-specific rules)
Other Implementations app stack:
- Implementation A,B,C
- Framework F1
To-be achieved app stack:
- Implementation D (D-specific rules moved to D)
- Framework F1 (Use F1 framework directly)
Other implementations:
- Implementation A,B,C
- Framework F1
What do you gain by removing it? --- Currently, 2 frameworks exist in our applications. We want to get rid of 1 for better maintainability.
Is F2 being moved to its own server with its own database? --- Nope. This is a clean up task for an old messy way of development, when plans were executed differently by other people.
I hope I am a bit more clear this time.
Kind Regards,
Hi Mike,
Thanks for your response. Following details to your questions:
How many of the rules in F1 do you *really* use in F2? --- 65-70% rules of framework F1 are exactly the same in F2 are being used by the implementation D
Why do you need to break the dependency? --- To explain you clearly, this needs to be done to clear out redundant rules in F2 (which are exactly same as F1). By dependency, I actually meant removing duplicate rules present in F2. Following example of before and after scenario of app stack:
Current app stack:
- Implementation D
- Framework F2 (F1 + D-specific rules)
Other Implementations app stack:
- Implementation A,B,C
- Framework F1
To-be achieved app stack:
- Implementation D (D-specific rules moved to D)
- Framework F1 (Use F1 framework directly)
Other implementations:
- Implementation A,B,C
- Framework F1
What do you gain by removing it? --- Currently, 2 frameworks exist in our applications. We want to get rid of 1 for better maintainability.
Is F2 being moved to its own server with its own database? --- Nope. This is a clean up task for an old messy way of development, when plans were executed differently by other people.
I hope I am a bit more clear this time.
Kind Regards,
Ashish
Pegasystems Inc.
IN
Hi Ashish
Why dont you consider merging 34.3 % rules of F1 into F2 and make A,B and C use F2. Get rid of F1.
Is that a possiblity??
Regards,
Ashish
Capgemini
NL
Hi,
Thanks for your reply.
I am sorry but I don't think you got the question properly. My question in my first comment is:
-----------------------------------------
What's better?
1. Move these 10000 rules to Implementation Layer D?
2. Create a New ruleset which could exist below D and contain all these rules?
-----------------------------------------
This has to be done anyways since implementation specific rules have to be moved to implementation layer first.
But for your reference, what i assume to be the downside to move F1 rules into F2 would be that it may affect 3 applications if any conflicting rules arise and it will be difficult for us to figure out and a lot of testing effort since 3 applications are in consideration.
Otherwise its only one.
Kind Regards,
Ashish
Pegasystems Inc.
IN
I think it would be safe to move all the rules to a new rulese below D (Option 2)
That way you can test it and have all the rules still in F2, once testing is done u can remove F2, If fails u will have a backup.
And I think
"But for your reference, what i assume to be the downside to move F1 rules into F2 would be that it may affect 3 applications if any conflicting rules arise and it will be difficult for us to figure out and a lot of testing effort since 3 applications are in consideration."
is a valid point :)
Best of luck with refactoring.