Posted: 22 Feb 2019 0:17 EST Last activity: 14 Mar 2019 13:00 EDT
Productize an application - Commonality Built First
We have a need for our business to Productize an application . Here are more details
PRPC -->Pega Framework--> Application 1 is what we initially though of, now we think of take a step further. If there is a need to build an Application 2, Application 3 and so on, how to scale it considering Enterprise layer and Division layer.
As a Division would like to have all common functionality of Claims Repair in one place and then keep building applications on this. My thought on this was build a Division layer and construct "Commons" and build in the Implementation layer (App1), Implementation layer (App2) and so on.
I would consider building a framework layer leveraging the assets of Application 1. You would then do the vast majority of your development work in your new Framework. Only those functionalities that are specific to a single implementation layer would be built in the implementation layer.
If you are saying that you need to build common functionality at the Division layer rather than the Enterprise layer, then you could opt for built on applications to the Division application.
Could you provide an example of your use case? This might allow me to be more specific with my suggestion.
Initially we (Divison) planned to build an application that is specific to our LOB 1 (3 states). Now that we foresee more LOBs in near future (LOB 2 - 3 states, LOB 3 - 3 states), we would like to be more flexible and scalable.
Our all LOBs have common functionality (Example - Intake, enrollment etc) and would like to focus on the commons first and built the ECS accordingly.
In our intended Pega Architecture we considered Org Layer as well with SSO, etc that are more specific to Org rather than Division
This sounds to me like a classic Pega framework to implementation layer solution.
If you have not yet built your application, when you run the New Application wizard, specify that you want a framework and an implementation layer. You should then get the structure you desire. You would leverage the Org layer of the framework for Org level reuse and the Framework organization would include only an Org and a Division, leaving Unit set to the default value.
If you have already created your application and have created a fairly sizable number of assets, you could just build on to the existing application in the new application. However, your class structure will not indicate the true nature of your current application being reused as a framework. You would really have an implementation built on to another implementation. I would avoid this if I could.
You can use the New Application wizard to build a framework only. You could then alter the Built On application of Application 1 to point to this new framework and move rules meant for reuse into the framework from Application 1.
Hope this helps! Please let me know if you have any add on questions or need clarification.
Since 7.3 when running the New Application Wizard you cannot say to build both a Framework and Implementation application at the same time. You can only build one or the other.
This is stated in the 7.3/7.4 LSA course at the beginning of Page 4, "How to choose the application structure", with the "DESIGNING FOR SPECIALIZATION" lesson.
Not understanding: "However, your class structure will not indicate the true nature of your current application being reused as a framework"
It is not necessary that every class name contain "-FW-" when defining a foundation for applications that specialize that foundation. You can construct that foundation layer various ways including leveraging multiple built-on applications and components.
"Since 7.3 when running the New Application Wizard you cannot say to build both a Framework and Implementation application at the same time. You can only build one or the other."
This is true. However, that does not mean that you can't build both. You can. In the advanced configuration, you can select one or the other. My apologies for the misleading answer, but the point is the same.
"It is not necessary that every class name contain "-FW-" when defining a foundation for applications that specialize that foundation. You can construct that foundation layer various ways including leveraging multiple built-on applications and components."
Again, true, however the new application wizard will still use the FW construct when you select Framework and it is, therefore, still a recognized class naming convention.
The principles of my answer are still valid, semantics aside. It still appears that a classic Pega Framework-Implementation construct would apply well here. I don't see any arguments to the contrary.
The 7.3/7.4 LSA course says to create a framework/ foundation/ model/ template/ blueprint (FFMTB) application from the beginning only after discussing with the Stakeholders whether the application would ever need to be extended.
The course also says an "Implementation" can be converted to an FFMTB in the future.
If the "classic Framework" option were removed from the New Application Wizard it would still be possible to construct an FFMTB layer. The question is whether a modular architecture approach is used to achieve that layer.
The original post was about having a Division layer because what will be built is specific to that Division. The post also mentioned wanting "Commons Claim Repair" functionality that other applications within that Division could leverage. Divisions are free to develop their own frameworks. Division-specific frameworks would be built on the Division layer which is built on the Enterprise/Org layer.
"Commons Claim Repair" functionality could be either a "framework application" or a "component application". Differences are application size, i.e., number of rulesets and case types, and how the "commons" application is managed/ versioned/ deployed.
It would make sense for the Division's COE would develop this functionality.
There is little value in having the same development team create, work on, and version two layers at the same time, the implementation layer being little more than a set of classes that directly extend framework layer classes.
Santosh, without speaking for Lee, I think I could use some more information to able to assist you. Lee makes a very good point about their being many ways to provide common functionality. Exactly what is the nature of this Commons? Is it shared process? Shared business rules? Shared reporting? All of the above?
In addition, is it expected that there will be users for this common functionality or that it will merely provide a reuse layer for other applications?
It is possible to start working on Application 1 and later "spin off" the Commons layer underneath it.
"Later" means when you are ready to start developing Application 2.
You can do this by using the ruleset override / application-wrapper approach described in the 7.3/7.4 course.
While developing Application 1 you must always be on the lookout for functionality that is specific to Application 1.
When you see such functionality code it into new rulesets added to the top of the application stack.
Eventually you want Application 1 to only contain those new rulesets and be built on a "Commons" application.
The Commons application's rulesets should only contain code generic to any application that is built on it, e.g., Application 1, Application 2, etc.
Application 2 can use direct inheritance for cases types. But if you are going to deploy Application 2 to a different database anyway, then you continue to use ruleset-based specialization for Application 2.
What you are suggesting, Lee, seems very similar to building a framework and an implementation simultaneously.
it seems to me that Commons is fairly well defined and it identified as a reusable layer. Frankly, it screams framework layer to me and I am really having trouble understanding why you wouldn't build this first and then extend it. I would even consider building it straight away as a component application if the intent is to truly productize the application, where distribution by ruleset is easily accomplished.
If you already know you have a layer of reuse and you can easily identify it, why not built it straight away?
Now, I acknowledge that I made an assumption there and that is that Commons is easily defined and understood from both a process and rules perspective. This is based on previous posts from Santosh. However, if you are not sure what will be reused or what makes up Commons and you expect to find out through the course of your journey, then I think your approach is one to be considered. it's a creative approach but it seems a bit riskier if you can already define what it is that makes up Commons.
Lee - To your point, as stated by Mike I feel that building the "Commons" sound like a fit. But I am still weighing on the optimal solution for this.
One way to do it is be proactive in filtering out the "Commons", this way we be able to build the "Claims Engine". This Claims Engine will have all the rules and process encompassing claims processing assets.
After this Framework - Claims Engine is built, then incline towards building "Application 1".
Parallel to this "Application 1", I can let the other team to work on "Application 2"
From your post a while back it sounded like you only had one development team at the beginning so I suggested a way to get Application 1 going without have to wait for the Commons layer to be developed.
If you do have the resources to staff two separate teams that would be preferable.
What I described was a way to build one application at a time albeit having to be disciplined to keep commons code separate from Application 1 specific code.
When Application 2 comes along, by that time a separate Division COE tream would be absolutely necessary.
Time to market is faster. Use of developer resources is more efficient. But more discipline required.
A "downside" to using ruleset override within the same application is that this affects your Application Quality Test Coverage score. If you had one application built on the other, you can easily test whether a rule is reachable or just dead code.
This relates to other topics taught in the the "DESIGNING FOR SPECIALIZATION" lesson, namely circumstancing and pattern-inheritance. The values that trigger both can be manipulated programmatically. Note the first Use case within Page 9 of the "DESIGNING FOR SPECIALIZATION" lesson, "Specialization Use Cases".
Let's go back the question whether Application 2 will be hosted in a separate databases. Would this always be true or even necessary?
Suppose a CSR handles calls from customers using a single company-wide phone number. Is the CSR expected to ask the customer what Division they are referring to after which the CSR needs to access that Division's application? In other words, due to the similarities between Application 1 and Application 2, can the differences, i.e., specializations, be handled within the same application?
To support same-application functionality, circumstancing and pattern-inheritance can be leveraged. Circumstancing is very powerful but is more complex to maintain as mentioned in the 7.3/7.4 LSA course. Suppose someone using Pega Express/App Studio modifies a flow or section that results in rules being generated? Those rules would not be circumstanced.
The above concern goes away when using pattern-inheritance. Test Coverage is straightforward as well.
Not trying to dodge your question, but the best way to seek Pega product purchase/licensing advice is to start by contacting the Pega Engagement Lead(s) and Practice Lead(s) associated to your current project(s) then take it from there.