Roles

Roles

[This is preliminary documentation and is subject to change.]

Some people will use TOPICA as a development tool, some will be end users of applications built with TOPICA. These people have different sets of skills.

In theory the documentation for end users might be completely separated from the documentation for those that build applications. But because of the amount of standard functionality built into the framework, all applications built with TOPICA will have a lot in common. Also, there is considerable overlap: those developing applications will need to know much about how the application is used. For these reasons, documentation for end users and builders / developers is built together.

This documentation contains a lot of information. Very few readers will need to read everything. What you need to read depends on your role.

The term "role" used throughout this documentation is to group the tasks involved in working with TOPICA, based on the requried skills needed.

Note
Do not confuse the term "roles" in this documentation with the permissions and profiles that control the security (access rights per user) in the application. (this might be known as "roles" in other contexts).

This topic contains the following sections.

Roles, responsibilities, and required skills
Overlaps
Cross-reference - roles and suggested reading

Roles, responsibilities, and required skills

Role	Responsibilities	Required skills
End User	This role will be further divided depending on the profiles assigned to the users. "Superusers" will manage organization (may include importing from external systems), manage users (including assigning profiles and permissions), etc. "Ordinary users" will enter patient data, run reports, etc.	Familiarity with the standard TOPICA functionality as described in Application Guide.
Configurator	Configuring form templates. Configuring structure. Configuring reports.	Familiarity with the see editor used to edit form templates and the structure file. Some knowledge of JavaScript (when needed). Knowledge of SQL (toconfigure reports) and/or third party reporting/BI tools - e.g. SQL Server Reporting Services. Knowledge of TOPICA Basic (to implement rules etc.) Knowledge of the application domain (e.g. clinical workflow, specialties, etc.) would be most helpful.
Application Developer	Develop application specific ("custom") code. plugins and/or webforms (custom webforms, custom webservices, plugins, etc.) See Extensibility and Integration.	.NET-development including ASP.NET
Framework Developer	Maintain and develop TOPICA framework	.NET development, especially ASP.NET and C#. Knowledge of TOPICA's API.
Deployer	Deploying TOPICA framework. Deploying configurations.	Operations Architecture Installation and Deployment

Overlaps

The distinction between the roles are not clear-cut. There is some overlap in the description of roles. Often one person working with TOPICA will "play" more than one role at the time.

Examples:

Consultants may play Role Configurator when designing input forms etc.), but will need skills described in Role End User to set up organization and users in order to test the configured forms etc. - and/or set up the environment for end users.
TOPICA is well suited for agile developments. An important issue in agile develoemnt is to deploy often and early. The persons that build the application (configurators and/or application developers) may play the deployer role, too.
Programmers may play roles Application Developer and Framework Developer - both need ASP.NET programming skills. As a programmer writing code in context of TOPICA, it is important to be make a clear distinction between these types of code:
- Generic code, that might be useful in many applications built on top of the TOPICA framework, should be developed as an integrated part of the framework.
- Only code, that is (theoretically) useful for ALL TOPICA based applications, should go into the framework.
- Application specific code, that is useful only in one or a few applications, should be implemented as separate modules / components / plugins etc. This goes especially for every piece of code, that depends on a dynamic (=configured) data model.
- TOPICA is ready for localization. Functionality that is useful for a range of applications, but country or language specific, should NOT go into the framework. It should be developed as replaceable modules / plugins. Typical examples include integration with country specific systems for person identification, organization data, classifications, etc.
- When the need to develop new code arises, and the code is specific for one or a group of applications, there might arise situations, when the framework does not have the needed extensibility option. In this case, the job should be divided in this way:
  - First, a framework developer modifies the framework to implement the required extensibility.
  - Next, an application developer uses this new extensibility option to implement the requested functionality.

Cross-reference - roles and suggested reading

This documentation set contains all existing technically documentation related to TOPICA. Very few readers will need to read everything. What you need to read, depends on your role. This table shows the relationship between the role played and necessary skills (with references to the parts of the documentation, that describe these skills):

Legend

- : irrelevant
+ : some knowledge required
++ : in-depth knowledge required

Role	Application Guide	Configuration Guide, Configuration Reference Manual	SQL and Data Model	JavaScript	.NET	TOPICA API, TOPICA API, Integration	TOPICA Source Code	Operations Architecture, Installation and Deployment
End User	++	-	-	-	-	-	-	-
Configurator	++	++	++	+	-	-	-	+
Application Developer	+	+	++	+	++	++	-	+
Framework Developer	+	+	++	++	++	++	++	+
Deployer	-	+	+	-	-	-	-	++