LSA Course : "Framework" VS "Component Application"
Hello,
It seems to be overall recognized that using a "Framework" is not a viable design choice unless under very specific circumstances.
For example, the course says: "When using the New Application Wizard do not use the "Framework" option purely for the sake of future-proofing. Maintaining a framework comes at a cost that cannot be justified without clear evidence for its need. "
I'm having a lot of trouble understanding why the same reasoning does not seem to be applied in regards to component applications.
In my view, a component application does not differ much from a framework. It's just the logical evolution of a framework since Pega allow multiple built-on application.
It's still a "reuse layer" that can be specialized.
So my question would be in what kind of situation should a component application be recommended over simply having 1 ruleset per case type? Should it follow the same reasoning as for the framework? Aka a clear requirement for reuse? Or just the fact that some functionalities "go together" justify the choice of making a component?
Kind regards.
Updated: 27 Apr 2021 7:08 EDT
Pegasystems Inc.
US
@baeyw A framework layer is a single application with a single work pool class and class group. An application built on a framework layer extends the work pool class with the framework layer. When importing case type from the from the framework layer, every case type is generated in the same ruleset. Every imported case type is specialized for the same reason, such as Organization, geography, product differentiation/branding, etc. A component application does not place as many restrictions on how it is used. An application built on a component app would likely not extend the component app's work pool class, instead just extend Work-Cover-. The rationale behind "ruleset per case" is to better support parallel development and to simplify decomposition of that case type to become a Component Application, should the need arise.
In version 8.4, Pega added a way to rename a class plus save that class to a different ruleset on import. Having created the case type from the beginning within its own ruleset, though, makes it easier to keep the case type free from dependencies.
For example if a rule is created in the work pool class, which has the same ruleset the Application's rule, and that work pool class rule is referenced by a case type, a dependency has been created between the case type and the Application it is currently in.
The same holds true if a case type references an ORG-APP-Data class that is owned by the Application.
@baeyw A framework layer is a single application with a single work pool class and class group. An application built on a framework layer extends the work pool class with the framework layer. When importing case type from the from the framework layer, every case type is generated in the same ruleset. Every imported case type is specialized for the same reason, such as Organization, geography, product differentiation/branding, etc. A component application does not place as many restrictions on how it is used. An application built on a component app would likely not extend the component app's work pool class, instead just extend Work-Cover-. The rationale behind "ruleset per case" is to better support parallel development and to simplify decomposition of that case type to become a Component Application, should the need arise.
In version 8.4, Pega added a way to rename a class plus save that class to a different ruleset on import. Having created the case type from the beginning within its own ruleset, though, makes it easier to keep the case type free from dependencies.
For example if a rule is created in the work pool class, which has the same ruleset the Application's rule, and that work pool class rule is referenced by a case type, a dependency has been created between the case type and the Application it is currently in.
The same holds true if a case type references an ORG-APP-Data class that is owned by the Application.
If however the case type only references Data classes from a lower layer, ORG-Data say, and does not reference any work pool class rule, that case type can be easily converted to a Component Application.
Pegasystems Inc.
FR
Hello @pedel,
Thank you very much for your answer, it helps a lot. I'm still missing a crucial understanding following the question " in what kind of situation should a component application be recommended over simply having 1 ruleset per case type?".
Basically, I understand from your response that since component applications have much fewer constraints than a framework they should be used more freely. But I'm still wondering to what extent we should use component application for "future-proofing".
I understand that the use of Frameworks was a bit abused before and that justify the strong communication around having clear requirement at the start of the project that encourages the need to use a Framework.
So I was skeptical about how much liberty we should take around using component applications because the same kind of argument is still valid, you are still maintaining a "Reuse layer", you have to take into consideration extensibility and reuse, you should make good use of template design patterns, all of which have high development costs.
My impression of the course is that you should use a component application almost as long as it is possible. That's why I'm really wondering if this is the new official way to design applications.
Kind regards.
Updated: 30 Apr 2021 13:35 EDT
Pegasystems Inc.
US
@baeyw The definition of "component" is recursive. It is always possible to compose an application from other components which in turn could be composed of components, etc., etc. A framework layer can be constructed from multiple component applications, but so can a production layer application. You only want to create a framework layer when there is sufficient rationale and justification. A layer that is never reused is not a reuse layer, per se. "Reuse" means something is used more than once. There are more advantages to building component applications compared to frameworks since component apps provide far greater flexibility.
If, from the beginning, you decide you want to build a monolithic framework application, placing the majority of the rules in one ruleset, the opportunity to modularize different functionality would be lost. In the future you want extensibility and flexibility. What you want to future-proof is NOT being hamstrung having to maintain large, brick-like applications that were NOT constructed with Separation of Concerns in mind.
Instead. you want to future-enable the enterprise's ability to compose new and different applications, ones built in less time, and easier to maintain.
Extensibility and flexibility are achieved through modular architecture.
Pegasystems Inc.
FR
@pedel Allright I think I understand a bit better.
I think my main issue comes from not really understanding the "Framework" use cases.
I suppose It's useful to "force" the content of a specific application but still allow some variability for Divisions / Units or countries.
Anyhow what I retain from this is :
- Modular architecture is basically encouraged when possible. As long as it's "logical" to package a group of closely linked case types together.
- It's preferable to create a built-on component application than only separating cases-types into different rulesets for future-proofing, especially if those case types appear to be strong candidates for a potential component application.
The only thing that bothers me is that in the course It's officially advised to use Separate Rulesets for strong component candidates, not use component applications. So the "limit" between using separate rulesets and using a modular architecture when you identify "potential" components is still a bit blurry for me :(.
Infosys Ltd
AU
@baeyw I also have a similar doubt as you had more in terms of what if I want to modify the case type sourced from a component application. Let's say if I want to add in a new stage to a case type sourced from a Component application? Would the component application approach still be fine? Or should there be a framework layer in this case? And is it good to assume that the case types Component Applications provide are not to be modified at the Production level? Because I think the advantage of Component applications would be reduced if we are making modifications and the case types sourced from Component applications are not meant to be modified at all as once they are modified the maintenance of Component applications would suffer. There would then be two places to make changes to.
Updated: 28 Aug 2021 12:32 EDT
Areteans
NL
@SHIKHARPEGA, right point.
But the same dilemma exists when developing in framework and implementation application development paradigm as well. In my opinion , what component application aims to solve is the modularity aspect of application development.
If you are building three separate process in three separate component application , you get the advantage of plugging in one of those in another application and develop it there. In case of framework you will get to choose either of those but be still dependent on all of those.
Just like in a FW and Impl paradigm, changes to impl layers are permitted , similarly an application which is composed of components should be allowed to mature the component case type in respective application with out touching the component itself, following the provided interfaces if any. If that's true then component applications paradigm makes sense. But there is still an overhead to maintain a component if the process needs to be customised a lot in implementations.