Difference between revisions of "Y-Principle"
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | __NOCACHE__ | + | __NOCACHE__{{language|master page=Y-Prinzip|language=en}} |
| − | {{language|master page=Y-Prinzip|language=en}} | + | |
| − | + | = Y-Principle = | |
| − | + | ||
| − | + | [[File:YPrinzip.png|400px]] | |
| + | |||
| + | At the iSAQB Information Days 2011, the Y-Principle was the central topic of discussion on how to achieve Separation of Concerns as simply and efficiently as possible. It focuses on the separation of business logic and technology. The Y-Principle is often, but not always, applicable – the criteria for its application must be known, and software projects should be examined to see if there is significant potential for cost savings. | ||
| + | |||
| + | With this knowledge, you should be motivated to analyze your own software projects to determine where they stand in terms of separating business logic from technology and how much importance you want to give to this topic in the future. | ||
| + | |||
| + | Contact us to learn how the benefits of separation increase significantly with the growing size and complexity of projects. See how the "Reverse-Y" analysis in concrete project examples reveals where the greatest benefits lie. | ||
| + | |||
| + | Reverse-Y means applying the Y-Principle from an existing implementation. This involves identifying recurring technical topics such as help systems, error handling, data storage, and user interfaces, and gradually decoupling them from the business logic (unless the decoupling is already ideally achieved and only needs to be documented). | ||
| + | |||
| + | The more separated the paths of business logic and technology are pursued, the more necessary it becomes to clarify the connections between the two sides and agree on interfaces. It is helpful for the business side to work with a "pseudo-technical view," which simplifies the technical assumptions and interfaces, and for the technical side to work with a "pseudo-business view," which represents the business assumptions and interfaces. In detail, neither view needs to be completely accurate. However, the pseudo-business view should reflect architecturally relevant points from a technical perspective, such as the data volume, complexity regarding data structures and GUI, and similar points. The pseudo-technical view should reflect the technical topics necessary from a business perspective, such as GUI, database, network, security, etc., so that the intended interfaces are simple and clear. | ||
| + | |||
| + | The '''Y-Principle''' originated at BITPlan in 2001 and is based on the Objects 9000® idea by Martin Rösch. This principle has been applied in several projects requiring cross-platform solutions. | ||
| + | |||
| + | In developing software architectures, the goal is to find an appropriate decomposition of the software to be developed. The separation of business logic and technology is an important decomposition principle. The cost-benefit potential should not be overlooked, as it makes no sense to dogmatically adhere to principles if a particular project situation does not offer the highest possible cost-benefit effect. For software systems that need to be maintained over the long term, it is important to consider the entire lifecycle. In situations where product families are being developed, it is generally advisable to follow an aspect-oriented approach guided by the separation of business logic and technology. Cross-platform development is much easier to achieve when technical aspects are encapsulated. Consequently, the requirements analysis should already take technical aspects into account as separately as possible. Achieving conceptual consistency from requirements analysis to implementation while maintaining the separation of business logic and technology is not easy in practice. Compromises are almost inevitable. It is important not to lose the advantage of systematization, as systematization is the prerequisite for automation. The necessary consensus processes for systematization belong at the beginning. Only then can automation be based on this foundation. | ||
| + | |||
| + | {{Link|target=http://wiki.bitplan.com/images/wiki/2/2f/Trennungvon_FachlichkeitUndTechnik2011-11-27.pdf|title=Complete Article: Y-Principle}} | ||
| + | |||
| + | = Example = | ||
| + | |||
| + | Y-Principle based generation for Semantic MediaWiki: | ||
| + | [[File:Y-PrincipleExample.png|800px]] | ||
| + | |||
| + | [[Category:frontend]] | ||
| + | [[Category:blog]] | ||
| + | |||
| + | [[Category:frontend]] | ||
Latest revision as of 06:15, 12 August 2024
This page in other languages: de
Y-Principle
At the iSAQB Information Days 2011, the Y-Principle was the central topic of discussion on how to achieve Separation of Concerns as simply and efficiently as possible. It focuses on the separation of business logic and technology. The Y-Principle is often, but not always, applicable – the criteria for its application must be known, and software projects should be examined to see if there is significant potential for cost savings.
With this knowledge, you should be motivated to analyze your own software projects to determine where they stand in terms of separating business logic from technology and how much importance you want to give to this topic in the future.
Contact us to learn how the benefits of separation increase significantly with the growing size and complexity of projects. See how the "Reverse-Y" analysis in concrete project examples reveals where the greatest benefits lie.
Reverse-Y means applying the Y-Principle from an existing implementation. This involves identifying recurring technical topics such as help systems, error handling, data storage, and user interfaces, and gradually decoupling them from the business logic (unless the decoupling is already ideally achieved and only needs to be documented).
The more separated the paths of business logic and technology are pursued, the more necessary it becomes to clarify the connections between the two sides and agree on interfaces. It is helpful for the business side to work with a "pseudo-technical view," which simplifies the technical assumptions and interfaces, and for the technical side to work with a "pseudo-business view," which represents the business assumptions and interfaces. In detail, neither view needs to be completely accurate. However, the pseudo-business view should reflect architecturally relevant points from a technical perspective, such as the data volume, complexity regarding data structures and GUI, and similar points. The pseudo-technical view should reflect the technical topics necessary from a business perspective, such as GUI, database, network, security, etc., so that the intended interfaces are simple and clear.
The Y-Principle originated at BITPlan in 2001 and is based on the Objects 9000® idea by Martin Rösch. This principle has been applied in several projects requiring cross-platform solutions.
In developing software architectures, the goal is to find an appropriate decomposition of the software to be developed. The separation of business logic and technology is an important decomposition principle. The cost-benefit potential should not be overlooked, as it makes no sense to dogmatically adhere to principles if a particular project situation does not offer the highest possible cost-benefit effect. For software systems that need to be maintained over the long term, it is important to consider the entire lifecycle. In situations where product families are being developed, it is generally advisable to follow an aspect-oriented approach guided by the separation of business logic and technology. Cross-platform development is much easier to achieve when technical aspects are encapsulated. Consequently, the requirements analysis should already take technical aspects into account as separately as possible. Achieving conceptual consistency from requirements analysis to implementation while maintaining the separation of business logic and technology is not easy in practice. Compromises are almost inevitable. It is important not to lose the advantage of systematization, as systematization is the prerequisite for automation. The necessary consensus processes for systematization belong at the beginning. Only then can automation be based on this foundation.
Example
Y-Principle based generation for Semantic MediaWiki:
