Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update introduction.md #329

Merged
merged 1 commit into from
Oct 31, 2022
Merged

Update introduction.md #329

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion introduction/introduction.md
View file
Open in desktop
Expand Up @@ -74,7 +74,7 @@ Eiffel is not a centralized or monolithic tool. Instead it represents a decentra
## How Does Eiffel Achieve Flexibility?
An important principle in Eiffel is that events are not prescriptive, but descriptive. An event is not an RPC call, it will not order the recipient to take a certain action. Instead, it is assumed that the recipient will react in an intelligent and conducive manner to the information it gathers. Holding to this principle becomes particularly important in large, multi-organizational integration contexts, as it allows decoupling and separation of concerns between consumers and producers of events.

To exemplify, an organization developing a common component does not - and indeed should not - need to know how the continuous integration systems of its consumers are set up. As long as it accurately report on its own process as it builds, tests and verifies new versions consumers may come and go, or may decide to pick up specific deliveries or not, for any reason, without any need to notify or synchronize with the developing organization. Despite this traceability is still preserved: looking up who has integrated which component version when, how long it took, and whether they are included in any customer releases is but a query away.
To exemplify, an organization developing a common component does not - and indeed should not - need to know how the continuous integration systems of its consumers are set up. As long as it accurately reports on its own process as it builds, tests and verifies new versions consumers may come and go, or may decide to pick up specific deliveries or not, for any reason, without any need to notify or synchronize with the developing organization. Despite this traceability is still preserved: looking up who has integrated which component version when, how long it took, and whether they are included in any customer releases is but a query away.

Consequently, the larger enterprise-wide continuous integration and delivery system becomes highly flexible in that it may be modified and extended without synchronization or central orchestration.

Expand Down