3 Crucial Change Management Models to Help Your Company Adopt New Technology

In the Technology Age we are constantly bombarded with new initiatives, new technology and the latest Shiny New Toy.  Generally our leaders set us on a course of technology adoption with minimal consideration or involvement from those individuals that must use this Shiny New Toy.  As a Technology Provider we find this consideration (or the lack of) a critical point for the success or failure of a given endeavor.  Management teams that support the use of a project or organization level Change Management strategy can dramatically improve system adoption, investment realization, employee satisfaction and performance.  In the sections below you will find multiple approaches that have been successfully adapted and used in technology engagements.  The specific model is not important, but using one may just be the key to consistent success.

Navigating organizational change at a project level cannot be done in a vacuum.  It must consider and involve the full project team and any external influencers.  Consistently articulate and support the relationship between the project team and related business resources. Define the roles and responsibilities. Work deliberately to create a partnership with a singular goal in mind—delivering the intended results and outcomes of the project.

There are a number of change management models that can be uses to successfully assess and implement a change. Each of these models include a number of activities or practices to follow in making organizational or technology changes.

McKinsey 7-5 Framework

The McKinsey 7-S Framework, developed by Thomas Peters and Robert Waterman is a popular approach.  It provides methods for assessing the current state of an organization, the future state and what needs to change.  It addresses seven key factors: shared values, strategy, structure, systems, style, staff and skills.  With a technology change this structure could be used to address impact on the business team based on its core values, skill sets, strategy, etc.  The objective is to look at the various aspects to gain an overall perspective of the change and its true value.

Kotter’s Eight-Step Change Model

A second type of change management model is Kotter’s Eight-Step Change Model, developed by Harvard Business School professor John P. Kotter.   This eight-step process is fairly simple and straight forward.  It focuses on acceptance and preparation for the change, rather than the specific change.  The idea here is to ease the transition into a new approach.


Last but not least is the The ADKAR model, created by Jeffory Hiatt (founder of Prosci).  The ADKAR model uses a bottom-up approach which focuses on the individuals that need to change.  It’s not a strict set of steps, but more a set of goals used to effectively plan for a change.  It focuses on the individuals’ needs rather than the technical aspects to achieve success.

Change management at the project level is important for benefit realization and value applied to a particular initiative.  It is a structured approach to create logical strategies and processes to improve employee adoption and usage. It is a way to help achieve the intended benefits, realize ROI, mitigate cost, risk and create value.  It is an important tool that can make projects and initiatives are more successful.

Take time to explore the various models and take what is valuable to you.  Stay flexible when following a model and adjust the approach to your team, rather than following it too rigidly. At a personal and organization level the way change is perceived and accommodated is unique based on your cultural norms.  There is no right or wrong approach, having one is the key.

Feedback is always welcome.  We would love to hear how your organization approaches change management with technology projects.

Have change management questions? Contact us today!

[pardot-form id=”16003″ title=”Blog- Todd Packer – 3 Crucial Change Management Models to Help Your Company Adopt New Technology”]

Value of Post Go Live Support

Businesses are constantly striving to gain competitive advantage and efficiencies through process improvement and increased productivity. Companies like Oracle, IBM and SalesForce provide the technology and applications to businesses to enable them to automate and improve their performance. Businesses often invest a lot of money to customize these applications to fit their business need.

Once a business has purchased the application whether it is On Premises or Cloud Based, it often looks to an outside vendor to customize the application to their organization’s needs. The vendor uses highly skilled resources who work with the business users and internal IT team to perform functional and technical analysis. The vendor will design and implement the functionality required by the business. Once the implementation of the customization to the application has been completed, the vendor will hand over the customized application to the internal IT team to continue the support and maintenance of the application.

At this point most businesses are faced with the challenge of continuing to support and enhance the customized application as the users become familiar with the application and want to make changes. More and more companies are focusing on their core business and relying on a vendor or a pool of specialized vendors to provide the support services for their IT infrastructure and applications. Today there are many different IT support models that are available. Some of the models for post go live support are as follows:

  1. Time and Material
  2. Retention Model
  3. Managed Services

Time and Material

The Time and Material model may be used when the business has a small IT team or an IT team that is not familiar with the technology that needs to be supported. The vendor’s support resource becomes an extension of the businesses IT team providing day to day support. Businesses often use this model to continue working on enhancements as they have contracted the support resources for 100% of the time and have to utilize them. This model may continue until the internal IT team has the skills to take over all or part of the support functions from the vendor’s support resources. This model is expensive as it is almost like hiring a full time contract resource with the right skillset. The advantage is continuity as one of the vendor’s resources who worked on the implementation often is the resource who supports the application. The vendor will also provide a backup resource from its pool of resources when the dedicated resource is on vacation or is not available.

Retention Model

The Retention Model provides flexibility when it comes to the budget and could be long term option for providing application support. This model is made up of a fixed fee and a time and material component.

  1. Fixed fee per month for a fixed number of hours per month
    1. Fixed fee covers a fixed number of support hours per month
    2. The Fixed Fee is use it or lose it and is paid to the Vendor whether or not all the support hours are utilized
    3. It is up to the Business to provide work to cover the fixed hours per month
  2. Time and Material for all support hours above the fixed number of hours per month
    1. Utilized when additional support hours above the fixed number of hours per month are needed by the business
    2. Prior approval must be received from the business for any hours worked above the fixed number of hours per month

The advantages of the Retention Model are as follows:

  1. Better control over the support budget as the business does not require a dedicated resource for support
  2. Level of Support can be tailored according to the need of the business
    1. Business may start with 80 fixed support hours per month after Go Live
    2. After 3 months the fixed support hours per month may be lowered to 40 hours
  3. Continuity as the vendor has a pool of resources with the skill set to provide support
  4. Different vendor resources can provide support depending on the issues which may be environment related, infrastructure related or application related

The business must constantly prioritize the support to make sure the vendors support resource is fully utilized and is addressing the high priority issues within the fixed amount of hours per month

Managed Service Model

The Managed Services Model is a broader support model that encompasses environment support, infrastructure support and application support. This is a more expensive model which covers broad areas of support requiring diverse skillset and experience. Instead of contracting with different vendors to provide support for the environment, infrastructure and applications, the business contracts with a single vendor. The single vendor takes on the responsibility for supporting all the areas of support using their own team or specialized partners. The business has to deal with a single vendor who tailors the Managed Services support with a combination of Fixed Fee and Time & Material options for the different support services based on the needs of the business. This model not only brings together diverse skills from different vendors, but it also brings together specialized monitoring tools and processes from different vendors under a single umbrella. The Single Vendor takes on the responsibility and overhead of coordinating the work with all the vendors who provide support. The billing is also simplified as the business has to deal with the single vendor for all billing issues.

Contact us today for more information on the value of post go live support.

[pardot-form id=”15999″ title=”Blog- Mubeen Bolar – Value of Post Go Live Support”]

Business Strategies for Managing Up

team management

Business Strategies for Managing Up

By: Matt Chumley | Project Manager

Coming from someone who jumped into the IT consulting world as a project manager at a young age, the realization hit pretty quickly that managing resources on my projects that are older and more experienced would be a challenge. Learning various ways to approach and handle this challenge became an absolute necessity if I had any hopes of being successful in a project management position. It became very clear starting with project number one of my career – project success was directly impacted by my business relationships among those resources working on each project.

The primary goal as a project manager is to become the most effective employee possible and creating value for company. The best path to accomplishing this goal includes creating healthy relationships with everyone you work with. Here are a few of the most important aspects of “managing up” that I have learned as a young project manager.

Realizing How Much You Can Learn From Co-Workers

One of the biggest mistakes you can make as a project manager (of any age) is to refuse to learn from the resources on your team. In virtually every case throughout my career, project team members have been with the company for years, they’ve worked on similar projects multiple times in their past, and have already developed problem solving skills that can be applied to current projects/situations. The best and most beneficial way to utilize this is by opening up meetings/dialogue to allow your team members to become resources for you to learn what works and what doesn’t within the company. They’ve been with the company longer than you, and therefore can help you be successful. Also, chances are obviously very high that someone working on your project has already done the necessary technical steps in the past. In result, the project manager can be more effective by using their technical knowledge to determine project milestones and timelines.

On weekly, sometimes daily, basis, I will ask team members if they’ve seen a particular problem before and what the correct course of action was in the past. I will run my own ideas across them as far implementing a solution so that they can give me advice on how a particular project can be more efficient. Most of the time, my co-workers have been more than willing to spread their knowledge. In the end, everyone is happy because the project is successful and I now have further knowledge to make my next project even more effective than the last.

Respect From the Project Team Members Already Exists, So Long As You Do Your Job

It is incredibly important to understand that the employees working on your projects are focused on project success, and they are not focused on the age or experience of the project manager. It becomes a huge problem if a young or new project manager feels the need to prove themselves while running a project instead of focusing strictly on client satisfaction. At the beginning of my career, I found myself trying to avoid challenging my project team members that were older or a held a high position within the company, thinking I could end up being embarrassed. That

is simply a mistake. The truth is that team members do have a healthy respect for any other young employee, and “challenging” them can actually enhance that respect as long as it is done in the correct way. If a manager does not do things like challenge team members, recognize the success of teamwork, and provide proper resources to the team, then that is when respect can be lost. At that point, a project manager is simply not doing their job – so the two points of doing your job and respect are directly related, regardless of age/experience.

You Can Relate to Each Project Team Member, Regardless of Age or Experience

When I started as a project manager in the IT consulting business, it seemed like I would never be able to relate to those I was managing on a particular project – whether it was because of age, experience, or their job title. In reality, there are a number of ways to connect with your fellow employees. This is incredibly important for project managers, because developing personal connections allows them to figure out how to motivate team members and figure out what makes each person produce their best effort. Working part-time as a teenager in college at a restaurant, it was easy as I was working people in the exact same spot in life for the most part – trying to earn some extra cash while concentrating on schoolwork. Now, it is more difficult because I’m now managing people that are a decade older than me and have been in this business much longer than I have. I have learned that building some kind of personal connection is still possible. I can still ask about past work experiences, career aspirations, and even their families because I have all of those things too, they just may look different than those that are older with more experience. Young managers in the business world will be much more successful if they find effective ways to “manage up”.

Project Management: A Team Exercise

project management blog image

Project Management: A Team Exercise

By: Mubeen Bolar | Director, Project Management

The Project Manager is tasked with ensuring an IT project is delivered on time and on budget. Depending on the structure of the team a Project Manager is often someone who has the responsibility to make the project a success, but no authority over the project team members, as they may not report directly to the Project Manager. One of the responsibilities of a Project Manager is to motivate the project team to complete their individual tasks on time and under budget. The cumulative effect of each team member being on track helps the project to be on track, both in terms of timeline and budget.

There are three major areas of project management that should be a shared responsibility across the project team.

  1. Budget
  2. Timeline
  3. Risks

1. Budget:

The Project Manager must make each project team member aware of the budget for the project. The individual actions of a team member can impact the cost by either increasing or decreasing the level of effort on individual tasks. A developer who is aware of the budget should make every effort to work efficiently, taking an approach to implementation that does not increase the level of effort. A developer who is not aware or not responsible can increase the level of effort by either over engineering or developing additional functionality that is not required by the client. Any increase in cost impacts the budget, resulting in the project going over budget.


2. Timeline

Timeline and budget go hand in hand. When the level of effort on a task increase, it results in an increase in the cost. Ensuring that the level of effort is under control normally results in the project being on time. There may be some cases when the timeline may not impact the level of effort and cost. This can happen when a team member is on vacation and there is a delay in implementing the task. Clients are sensitive to shifts in the timeline as it impacts their go-live schedule. This can result in a customer satisfaction issue.


3. Risk

Risk Management is a team activity. Risks must be identified as early as possible and mitigated to ensure that the project remains on budget and on time. This requires each member of the project team to communicate the emergence of a risk as soon as possible. When a risk arises the project team must come up with steps to mitigate the risk.


When a project team takes joint responsibility for Budget, Timeline, and Risks, the chances for success increase. Project Teams often receive compensation in the form of a bonus based on the Profit Margin of the project. This encourages team members to take an active role in controlling the budget, timeline, and risks associated with a project.

Contact Mubeen or TekStream Today

Why is Risk Management important on every project, big or small, and how do we track it?

Risk Management

The Importance of Risk Management

Jonathan Bohlmann | Solutions Analyst

“If you are never scared or embarrassed or hurt, it means you never take any chances.” – Julia Sorel

Why is project risk management important? Risk Management is not a pleasant topic, and some people would like to avoid it.  Many times when a Project Manager brings up the topic of Risk Management, the participants get that glossy look in their eyes and zone out. Most of the time it is hard to find someone who is willing to even discuss the topic of risk, but Risk Management is vital to the success of a project.

Whyis Risk Management Important in Project Management?

Experience proves that when a risk analysis is conducted for a certain project; problems are reduced by a staggering 90%.  In addition, in the article by the Project Management Institute, “Pulse of the Profession 2015,” it is stated that “83 percent of high performers report frequent use of risk management practices, compared to only 49 percent of low performers.” Managing risk helps ensure that your business is performing at an optimal level.  However, risk management is not a one and done type of deal.  Do you go to a doctor only once in your life time for a physical? Of course not. You go on a regular basis to help detect any problems at the earliest opportunity.  The same is true with risk; you take an assessment at the beginning and you regularly assess the risk throughout the life of the project. Some risks will no longer be pertinent or will have been mitigated, while others may come into play.

The following are a few benefits of risk management:

  • Increased operational efficiency by mitigating exploits that could normally drain organizational resources responsible for remediation
  • Increased revenue due to increased operational efficiency
  • Decreased number of incidents to remediate internally or with a customer/vendor
  • Clearer understanding of current threat climate
  • Creation of a risk-focused culture within the organization

Risk management needs to be given greater authority during the life a project, and Senior Executives must lead risk management from the top.  Risk management should gain enough attention in the organization at a senior level, so that the organization can properly evaluate and elevate the risks when needed.  In addition, risk needs to be adaptive rather than static. As previously mentioned, if the risk analysis is only assessed at the beginning of the project and never again, you may be monitoring risks that are no longer relevant and miss the new risk signals.  For example, if the union employees are negotiating a new contract while your project is being conducted, a risk could be the union goes on strike and could prevent part (or all) of your project from moving forward.  Once that contract is signed, the risk goes away and no longer needs to be monitored.  At the same time, a major storm is developing on the west coast and is expected to hit your area which could impact your project.  If you are not evaluating all potential risks during the life of the project, you will be unprepared for any new risks.

The business division is accountable for risk mitigation decisions. Therefore, they should always be educated on the project at hand.  They should also be subject matter experts and accountable for managing and coordinating the process, but are not the decision makers. Senior leaders are responsible for making the decision of how a risk should be mitigated. Or, when a risk issue is realized, they have the authority to reduce or mitigate the risk based upon the core business objectives.

How does TekStream manage risk?

Project Risks are items that have the likelihood to occur and impact a project.  Risk Issues are risks that have already occurred.  Using JIRA® to help us manage risk, TekStream has standardized the risk management process which in turn allows our customers to monitor the risks and evaluate/implement risk strategies.  This creates a knowledge base of risks across the project and enables transparency into the Risk Management process.

In our Oracle WebCenter projects (on site, PaaS, and IaaS), we start to manage risk by conducting a QuickStream process to gather requirements before developing the Phase 1 project plan.  During the discovery and define steps we look at all aspects of the project from hardware to resources to human interaction to software and evaluate, with the client, any risk that may come up in the project.  This gives the customer the first of many reviews of the risks to be both aware of and possibly mitigate the risk before the full project kicks off.

My hope is the reader will come away with a better understanding of why risk management is as important to us and your company on their next project.  If you have any questions on risk management, please reach out to me and we look forward to helping you on your next project.


Contact Jonathan or TekStream Today to learn more.

Managing Your Project’s Budget

Project Management

Managing Your Project’s Budget

By: Savitha Meda | Project Manager/Solutions Analyst

As a project manager, I love the beginning of a new project. I always look forward to having that first kickoff meeting with your team where everyone is excited to tackle a new challenge. As a project manager, you work on ensuring everyone that a great idea is in store for them for next several weeks or months.

When working in a firm like TekStream, project managers are often involved in the sales cycle. Therefore, we have a solid plan on how to deliver the project. With any project, our ultimate goal is to deliver a solution that our customers are excited about and that will add value to ultimately improve their business processes.

How does this relate to managing your project’s budget? Easy, none of us have a crystal ball or can predict the future. The status of the project’s budget helps us keep our finger on the pulse of how the project is tracking and ultimately how we are driving customer satisfaction. A project that is running over budget can be warning signs of issues such as scope creep, improper resource mix, or even not being able to meet delivery timelines promised.

The ultimate goal of a project manager is to deliver a project on time, on or under budget, that meets the customer’s needs. If a project goes over budget (which can happen for numerous reasons) the project is not considered financially successful and may not deliver the solution a customer expected in the timeframe they specified.

Here are a few strategies for successfully managing a project’s budget:

  1. Manage Project Scope

    Without knowing all of the variables at the beginning of a project there is always the possibility of unplanned work finding its way into the project plan. Either customers change their minds after design or development has started, or the team uncovers some additional work that needs to be addressed. Scope changes are considered okay if at the end of the day it helps us deliver a better solution. The key is to minimize the impact it has on the budget and the timeframe of delivery. Communicating these changes up front to the customer in a timely manner helps us determine if this extra work is really necessary. If it is, a Project Change Requests (PCRs) should be executed for work that was not covered in the project’s initial scoping efforts. PCRs authorize additional funding to cover the cost of extra work, and keep the project at its new budget.

  2. Manage the Plan in a Timely Manner

    The key to this strategy is to review your project plan often and ensure it reflects what is happening “on the ground”. This is done in a few ways. The first way is to compare all the tasks that were needed to be completed in a certain time span (I do this on a weekly basis) against what has actually been completed. This helps assess what was supposed to be completed and if any further reprioritization is needed for the work that still waiting completion. If it looks like tasks are being finished earlier than anticipated, then that may allow for a buffer in case other tasks take longer. Or, more importantly if tasks are taking longer to complete, this may be a warning sign of scope creep or the need to change that resource working on the task. Either way, these overruns need to be escalated with management in a timely manner and communicated to the customer in case it jeopardizes the ability to deliver a project on time.

  3. Manage Resources

    Meeting with your project team regularly will also help ensure the project budget stays intact since your team members will contribute to the project costs as well as drive revenue (as they record billable hours). Weekly team meetings help with the process of reviewing the tasks needing completion as well as informing the team of next steps. Sometimes, these meetings uncover the need to add extra team members or swap out tasks between team members to maintain the project budget and timeline. Typically, the project manager owns managing the project plan. However, the plan should be reviewed regularly with the team to assess if the project is on track for on time delivery and help to ensure everyone is being utilized effectively. Not only does this help ensure the plan is reflecting what is actually happening “on the ground,” but provides a shared sense of responsibility amongst the team for a successful project delivery.

Hopefully you have noticed that communication is the common theme in the above strategies. The project budget helps provide the data we need in order to communicate changes to scope, not only to customers, but to management and the project teams as well. It also uncovers resourcing opportunities/challenges and ultimately helps asses if we are going to deliver a project on time and on or under budget. The project budget is a living, breathing animal and needs to be reviewed regularly. In my experience, project managers who follow the steps above have a good grasp on their budgets throughout the life of their projects and are able keep customers and management happy.

Contact Savitha or TekStream Today

Waterfall vs. Agile Process for PaaS Projects

Waterfall vs Agile

Waterfall vs. Agile Process for PaaS Projects

By: Matt Chumley | Project Manager/Solutions Analyst

In order to attempt to choose between Waterfall and Agile approaches to a project implementing a cloud solution, it’s important to have a clear understanding of the benefits and drawbacks of each methodology. In a technological world that is increasingly becoming more and more demanding, aspects of Agile are being used to facilitate projects to successful completion.

The push towards a full Agile approach to cloud solutions, such as PaaS (Platform-as-a-Service) projects, could potentially post major concerns and problems to your project. This is why the best approach should ideally be some type of hybrid, with the user/manager’s choice of how many Agile aspects are actually used while keeping some of the structure of Waterfall processes.

Benefits/Challenges of Waterfall vs Agile

Waterfall Approach

Waterfall Approach

(Figure A)

The Waterfall method involves using strict, concrete plan from day one of the project with tasks in a specific sequential order. Each stage in the process is treated as its own component, and there is no going back or reverting to previous stages of the project that are already completed.


  • Plan is very strict and predictable
  • Promotes a repeatable process for others to follow
  • Strong documentation is key
  • Ideal for projects where all requirements are known up front, and very few changes are anticipated (as change means high cost)


  • Since the plan was set at the very beginning and is fixed, there is no room to incorporate changes mid-project. Therefore, once an error is detected in testing the team must start all over from the beginning.
  • Being only one phase dedicated for implementation, testing can only occur at the end of project. There is no chance to review/test any deliverables mid-project.

Agile Approach

(Figure B)

(Figure B)

Unlike the Waterfall method, the Agile approach embraces change and allows the Project Manager to account for uncertainty throughout the project plan. The project is broken down into multiple iterations, or sprints, in order to create multiple development cycles.  Each sprint is, in essence, a small project that involves a working deliverable that can be reviewed/tested.


  • Better and faster feedback on deliverables
  • More frequent iterations meaning less impact with changes
  • More requirements met
  • Less change requests
  • Faster time-to-market


  • Time to completion takes priority over documentation.
  • Much of the project cannot be predicted, as only the first iteration is planned at project start.
  • Difficulty of creating a project team that has the correct training and skill sets to complete a fluid project.

Hybrid Approach for PaaS Solutions

It is evident that the two project management methodologies are polar opposites and that one must choose either one or the other. When you examine the benefits and challenges of both Waterfall and Agile, it can be beneficial to use certain parts of each process and blend them together when planning out a cloud solution project.

One of the best examples involves the combination of speed (time-to-market) with proper documentation.  When working on a PaaS solution, the client would most likely desire to have the Agile benefits of speed and flexibility. That would allow incremental steps in developing the overall solution, and changes to be inserted at various points.  However, the lack of documentation may not be appealing to the client as they consider employee turnover or hiring new developers for cloud implementation.  This is why the idea of incorporating the rigid structure and planning of the Waterfall method may be very beneficial.

Many times a company may choose to use both Waterfall and Agile methodologies simultaneously and in-tandem. Using the defined, repeatable process for established services, while using multiple small iterations for new activities like migrating customers to the cloud.  The choice on management styles does not have to be black or white, as it can be some type of hybrid in which the parts of each process that benefit that particular project can be hand-picked and used.  It is up to the discretion of the Project Manager to put together the most effective processes in order to satisfy the goals of the project.


Contact Matt or TekStream Today

Mediating Task Events to Integrate Dashboards with Existing SOA Tasks


Mediating Task Events to Integrate Dashboards with Existing SOA Tasks

By: John Schleicher | Sr. Technical Architect

Business Activity Monitoring (BAM) services are typically licensed with SOA implementations.  Their incorporation into SOA orchestrations and BPM workflows are not that prevalent; however, the incorporation of dashboards for BPM task visibility should not be considered as problematic as they may easily be integrated with SOA mediation in a loosely coupled fashion such that the existing sources are essentially unaware of the additional capability that is engaged.

Within this article, we will walk through the steps necessary to take an established BPM task (whether BPEL based or BPMN based) and with minimal invasive activity add the components necessary to integrate with BPEL sensors for presentation in BAM dashboard.

Of course, the business knowledge associated with the tasks and internal payload as well as BAM objects are typically highly sophisticated and we are going to abstract that sophistication for the purpose of this article.  We will employ an existing application, but the details of such are irrelevant and the steps followed would be the same no matter what the application type.

Also, it is assumed that the BAM data objects are in place and the sensors to engage BAM are externalized to a BPEL web service.  This externalization is recommended as it facilitates the integrations with multiple tasks or allows for additional projects to leverage the BAM objects and their sensor integration points.

 The steps required for after the fact BAM dashboard integration are:

  • (Assumed in place) BAM objects in place with sensor engaged BPEL service updating the BAM data objects
  • Add the BPEL service to the targeted task composite as an external reference
  • Add an event mediator to the targeted task composite
  • Add data transforms for task events (Assignment, Update, Completion)
  • Configure the mediator filters
  • Configure mediator transforms to route business data to the defined BPEL service

For this exercise, the BPEL service to engage the sensors is ‘activityReporting’ and we will be adding task event mediation to the Rescan task.

Step 1: (this one is pre-requisite and assumed in place)

Step 2:  Add the sensor BPEL service to the targeted task composite.



Step 3:  Add an event mediator.

For this step we need to get the EDL for task events.  This file (HumanTaskEvent.edl) is located in the jdeveloper integrations directory along with other workflow schemas and wsdls.  Copy it to the local task project directory.

Drag a mediator component into the target task composite:



Double click on the mediator and subscribe to the Human Task events by hitting the ‘+’ sign and identifying the event file.


Elect the events required, normally OnTaskAssigned, OnTaskCompleted, and OnTaskUpdated to support standard dashboard activity.


Now to populate the mediator’s routing rules for the event subscriptions (here we will focus on OnTaskAssigned but the same technique applies to all).


Select the green ‘+’ sign and chose permanent routing rule and select service for the invoked target.


Pick your target service that manages the sensors.


Step 4:  Apply filters for the transform and map the task data to the data expected by the BPEL service managing the sensors.

Here we will filter on task data ensuring that the task event is associated with the Rescan task.  On systems will multiple task deployments the task event will fire for all tasks and must be filtered.

Depressing the funnel icon gives the filter dialog. Probe the task data so you can filter on sca/task:compositeName and ensure it matches the task’s composite name.


Step 5:  Create/assign transforms to route your task data to the BPEL service.

Select the transform icon on the right and select ‘Create New Mapper File’ and map the appropriate elements for your business case (this will be specific to your business case and implementation strategy):


When the mapping is completed your task assigned mediation event appears as:


You are finished with the OnTaskAssigned event and can extend these activities to OnTaskCompleted and OnTaskUpdated.

Once deployed, you may apply a task assignment the em trace will show the activities in the process trail as such:


This particular invocation didn’t pass the mediator filtration (i.e. it wasn’t a Rescan task event that fired) and it ended at the mediator.  If it was a Rescan assignment event you would see the callout to the static routing task.

All of the above was added to an existing task process without engaging any of the previously developed sources (i.e. it is truly loosely coupled).  Once you get a handle on the technique and can apply existing processes, it is a quick and easy task to add human task event mediation to existing processes and extend this information to a sensor based process to see your data on a BAM dashboard.