Guidelines for Dividing a Solution into Feature Projects
This topic provides guidelines on dividing an automation solution into multiple feature projects, as per the recommended solution architecture.
Multiple factors must be taken into account when deciding how to divide a solution between projects. These include:
Technical Considerations
Technical considerations for dividing a solution across projects include:
Run-Time Performance
By far, the major factor that affects run-time performance is the number of screen elements monitored by the solution. (For this reason, it is useful to remove unused screen elements from your project and to disable recognition of screen elements when not needed.)
In the case where two features use different sets of screen elements, and the two features are not related and won't be used at the same time, consider including those features in separate projects and only load the project required by the agent at the time. That way only the required screen elements will be monitored.
Design-Time Performance
While Automation Studio is capable of supporting the design of large solutions, performance is improved when working on smaller projects.
From the developer's point of view, smaller projects are more manageable and easier to debug than larger ones.
On-boarding new developers is also easier when projects are smaller and focused on a limited set of features.
Screen Element Recognition
Where multiple projects in a solution include screen elements of the same application, recognition of those screen elements may fail during run-time under certain circumstances. Deciding how to structure a solution to ensure screen element recognition is explained in more detail here.
Business Considerations
Business considerations for dividing a solution across projects are listed below.
Features and Users
If some users require one set of features and other users require a different set of features, consider dividing those features into two different projects (or groups of projects).
By doing so, developers can focus on the needs of just one user group during development. Also, the effort and risks of maintenance and updates are limited to a single group of users.
Feature Owners
Where possible, each project should have a single owner. If a proposed set of features has two owners, consider splitting those features between two projects.
Static vs. Dynamic Features
If part of a solution is unlikely to change over time, consider building that section in a separate project that can be referenced by multiple other projects.
Future Use of Features
Take into account how each of the features may be used in the future.
For example, if one feature may be reused in combination with other features in the future, it is better to develop that feature in its own project than to develop it together with other features that have no connection to future features.
Features and Applications
Where two features in a solution automate processes on different external applications, it is almost always preferable to develop those features in separate projects. Doing so allows the developers to focus on one application at a time, and also minimizes the effort and risk of updating the solution when one of those external applications is modified or updated.
Developer Location
If development of features will be split across teams and/or timezones, consider splitting those features between projects.
Developer Skill Set
If your development team includes a developer with a specific set of skills, such as a UI expert, consider an architecture where that developer can work on a standalone project that will interface with other projects developed by other teams. In this way, work can be performed in parallel as multiple developers can't work on the same project simultaneously. Where that is not possible or desirable, working on smaller projects would allow one development team to complete work on each project faster and then pass that project onto the specialist developer sooner than would be the case with a larger project.
