Beginning-to-end in five steps

Step 1: Identify your situation

Begin by documenting what your business struggles to respond to, and what situations you are already using to impact your business results, internal productivity, efficiency, and agility.

Clarify if your business transactions or events can be analyzed over time to identify or detect specific contextual patterns, trends, sequences, or interactions that the business does not detect. It might be risk-based such as detecting fraud, opportunity-based such as using context or location to offer discounts, or compensation-based on client/partner interactions with your business.

The next level of analysis is understanding your situation. Use the following set of questions to help you gather more information about your situation:

• Does the business understand how, why, and where these events occur?
• Does the business have existing rules that they can use to detect these events?
• Does the business have existing predictive models that they use to detect these events?
• Do the events have information associated with them, so that they can be differentiated when they occur?
• Are the events stored as historic context or state, such that a pattern can be detected over time to better understand the impact?

Have a conversation about event sources to determine how to integrate with existing sources of events, and how to gather new event information. Promote the concept that every change to the state of an application can be captured in an event, and that these events are stored for the time they are interesting to the application state itself.

Use the verbs sense, decide, and act in your conversations with stakeholders as you define the business situation.

Step 2: Model the entities and events

Use the description of your situation to drive further conversations about the entities and events that are required. Type the model in the business model definitions (BMD) editor in Insight Designer.

In some cases, you might have existing models and schema files that you can bootstrap from. You can use other modeling tools such as UML diagrams to model entities, events, relationships between them, and temporal and spatial logic.

Here is a UML class diagram for an entity of type Client and an entity of type Account.

An entity type is composed of a set of attributes, and a set of relationships to other types. An entity type has an attribute that acts as an identifier for entity instances. In this example, the client ID attribute is the identifier. The account entity uses the number attribute as its identifier. You define the relationship between entities by using the is related to construct. In this BMD example, an account is related to a client.

a client is a business entity identified by an ID .
a client has a name,
   an address,
   a preferred language,
   a churnScore .

an account is a business entity identified by a number .
an account is related to a client .
an account has an account type,
   a balance .

An event type describes the shape of an event. An event type has a set of attributes, and a set of relationships to other entity types. The following figure shows the relationship between four event types in UML.

An event has a timestamp attribute that represents a date and time. An event can have a location, such as the location of a withdrawal. In the business model definition language, you can model relationships between object types. The type of construct that you use determines the type of relationship. You can also define simple and multiple relationships. The following definitions show how relationships are modeled in the BMD.

a client related event is a business event related to a client . 
a client related event has a transaction time (a time) used as the default timestamp .
a banking event is a client related event .
a banking event has a location ( a point ) used as the default geometry .
a banking event has a country .
a banking event has a state .
a banking event has a city .
a banking event has a Land .
a banking event has a bankingEventId (string ) .
a banking event has a sequentialNumber (integer) .
a transaction is a banking event .
a transaction has an amount ( integer ) .
a withdrawal is a transaction .
a purchase is a transaction .
a purchase has a type of good .

Step 3: Create agents

After you modeled the entities and stored the business context and information to make the situational decisions, you can turn your attention to the business logic. In order for the business logic to be applied to an entity, agents are bound to the entities upon which they act. Agents must be bound to an entity because the business logic cannot be applied without the information or context that comes from the events.

In a common business situation, you are likely to need one or more event types, aggregates over time, and an update of the entity state when the situation occurs. It is important to identify updates to entities. An agent can modify only its bound entity, so if you can identify the entity to update you know that an agent is needed. An agent can process one or more event types, so the relationship between agents and events is not one to one. You can also have multiple agents that act on a single entity, but for different purposes.

In some cases, you might need to define internal events, also known as derived events, to allow agents to communicate with each other. To update another entity, one agent fires an event that another agent processes. When an event is received, agents are called in a sequence that follows the priority order. The higher priority value is processed first. You can use an explicit chaining to handle entity dependencies rather than relying on priorities. The first agent can send an event that the second agent listens for, the second agent also sends an event that a third agent listens for, and so on.

Sketch a solution flow diagram that shows the agents, the incoming events, and the derived and outgoing events. Name the agent to help indicate the bound entity of the agent. For example, a Customer Agent is bound to the Customer entity. In the following figure solid lines with arrows indicate inheritance relationships between events, and dashed lines with arrows indicate agent event subscription or emission.

To ensure transactional integrity and performance, the programming model must target updates to data that is local to the bound entity. Before you define relationships between entities, you must think of the lifecycle of each of these entities to avoid testing entities that do not exist. For example, in a banking solution, you are interested in client entities, the events that affect state, and the type of agents that act on these events.

Step 4: Detect your situation

It is important to think about the sequences of events (and the state of entities) that you need to push into the system to test that a situation is (and is not) properly detected. You can use Insight Designer or the TestDriver class to define some basic scenarios or JUnit tests to begin this testing. At this stage, you might even want to create a test harness; to be able to replay directories of events that are saved as XML under varying conditions and monitor the behavior and outputs.

Step 5: Write rules

Rules define the action to be taken when an agent receives an event. The vocabulary available in the rules comes from the elements that are defined in the business model and the agent descriptor. A rule can be expressed by using business terms, variables, operators, and values.

As you develop your business logic, it is not unusual that you discover hidden ambiguities in the definition of the situation and these tests need to be implemented in rules. As you seek answers to the following questions, the number of rules are likely to increase and provoke further conversations with the stakeholders.

• What happens when the situation is moved to a different time zone like EST, GMT, CET?
• What time zone does your solution work in?
• What happens if you receive an event that is late?
• What if an event never receives the stop event for a start event that is received?
• What can you do if you receive events out of logical order?