When do we need to create just a framework layer and and when do we create Framework layer and implementation layer?
When do we actually need to create Framework layer? I feel for any kind of automation we want to do we should start with creating Framework layer. Because we never know if there is or there is no chance of of a specific implementation for the problem we are trying to automate. Is this correct?
When do we actually need to create Implementation layer? What is the trigger point which forces us to create a implementation layer? If there are no specifics for an implementation should we still create implementation layer?
SSA content says 'One key aspect to the implementation layer is that this is where any of our work classes should be instantiated'. So regardless of whether there are specifics in terms of implementation we should create implementation layer on top of Framework layer?
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Hi PEDEL,
Do you mean, If an application has a broader spectrum at a later point we create a Framework by default. The first basic implementation should be in framework and if anything further comes up then it has to be created as a implementation over the existing framework and try utilizing the existing functionalities from FW??
Thanks,
Satya Dasika.
I too have a similar question.Let us consider an example . A Company is building an application for one of its Region (Ex. Region A) or divisions.And that application in future might be extended for other regions and divisions with some Customization.In this case is it a good idea to :
1) Build the application for Region A as framework and then build other regions on top of it as Implementation layer
2) Directly build the Implementation layer for Region A and build other implementation layers on top of it in future
3) Build a framework with all features of Region A and on top of that build the Implementation for Region A.
I felt option 3 is the best since we can build multiple implementation layers on top of the framework layer and reuse its features (improve framework in future if we need to introduce some new features for all regions) and if I need to make any change specific for just Region A I would do in that Implementation layer. If Region A was the framework layer the class structure wont reflect the exact divisional layer (it would be FW) and If want to modify anything specific to Region A I would have to take care to make sure it does not affect other regions. I was not able to imagine the value between Implementation on top of Implementation vs Implementation on top of Framework
Is it possible to build option 2? Have you ever tried?
The (almost completed :-) 7.3 Lead System Architect course will discuss all of this.
Valuable input from this forum, including yours, has been incorporated.
Something lacking in this discussion is how Business intends to deploy multiple applications derived from the same framework. Security concerns could arise if hosted on the same system. You would not want to re-invent Pega's multi-tenancy solution should that be a viable alternative.
Having to switch between applications is another concern. Can specialization needs be accommodated within the original application as opposed to adding a new application layer?
Bottom line, an LSA's role is ask Business about their needs before making major decisions; major decisions should not be made in a vacuum.
pedel I concur your with your point that business needs to take major decisions. But dont you think the other way too? If decision changes because of the dynamic nature of the business they do, Product should have offered minimum flexibility to incorporate those?
I will wait for 7.3 course.
The current "beta" version of the 7.3 LSA course will be highly similar to the final version, which will be made available soon after 7.3.1 GA.
Lessons in the course that specifically address application structure include:
[4] Asset Design and Reuse
o Designing for specialization
o Promoting reuse
[12] Post Production Events
o Extending existing applications
First of all whether or not create a framework layer does not belong in an SSA course since that is an LSA level decision. The "must have a different class in Production" argument is false. Y-axis is ruleset, X-axis is class. For the first implementation you move up the Y-axis. Only for the second implementation - if and when there ever is one - do you need to move to the right to create a different class.
There is nothing wrong with the idea of framework except its name. What you aim for is Model Driven Architecture. If you know there is the possibility for multiple layers, in the lower layer you abstract a model - similar to using the Template design pattern. In that pattern you do not do everything. Instead you define a blueprint for solving a problem. Distinct implementations can follow the same blueprint simplifying maintenance while increasing development speed.
That said there are numerous situations where there would only ever need to be one implementation.
If you were a software vendor, you could decide to only build frameworks, customers completing the implementation (filling out the template).
If you worked for such a customer would your first decision be building yet another framework layer for the first implementation knowing that you can use ruleset override at any point in the future if truly necessary?