Roles and activities

Operational Decision Manager comprises a set of modules that operate in different environments. Each step of the development lifecycle requires a specific set of skills and these activities can be divided into different users or roles. Roles within the team must be established early on in the development cycle.

Decision Server Rules and Decision Center have different roles and activities compared to Decision Server Insights.

Decision Server Rules and Decision Center

Decision Server Rules and Decision Center work together to provide a comprehensive decision management environment. The following figure shows the various activities that are involved and where each activity is carried out.

Two categories of users are involved in developing and maintaining a decision management solution:

IT users: Architects, developers, and administrators develop and maintain the rule application.
Business users: Business analysts, policy managers, and rule authors develop and maintain the decision logic.

The following table describes the different types of IT and business users that are involved in developing and maintaining a decision management solution.

Table 1. User roles for the development of business rule applications
Role	Activities	Description
	Design Integrate Deploy	Architects work mainly in Decision Server and have the following responsibilities: Defining the granularity of the decision services and their interface with the calling applications. Defining the project organization so that it is convenient for developers and business users alike. In particular, they are responsible for setting up the data model (XOM) that is used as the rules vocabulary. Making sure that rule execution is optimized.
	Design Author Test Integrate Deploy	Developers are familiar with object models, APIs, and the development environment (Java EE application servers, Java™ SE). They work mainly in Decision Server and have the following responsibilities: Developing, testing, debugging, and deploying decision services. They provide input to the design of the rules. Integrating decision services in to business applications, by defining the client execution code.
	Deploy Administer Monitor Audit	System administrators work on the servers to ensure that they run smoothly. These servers can be for Decision Center or Decision Server. Administrators have the following responsibilities: Deploying and configuring the server and database for Decision Center and Rule Execution Server. Managing user access to Decision Center and Rule Execution Server. Managing the overall deployment organization of decision services, by ensuring that the decision services can be shared across environments, and redeploying decision services as changes are made. Configuring trace data sources for testing purposes. Deploying applications, and restoring a particular application state. Tracking and monitoring rule execution, by generating detailed execution reports.
	Design Author Test Synchronize Manage Validate	Business analysts act as the bridge between business and IT departments, from design to integration inside a software application. They work in Decision Server and Decision Center. Business analysts have the following responsibilities: Designing a formal specification for the rules, with validation from both developers and policy managers. Defining the vocabulary that is used in rules. Identifying candidate business rules. Writing and organizing business rules so that rule authors can maintain them. Validating that rule execution yields the expected results. Depending on their level of technical knowledge, business analysts can do tasks that are currently described as developer tasks. However, business analysts generally do not write code.
	Manage Validate Author	Policy managers are the owners of the decisions within an organization and work mainly in Decision Center. Policy managers have the following responsibilities: Participating in the design of a formal specification for the rules. Defining vocabulary elements with the help of business analysts. Managing releases and validation activities in the context of decision governance. Creating and updating rules. Reviewing how the execution of rules is orchestrated. Reporting on the status of the decisions. Testing rules to ensure that the rules give the intended business outcome. Running simulations to assess potential impact of changes to rules.
	Author	Rule authors work in Decision Center, and have the following responsibilities: Updating and sometimes creating rules. Reviewing business rules. Creating change activities in the context of decision governance.

Decision Server Insights

Decision Server Insights comprises a set of tools to develop, deploy, and configure solutions in the runtime system. Each step of the lifecycle requires a specific set of skills and these activities can be divided into different users or roles.

The following figure shows the roles and activities that are involved in developing a solution.

Table 2. User roles for the development of solutions
Role	Activities	Description
	Design Integrate Deploy	Architects work mainly in Insight Designer to integrate configurations for the solution. They identify the incoming events that require updates to the entities of the solution, and the outgoing events the solution emits to the outside world. It is likely that the architect is a separate person to the solution developer, and does not have to know about the application's business logic. They are exclusively concerned with managing integration touch points. An example of an incoming event: `A request from a Point of Transaction starts a sales transaction between a customer account and a merchant account.` An example of an outgoing event: `Notification to the Point of Transaction that the purchase is successfully applied.` An architect maps external formats with the solution, and writes code to handle complex interactions with other applications and databases. Designers must find out what business dashboards are required to monitor the solution, so an architect can design and help to assemble these services for operations staff.
	Design Author Test Integrate Deploy	A solution developer uses Insight Designer to construct a solution that includes entity models, event definitions, agent definitions, simple rule agents, aggregation and correlation rule agents, Java agents, and predictive model agents. The overall solution is the aggregation of all the developed projects in a set of deployable packages. A developer creates the agents that process the incoming events: The developer identifies the agents that are necessary to process the solution. The developer must specify the triggering event for each agent, and identity the specific entity that is operated on by each agent. Standard stateless or stateful rule semantics and internal orchestration can be used to express the function of the agents. The function is expressed by a Java class with access to its bound entities. Events that are generated by the agents are also specified and must clearly state whether they are internal or external. For external events, declarations of the target endpoint and protocol for the emitted event must be specified. The developer can also develop a predictive scoring agent to integrate scoring models. To compute a score, you must map the entity to the inputs of the scoring model. The use of time windows and aggregation across events requires the state of the entity to be managed by the solution. The process of developing a solution is iterative and includes the following examination: What entities are referenced in the rules? What events can arrive that trigger updates to these entities? What is the incoming payload of each event? How is the event payload correlated with the identifier of the entity to update? What aggregate computations need to be run that span entities? Are any predictive models required by the business rules? How is the business logic divided between the event router and the agent implementation? What integration and connectivity infrastructure is required to receive the incoming events? What external systems are notified by agents?
	Deploy Administer Monitor Audit	The administrator role is to install, configure, and maintain all the tools that the development team plan to use. They do not always know how the tool is used, but they are often called when there are problems with the tool. In most cases, a lab is divided into different environments, which are likely to include a development environment, a staging environment, and a production environment. Before anything goes into production, it is installed in the staging environment to allow some time to pinpoint and fix any problems. The person in this role is expected to have an answer about what caused, or is causing, a tool problem. A system administrator keeps the IT infrastructure up and running. They constantly assess the requirements that are needed to support the evolving databases and applications. A database administrator ensures that the data processing needs are satisfied, and maintain the databases to ensure high availability and good performance.
	Model	Decision Server Insights solutions are systems of record in which data entities represent the primary objects of business interest, for example an `Account` or a `Customer`. These objects are updated by services that respond to events that carry information relevant to these entities. Entities are updated by policy (business rules) based actions or computations that are generated by analytics. A modeler must have a complete view of all the entities at the time of interaction to be able to identify risk and opportunity situations. An understanding of the past, present, and future business events is paramount to drive the appropriate and complete set of actions, or communications. The design of the business policy logic needs to be comprehensive and agile enough to remain responsive to business goals, regulatory initiatives, and changing circumstances. Ideally, the modeler can anticipate situations before they occur to maximize the value of early response. A modeler models the definitions that are required for the solution: The modeler defines the entity model, which is a task similar to creating a class model for a specific domain. Each entity definition consists of one or more top-level classes that are uniquely identified by a common key, which collectively describes one of the primary business entities in the solution. The modeler must identify a key for each of the entity classes, and keys for the enclosed top-level classes. Keys for the top-level class must be resolvable to the entity key. For example, if the key to a customer account entity is the account number and the account demographic information contains this key, and the account history is identified by the account number plus a transaction id, then the id is resolvable to the entity key of account number. As part of the modeling, a business vocabulary must also be assigned to the object model so that the rules-based programming model can access the data. The modeler specifies key attributes for the physical mapping and configuration of entities into partitions and defines a strategy for entity off-grid persistence. This strategy includes mapping the entities to a database, creating constructors for new entity instances, and adding the necessary persistence policies.