Do It Lean - Architecture Bootcamp Quiz.pdf

4/15/2021 Do It Lean - Architecture Bootcamp Quiz
https://docs.google.com/forms/d/e/1FAIpQLSeu-VhCltdSNEmbuGxZu_xenwR-ND4xK8zrs9DXfmdHOpgihA/viewscore?viewscore=AE0zAgAmODTlunlP8XcNx1lrSFVkaMV4_1yG0jfTHQbQ9NEEG4wr… 1/30
Email address *
nuno.damaso@doitlean.com
1 of 1 points
1/1
Manages complexity and reduces costs, removing the need to plan
Makes dependencies manageable and solutions flexible to evolve
Reduces risk by avoiding Service Abstraction
Abstracts business concepts, making unnecessary to worry with non functional
requirements
Canvas 5 of 8 points
Do It Lean - Architecture Bootcamp Quiz
Total points 33/40
Small quiz around the Architecture Bootcamp.
What is the benefit of a good Architecture? *

1/1
Orchestrates cross-application end-user functionality
Provides functionality to support user stories, and must be independent of other
end-user modules
Provides reusable business processes but must not be consumed by other end-user
modules
Designed by an end-user
1/1
Manages cross-application processes and dashboards, providing access to
different business applications
Orchestrates the synchronization of multiple entities from an external system of
records
Provides reusable business processes but must not be consumed by other end-user
modules
Provides non reusable functionality to support user stories
What is the main nature of an end-user module? *
What is the nature of an Orchestration module? *

0/1
Provide reusable services around a business concept, as long as it is not consumed
by another Core module
Be exposed to external consumers through an Integration Service and reference
external producers through an API module
Be isolated to avoid impacts from changes on external consumers and producers
Provide business or non business reusable services, and it can depend on other
Core modules
Correct answer
Be isolated to avoid impacts from changes on external consumers and producers
1/1
Faster architecture design without validation need
A systematic approach to architecture design, supported by a validation tool
A common understanding between business users
An automatic way to follow and fix architecture principles
A Core module should... *
Adoption of the 4-layer canvas provides *

1/1
The reusability of end-user modules by spliting business processes per module
The merge of two concepts on the same module whenever one depends on the other
The mandatory split of one concept into different modules, separating data, logic
and presentation
The segregation of reusable building blocks that minimizes impacts on
consumers
0/1
The split of a concept into different modules to separate data, logic and
presentation layers
The development of logic and data around business concepts directly in an end-user
module, if those concepts are only used in that module
Information hiding to easy the reuse of functional and non functional concepts
The capacity to create/update/delete entity records directly in a end-user module
Correct answer
Information hiding to easy the reuse of functional and non functional concepts
The correct granularity of modules in the Canvas, promotes *
Abstraction is key to promote *

0/1
It allows sharing screens between different end user modules
Promotes cost savings and avoid multiple definitions of concepts
Gives flexibility to create/update/delete entity records directly in a end-user module
Promotes cost savings by allowing the definition of a concept in multiple
modules
Correct answer
Promotes cost savings and avoid multiple definitions of concepts
1/1
Advocates the merge of two concepts on the same module, if one depends on the
other
Leverages the composition of information and logic, on top of reusable building
blocks
Gives flexibility to create/update/delete entity records directly in a end-user module
Promotes cost savings by allowing the dispersion of a concept into multiple
modules
Why is reusability so important? *
Why is mash-up a key aspect of Architecture? *

Design process 4 of 4 points
1/1
Detailed user stories and signatures of all the required APIs
The availability of different teams involved in systems to integrate
The major project risks
End user processes, business concepts, integration needs and NFRs
1/1
Concepts have the same lifecycle, even if not functionally related
Concepts belong to the same functional area and a typical consumer exercise all
the concepts
To reduce the number of modules and references, simplifying the release cycle
To accelerate development, by reducing the number of references
What is important to understand, when disclosing concepts for an
architecture design *
What is a good reason for joining concepts when assembling a module *

1/1
No, because it adds unnecessary complexity to consumers requiring both concepts
Yes, because it reduces the number of references, simplifying deployments
Yes, to avoid cyclic references and reduce the footprint of generated code
No, because it prevents lifecycle independency of concepts and add
unnecessary impacts to consumers
1/1
To separate unrelated concepts with different lifecycles
To make sure that entities are isolated from business logic
To avoid upward references
To increase development speed
Validation rules 6 of 6 points
Should you join unrelated concepts in the same module? *
What is a good reason to split a core module in two *

1/1
Allows the correct reuse of screen destinations in a menu
The footprint of the modules reduce drastically
Generates a lot of direct or indirect cyclic references
Reduces the number of indirect references, by shortcutting to an upper layer module
1/1
Simply remove the references to the elements of the upper layer module
Always move the consumed elements from the producer to the consumer to avoid
the reference
Make sure the library is business agnostic and move consumed elements to
reusable libraries
Identify the consumed elements and move them to a reusable core module
What is the consequence of having upward references *
How can you fix an upward reference from a library *

1/1
Allows the reuse of destinations between end user modules
Lack of isolation between core modules
Always generates cyclic references
No lifecycle independence between end user modules
1/1
Make sure the consumer is business agnostic and move consumed elements to
reusable libraries
Replace destinations by external URLs and consume actions through restfull APIs
Always move the consumed elements from the producer to the consumer to avoid
the reference
Identify the consumed elements, excluding destinations, and move them to
reusable core/library modules
What is the consequence of having side references *
What is the correct way to fix a side reference? *

https://docs.google.com/forms/d/e/1FAIpQLSeu-VhCltdSNEmbuGxZu_xenwR-ND4xK8zrs9DXfmdHOpgihA/viewscore?viewscore=AE0zAgAmODTlunlP8XcNx1lrSFVkaMV4_1yG0jfTHQbQ9NEEG4w… 10/30
1/1
One of the directions is conceptually undesirable, with hard-to-manage code
Generates loops in the runtime code
Although modules involved in the cycle become tightly connected, it allows a better
granularity without extra impacts on other consumers
It's the only way to generate indirect references to the consumers of those modules
1/1
Make the module independent, by replicating the common code required in both
modules
Remove the composition logic to a third module that consumes these two
modules
Always merge them in a single module
Identify the undesirable direction and replace action references by a REST API
reference
Patterns - Libraries 7 of 8 points
What is the effect of having a cyclic reference between two modules *
What is the best approach to fix a cyclic reference between two modules
*

Check the following connector pattern

1/1
The extension simply encapsulates the original library, and the eSpace abstracts
a public API matching required use cases with normalized concepts and
behaviour
The extension maps a C# or Java library to the API consumed by any module
requiring that functionality. The eSpace is just a sample usage
The eSpace simply adds data resilience on top of the extension, that encapsulates a
C# or Java library
Consumers seeking flexibility should use the extension, since the eSpace limits the
usage of the functionality
1/1
Create a Driver module per functional area and an Integration Service on top to have
a single endpoint to communicate with the ERP
Create a single Integration Service to map concepts and hide integration complexity
Use the REST/SOAP API exposed by the ERP directly in your business rules
Create an Integration Service, per functional Area, with the correct granularity to
fulfill different lifecycles and consumption needs
What is the main characteristic of the Connector pattern in the picture *
When integrating with an ERP with hundreds of APIs, across several
business areas, you should: *

1/1
To support a concept with entities and CRUD edition
To abstract different implementations in a Transparency pattern
To implement business rules by composition of base core modules
To support reusable core widgets
0/1
Understand the mapping between modules and applications
Enforce a reference architecture and normalize patterns
Remove the need to validate the architecture
Reveal the nature of each module, without enforcing a reference architecture
Correct answer
Enforce a reference architecture and normalize patterns
Select a valid reason to create a BL module *
Adopting a module naming convention is important to *

Consider the following example of a basic External Core Service, where the
Master of Customer is an external ERP
1/1
The integration service only needs to support the retrieval of customer updates
since the last sync
Consumers of the Core Service will be able to compose customer information with
aggregates
The ERP is protected from end user load since there is no synchronization process
The ERP API must support all customer info retrieval needs, since there is no
local replica in the core service
Pick the appropriate comment *

Consider the following example of an External Core Service with local replica,
where the Master of Customer is an external ERP.
1/1
Consumers of the Core Service are not able to compose customer information with
aggregates
Optimizing the synchronization process has no impact on consumers of the core
service
The ERP API must support a complex API to cover all use cases of searching and
filtering customers
The ERP is protected from end user load since there is a synchronization
process
Pick the appropriate comment *

1/1
Sync only summary data that it’s frequently listed, joined or searched and get full
detail directly from the external systems when a single entry is selected
Adopt a lazy load strategy, where the local cache is incrementally updated, whenever
single records are requested from the external system
Avoid the local cache to remove the synchronization cost without performance
impacts
Make sure the synchronization logic is separate from the core service to reduce
impacts
1/1
Abstracting several concepts in a single API
To compose several concepts into a single API
To make a core service agnostic to the fact that the same type of Master data is
coming from different external system of records
Integrating with an ERP supporting different functional areas
Refactoring 3 of 3 points
How to improve an External Core Service with local cache, when the
whole database is too big and costly to synchronize and you need to list
and search? (Details are only required for single entries) *
A transparency service is applicable when: *

Imagine you need to extract a core from an end user module.
1/1
To keep all screens and entities on the original eSpace, avoiding data migration
To change the URLs and force consumers to refresh dependencies
To keep all screens and entities on the original eSpace, preventing consumers to
refresh dependencies
To reduce impacts on consumers and leave the original name to the clone of the
end user module to keep URLs
Why would you keep consumed elements on the original module (step
5)? *

1/1
Upward references to cores
Cycles among cores
Cycles among end users
Cycles among libraries
1/1
This assertion is false. Refactoring while changing/adding features is a way to dilute
refactoring cost
To make sure that all the focus goes to the refactoring
Because new definitions on elements being refactored, may not match what is in
production, when trying to reconnect data
To avoid enlarging the code requiring refactoring
Composition 4 of 4 points
During refactor, which prioritization should be checked after End-users
modules are ok? *
What is the main reason, when refactoring, to freeze features before the
refactored code hits production? *

1/1
Allow different paces in modules of the same Application
Aggregate modules of same functional area, for different sponsors
Minimize impacts between modules
Simplify deployments
1/1
Applications must be manually positioned in a layer
Application of a certain layer should only contain modules of that layer
Modules correctly layered with no violations
No cycles among applications
What is the the goal of a correct application composition? *
What is the first thing to ensure to correctly compose applications? *

Look at the following modules dependencies.

1/1
End user App 1: EU1 + Core A + Library A, End user App 2 : EU2, Core APP: Core B
+ Core C + Library B + Library C
End user App: EU1 + EU2, Core App: Core A + Core B + Core C, Library APP: Library A
+ Library B + Library C
End user App 1: EU1, End user App 2: EU2, Core App: Core A + Core B + Core C,
Library APP: Library A + Library B + Library C
End user App 1: EU1 + Core A + Library A, End user App 2 : EU2 + Core B + Core C +
Library B + Library C
1/1
Never: each application must have clear accountability set to support
deployment decisions
To prevent different lifecycles
To make sure all modules get the same quality
To simplify deployments
Validate Applications 1 of 3 points
For this example, what is the best way to compose applications in this
example? *
When should you mix modules from different owners in the same
application? *

Take a look at the following application canvas from Discovery

1/1
The only way to solve all the upward references is by refactoring the modules inside
each application
It is impossible to move modules between applications
To many shared services inside End user and orchestration applications
The small proportion of core applications shows that there is not much reuse of core
modules
What is the major evidence in this application canvas? *

0/1
It is impossible to move modules between applications
Unmanageable deployments in lifeTime
Unbalanced proportion of core applications, but still a reasonable lifecycle
independence among end user / Orchestration applications
The only way to solve all the upward references is by refactoring the modules
inside each application
Correct answer
Unmanageable deployments in lifeTime
What is the impact of having so many violations in this application
canvas? *

Consider the following Discovery example, showing the consumers of End User
application CRM.
0/1
Isolate modules CRM Biz and Policies Biz in a Core application
Move the consumed library modules to a library application
Move the consumed modules to a core application
Isolate all the end user modules in different applications
Correct answer
Move the consumed modules to a core application
2 of 3 points
Pick the solution that better improves applications lifetime *

Style Guide
2 of 3 points
0/1
The Style guide is an specialization of the built-in and the Login flow is in the theme
The Style guide is a clone of the built-in and the login flow is in the template
The Style guide is an specialization of the built-in and the Login flow is in the
template
The Style guide is a clone of the built-in and the Menu is in the theme
Correct answer
The Style guide is an specialization of the built-in and the Login flow is in the theme
Consider the following scenario: You have multiple applications with the
same look and feel as an existing built-in style guide. All applications
reuse the same federated authentication. *

Check the following blueprint where a shared Style guide provides the menu and
the Login flow in the theme.

1/1
Portal
Intranet
There is no applicable scenario
Independent App
In this situation, what is the applicable scenario? *

Check the following blueprint where a shared Style guide provides the menu in
the template and the login flow on the theme.

1/1
There is no applicable scenario
Independent App
Intranet
Portal
This form was created inside of OutSystems.
In this situation, what is the applicable scenario? *
Forms

Do It Lean - Architecture Bootcamp Quiz.pdf

Recommended

Recommended

More Related Content

Similar to Do It Lean - Architecture Bootcamp Quiz.pdf

Similar to Do It Lean - Architecture Bootcamp Quiz.pdf (20)

Recently uploaded

Recently uploaded (20)

Do It Lean - Architecture Bootcamp Quiz.pdf