While BAM is an incredibly powerful tool, it shouldn’t be the only tool utilized in building your BPM practice. In fact, organizations with more than one operational intelligence tool are those that have much higher levels of visibility into the business and higher project success rates.

In this final chapter, we’ll conclude the book by covering

• BAM best practices: BAM implementations built better as a result of practices within the organization
• BAM architectural evolution: BAM, as a technology, built better with each successive generation
• BAM branches out: BAM solutions built better by including multiple operational intelligence systems
• BAM to the future: BAM being built better by Microsoft updates to the product

While this chapter doesn’t include any hands-on exercises, there are a number of exercises you may put into practice to build better BAM.

BAM Best Practices

By this point in the book, you should have a thorough understanding not only of Microsoft’s implementation of BAM, but also of some technical best practices as well. Numerous recommendations for executing BAM projects, in general, emerge irrespective of vendor.

A recent Forrester Research white paper, “Best Practices: Business Activity Monitoring Adoption,” captures five recommendations for BAM adoption, upon which we expand:

1. Create a Center of Excellence (COE): A Center of Excellence is a learning community in which participants apply their knowledge, experience, and varied skills in leadership development, systemic change, continuous improvement, and best practices.

   In order for BAM implementations to be successful, such an environment must exist and be fostered by the executive sponsors. As IT members face common challenges involving better process and providing better metrics to decision makers, members of the COE may collaborate and deploy BAM solutions to address them. When identifying those whom you want to be part of the COE, recruit members from diverse groups within the business to provide for a wider range of opinions. Ensure that COE members have diverse skill sets; that is, avoid having a large concentration of any one role, like developer, business analyst, DBA, BI pro, and so forth.

   As part of the COE creation, consider creating a BAM toolkit including templates for questions to ask when building a dashboard or an observation model.

   For projects that originate from the COE, determine your project methodology up front and get buy-in from not only IT stakeholders, but also your financial stakeholders. BAM and BI projects are often assailed for taking too long and producing too little. In order to improve the operational efficiency of a process or a business over time, it is “time” that is imperative. Therefore, adopt an iterative development cycle with regular deliverables, and be sure to keep an eye on budget at all times.

   The goal of the COE should be to continuously promote a stronger working relationship between IT and the business, and ensure that the relationship is reciprocal.

2. Involve operational staff and midlevel management early: The quality of a BAM implementation is directly related to the quality of the people involved.

   If solid business planning, analysis, and design have not gone into building the observation model, your large group of data-hungry consumers expecting a heaping portion of information filet mignon will be served a small portion of last week’s data leftovers. We have witnessed observation models built around describing activities for data that does not exist because a BizTalk developer or systems engineer was not involved. There have also been cases of robust observation models that provide large amounts of data, honed and processed, and further distilled into well-presented information for massive amounts of consumption. Unfortunately, the decision makers were uninformed as to the availability or the validity of the information. Get people involved and ensure that everyone understands their role in not only building the observation model, but also committing to better process management.

   Remember that BAM, as a technology, is applicable to many, many different projects and models. Therefore, it’s very important to choose your first BAM project very carefully and deliberately. You may select a small-scope BAM project because it provides a quick “win” to the business; or maybe you choose a large BAM project because it will bring a “win” to the most number of users possible. In general, though, we recommend starting small and “planting the seeds.” There will always be processes and projects that need improvement.

   If your IT environment is like most, any number of proprietary spreadsheets or custom-built web sites exist to track metrics as an evolutionary need through the years. While this approach is noble, it doesn’t provide project sponsors and senior-level management with any transparency as to how metrics were defined or why they were chosen.

   As with any project, IT or otherwise, expectation management is key. Have a clearly defined charter and scope for your project; be willing to expand that scope to monitor and refine other processes and complex systems; but also know when to set boundaries. Once operational staff begins to see the benefits of BAM, you’ll likely be surprised how fast the enthusiasm about using it spreads. It may be that some seek to build BAM portals and track metrics for items that shouldn’t necessarily fall under a BAM project. Just remember the saying, “To a hammer, everything looks like a nail.” By having a COE in place, these challenges can quickly be addressed while maintaining enthusiasm.

   Be very careful about the marketing of your BAM project. Using terms like “business process reengineering” implies that the processes aren’t functioning as they should be and may be considered offensive to some. Tread lightly in promoting BAM projects in which BAM is utilized to monitor employee productivity or human-centric metrics. The perception may be that those who are not viewed as productive by BAM definition metrics will face some punitive action. In general, try to market your BAM effort to the broadest audience possible, but at the same time, target and distill your message.

   Lastly, ensure that operational staff members know where, when, and how they may contribute. Raising an alert to a user is one thing, but if the user has no idea as to how the problem may be remedied, the alert will be ignored.

3. Choose the right metrics: BAM differs from operational intelligence tools like BI and reporting. Focus your BAM activities on operational metrics about how you actually perform business and how you want to perform business, as opposed to just defining KPIs.

   Metrics must be defined as part of an operational intelligence project. However, the real value provided by their implementation is not the end result, but the process of defining them. Understanding how upper or midlevel management maps high-level business requirements to low-level process data and milestones is key. The activity or KPI is merely the capturing of that collaboration.

   Don’t consider your metrics to be set in stone—BAM activities and views and KPIs are a reflection of business milestones and data considered to be of importance at a specific point in time. At some point in the future, whether a process may be considered optimized, perfected, or meeting its target may change. Revisit your original business goals and objectives, and refine your observation model accordingly.

   Remember that there are multiple viewpoints for data. Information may be interpreted differently according to many factors related to the consumer. Make it clear how the information you define in your observation model maps to specific business objectives. Also remember that mistakes happen—sometimes a milestone is defined incorrectly. Sometimes a threshold is set too high or too low. Sometimes a step in the business process is omitted. Have procedures in place to handle either misinterpretations of data or requirements, as well as “meta” information involving how data should be interpreted. Oftentimes, people see what they want to see. It’s up to you to help them understand the facts and the correlating information.

   Just as conclusions are presented and decisions made, commit to the betterment of that process. If a senior-level manager “wants” to make a decision, but has some hesitancy because of lack of supporting information, consider using lookups to provide greater detail, or deploying a new version of the observation model that captures additional information. The data you present is only temporary—consider using an iterative approach to expand the context of the data presented to users, and provide customization points where necessary.

   The input of mapping high-level business goals to BAM activities and low-level KPIs from one person is valuable, but the input from several people is even more valuable. Different data points are of different value to different people. Be sure to include as many voices as possible, while at the same time drawing a line when necessary.

4. Relate the COE to a business excellence team: BAM is a means to generate, process, and consume data around business activities. Once that process is built into a repeatable, well-honed one, it’s important to have an executive team that will do just that: execute.

   The BAM COE functions well to help refine, define, and extend the capabilities of BAM. Having a team that utilizes the output of the COE to make measured, well-informed decisions is equally as important. We have read about and know personally of instances in which BAM or operational intelligence information was passed on to decision makers who, ultimately, decided to ignore it, at times to their downfall. Whether decision makers decide to side with BAM data or not is their choice; but at some point they must decide. A business excellence team of executives is put in place for just that purpose.

5. Turn passive BAM dashboards into actionable dashboards: As referred to in the chapter on consuming BAM data, providing information and alerts to consumers is just the first step. Specific, actionable, measurable tasks must be assigned as a result of BAM data, and the best place to surface and assign is in a dashboard or personalized portal. As dashboards are personalized, unlike scorecards, they may provide a more hands-on approach to viewing and acting upon BAM data.

BAM Architectural Evolution

From a technology standpoint, BAM has come a long way since its humble beginnings, especially since it was introduced in the BizTalk product line in BizTalk Server 2004. Few know that research company Gartner, Inc. actually coined the term “Business Activity Monitoring” in 2001 to describe “a style of monitoring application that provides near real-time access to business performance indicators, with the goal to improve the speed and effectiveness of business operations. A valuable characteristic of a BAM application is its ability to reveal current business conditions, correlations and causality by using events from multiple and unassociated environments.”

While 2001 wasn’t too long ago, in the IT world, it was another era. The architecture of BAM implementations has evolved a great deal since then to include four successive “generations.”

First-generation BAM (1G BAM) may be considered, as defined by Gartner, as “a monitoring application that delivers real-time information, but its scope is limited to the context of a business application where it is embedded.” As an example, think of a Windows Forms application that monitors an assembly line. The application may control the different conveyor belts or machinery on the assembly line and also provide some operational status as to how the different activities, from one end point of the assembly line to the next, progress. Figure 15-1 illustrates this generation of BAM.

The advantages of 1G BAM are that the implementation time is short and the data is readily available. The disadvantages are that it fails to extend monitoring capabilities beyond a single system, and therefore has a largely static data model contoured around the entities of the single system. There is little or no correlation to other systems or data sources, and data rules are often hard-coded.

Second-generation BAM (2G BAM), as defined by Gartner, introduces middleware and messaging, and is more “stand-alone BAM” (see Figure 15-2). Using publish-subscribe patterns, application adapters, capturing agents, log files, and other techniques, 2G BAM connects to external systems and multiple event sources, and is extensible. 2G BAM also provides the ability to transform, normalize, and standardize events so that they may be monitored. The defining mark between 1G and 2G BAM is that with 2G+, new event types, new metrics, and new custom events may be defined within the system. 2G BAM also provides the ability to monitor a process without first modeling it.

Figure 15-1. First-generation BAM

Figure 15-2. Second-generation BAM

The advantages of 2G BAM are that most 2G BAM products align closely with the BPM tool or suite with which they are deployed. Within the BizTalk realm, before 2006, BAM and BizTalk were very closely intertwined because of BAM’s ability to only monitor BizTalk orchestrations. The disadvantages of such systems are that there tends to be a high latency involved in processing through BPM suites and applications, and that middleware tends to introduce other problems for which additional code must be written. 2G BAM is where most BAM implementations reside today, closely aligned with a product, and typically used to monitor a handful of applications or integrated systems.

Third-generation BAM (3G BAM), as defined by Gartner, “leverages the expandable data model characteristics of second-generation BAM applications, but integrates BAM within an application, a proprietary application development environment, or within a BPM Suite.”

Think of 3G BAM as “embedded BAM,” that is, applications monitored by a stand-alone BAM product are architected specifically to be plugged into a BAM or BPM suite instead of using adapters (see Figure 15-3). Alerts, rules, and events are exposed by 3G BAM–monitored systems in a standardized way without providing middleware (such as web services, WCF services, or on- and off-ramps) to standardize interfacing. Much like 1G BAM, 3G BAM usually involves purchasing a vendor’s entire product suite as the emitters put forth by the individual applications or systems tend to work best when coupled with the BAM product offering put out by the same company.

Figure 15-3. Third-generation BAM

The advantage of 3G BAM, much like 1G BAM, is that because the applications are aligned with a standard design methodology and toolset in place instead of being “best of breed,” there tends to be less time for implementation and more familiarity. Likewise, this too may be a disadvantage as competitive tools may provide better offerings, but sometimes, IT may be forced to purchase the entire suite.

Fourth-generation BAM (4G BAM), according to Gartner, has yet to hit the marketplace. Gartner defines 4G BAM as “a vision of what could be, but is not available in 2008. Here, the BAM application is built to exploit the power of a service-oriented architecture, using external services to deliver its functions. It uses composite application development techniques, calling on data services to subscribe to events, an event processing engine to detect patterns, a rule engine to analyze changing metrics, an alerting service to handle the delivery of alerts, BI services to provide historic and predictive analysis and a portal to display the environment. The objective is to use best-of-breed services, connected together across an enterprise service bus, or Web-oriented architecture techniques such as Simple Object Access Protocol (SOAP) and representative state transfer (REST).” The diagram in Figure 15-4 depicts 4G BAM.

Portions of this vision of BAM have largely been realized with the integration of WCF and WF as means to monitor an SOA in BizTalk. BAM and BizTalk together utilize a rules engine for changing metrics (the BRE), provide alerting, and connect to composite applications using a WCF service façade. BAM in BizTalk Server 2009 may even be used to monitor SOAP and REST-based architectures (Microsoft, in January 2009, released a white paper on doing just that). Gaps between Gartner’s 4G BAM vision and the Microsoft BAM of BizTalk Server 2009 exist in the areas of BI services, predictive analysis, and the tight-coupling of BAM and BizTalk.

Figure 15-4. Fourth-generation BAM

With regard to BI services, Microsoft announced that it would discontinue its Performance-Point product, and roll the underlying business intelligence capabilities into a series of “services” to be bundled with the next version of SharePoint Server. It is not known, however, whether these BI services will offer a standardized API that provides a means to roll up into a centralized portal to display both BAM and BI information side by side.

With regard to predictive analysis, Microsoft has remained quiet on the front of predictive analysis tools, but with the industry largely moving in that direction (see “BAM to the Future” later in this chapter), this arena clearly cannot be ignored.

With regard to the tight-coupling of BizTalk and BAM, historically, BAM has “ridden the coattails” of BizTalk’s BPM capabilities in order to become a more widely recognized product. While this has worked to promote knowledge of BAM, it has also hindered its adoption to some degree. The perception widely exists that in order to implement BAM, you must have BizTalk. In fact, the licensing model promoted by Microsoft requires at least one licensed BizTalk server to be in place in a network for the BAM license to be valid.

In order for Microsoft BAM to fully reach this vision, in the future, it may have to be decoupled from BizTalk altogether, perhaps as part of a larger strategy toward moving beyond the firewall (e.g., BAM reaching out to the cloud, etc.). In order to provide a more effective, more comprehensive intelligence strategy, BAM should become one pillar of many in an organization’s operational intelligence strategy.

BAM Branches Out

BAM is but one component of a comprehensive operational intelligence strategy. In fact, in order to provide a truer, more accurate, complete, and transparent process monitoring and intelligence strategy, the strategies of multiple technologies, such as BAM, BPM, BI, reporting, and so forth, must be closely aligned.

When we have been part of or have read about successful BAM implementations, they have oftentimes been part of a comprehensive strategy that delineates the multiple technologies, but also provides a means to monitor the process as it flows through them.

Operational intelligence architectures that provide for the most comprehensive technique for accurate process monitoring

• Monitor an individual process instance.
• Monitor all active process instances.
• Examine processes that have occurred historically.
• Correlate monitored external events.

Those processes that have been modeled and well understood by operational users and are monitored at an individual, peer, historical, and external level are those that provide the most useful operational intelligence.

Individual processes, such as workflow, are oftentimes best monitored by using BPM tools. For instance, as a workflow kicks off within a WF application, BizTalk and BAM may use the WF adapter to determine whether the process is succeeding or failing.

Peer processes are often best monitored in the same way. Where it is useful to monitor an individual process, such as an order being submitted to a WF application, for specific metrics such as whether it was processed or rejected, it is equally useful to monitor multiple order submissions to determine patterns and alert business users as to trends that may be emerging in real time.

Over time, as the total amount of data that has been amassed in either the BAM analysis database or a BI cube has grown, tools such as the BAM pivot table or PerformancePoint Server are best used to examine historical trends and apply “smart patterns” in an offline fashion.

While BAM is great for monitoring WF applications, additional patterns may emerge as messages flow through line-of-business applications and BizTalk. Correlation of the various data into usable information should be your ultimate goal.

BAM to the Future

Microsoft BAM is a relatively mature technology, but one that has yet to witness widespread adoption. Changes to the modern software ecosystem, however, in conjunction with enhancements to BAM’s underlying technologies, will serve to make BAM a great deal more commonplace.

A recent white paper examined the frustration of users in finding the information they need to do their jobs. This frustration was highlighted in a 2007 Accenture survey of 1,000 middle managers that showed managers spend up to two hours a day looking for information and that more than 50% of the information they find has no value to them.

The hypothesis of the white paper was that many users have problems finding information because the data discovery and analysis tools provided by vendors often assume, incorrectly, that the user has a detailed working knowledge of the business data involved, knows where to find it, and is able to use fairly sophisticated software tools for finding and using the business data they require.

Today we have access to more information than ever before, and while advantageous, it is also problematic: so much of that information is raw data and so little of it is useful information. Not only that, the boundaries of where data is stored and processed are quickly blurring with technologies such as cloud computing and Software as a Service (SaaS).

Additionally, disruptive technologies such as event-driven architecture (EDA) and complex event processing (CEP) are providing “smarter,” more predictive intelligence at a faster rate than ever before.

BizTalk and BAM in the Software + Services World

Software + Services is Microsoft’s mantra and approach to these five trends:

• Service-oriented architecture (SOA)
• Rich Internet Applications (RIAs)
• Software as a Service
• Web 2.0
• Cloud computing

The Software + Services vision was first fully detailed at the Microsoft PDC 2008 conference with the announcement of Windows Azure, the Microsoft data centers, and enhancements to a number of preexisting Microsoft technologies.

BizTalk is not part of the Software + Services cloud, but may interact with applications and operating services via service invocation. It’s very likely that the next version of BizTalk will include extensive integration with .NET Services, Live Services and SQL Services on the Azure services platform via BizTalk adapters.

Although there is currently no cloud offering for Business Activity Monitoring, the question may be posed as to whether or not BAM will interface with cloud components to monitor services and workflows executing in the cloud.

The .NET Framework 4.0, which includes extensive enhancements to WCF and WF, has been structured much like a 3G BAM system, with specific tracking mechanisms built into it rather than adjoining it. As these technologies along with Windows Azure and the Microsoft cloud APIs mature, expect to see BAM and tracking capabilities within the cloud. It is also a criticism of the cloud as a hosting platform.

As one executive relayed, “I want to move some of my applications to the cloud, but I’m hesitant. While hosting costs may be lower and the premise of infinite scalability is very nice, with [operational intelligence] tools, I can tell who has dropped the ball, or discern data patterns and refine. Once that moves into the cloud, I have no visibility and no control.”

BizTalk, BAM, and Complex Event Processing

Event-driven architecture is a software architecture pattern focused upon promoting the production, detection, consumption of, and reaction to events. Where the fundamental construct of BAM is the activity, in an EDA, it is the event.

An event is oftentimes thought of simply as a change in state. The scope of that change can be major or minor and may roll into a larger series of events or activities. Events have a header, which includes metadata about the event, and a body, which describes the actual event that occurred.

Event-driven systems, usually implemented within distributed architectures, typically consist of event emitters (or agents) and event consumers (or sinks).

It is the role of the emitter to generate data from various sources. Sinks then have the responsibility of acting upon that event as soon as it is presented. That action may be acted upon by the sink or routed to another mechanism to be acted upon. Sinks could potentially simply filter, transform, and forward the event to another component. Conversely, the sink may perform a series of internal actions and then route on to another component.

Sinks fall into two categories: traditional components, such as message-oriented middle-ware, to distribute an application across multiple heterogeneous platforms, and self-contained online actions, which require a more appropriate transactional executive framework.

Event-driven architectures, because of the nature of their design, tend to be more agile and responsive to unpredictable and asynchronous environments. Additionally, event-driven architectures fit well within or are complementary to service-oriented architectures because services within an SOA can be activated by triggers fired on incoming events. Whenever the sink is a more traditional component, the integration point within an SOA is increased because fewer dependencies exist that need to be accounted for.

Within event-driven architectures, events are processed by three means: simple, stream, and complex. The three styles are not mutually exclusive and are often used together in a mature event-driven architecture.

Simple event processing focuses upon events directly related to specific, exact, and measurable changes of condition. In the simple event-processing model, an event happens upstream that initiates downstream action(s). Simple event processing is oftentimes used to drive the real-time flow of work, reducing lag time and cost. Examples of simple events are usually in a one-to-one ratio, for example, a thermostat detects that it has become colder, and therefore turns on the heat.

In event stream processing (ESP), events that are considered both ordinary and notable happen. Ordinary events, such as an order submission, or an RFID transmission, are examined to determine whether they are considered notable and accordingly streamed to information subscribers. Event stream processing is oftentimes used to promote the real-time flow of information in and around the enterprise, which enables in-time decision making.

Complex event processing, then, is the combination of the two. CEP allows patterns of simple and ordinary events to be examined to infer that a complex event has occurred. Complex event processing, much like BAM, evaluates events and then takes action. CEP requires the employment of sophisticated event interpreters throughout the event chain, event pattern definition and matching, and correlation techniques (see Figure 15-5).

BizTalk infrastructures that generate events, by definition, are event-driven architectures. Emitters may be data feeds, network feeds, RFID feeds, ESB messages, custom applications that generate events, or packaged applications. Currently, the BizTalk Server WCF adapters provide the sink capabilities within BizTalk.

The difference between BizTalk BAM and CEP has to do with means by which queries are structured, the speed at which they are executed, and the flow of the data events through the system. In BAM, ad hoc queries or requests are created using the BAM portal to raise alerts. There may be a latency of even a couple seconds for complex activities, but at times, BAM alerts may take multiple days to fire because the BAM activity has yet to complete. Data within a BAM system typically flows at a rate of hundreds of events per second.

Figure 15-5. Complex event processing within an event-driven architecture

In a CEP system, queries are predefined instead of being ad hoc and may be aggregated. Latency in CEP systems is measured in milliseconds or less, and there tends to be tens or even hundreds of thousands of events that pass through the system per second, or even more.

CEP systems may be considered “smart” and utilize deductive logic. For example, a CEP system may observe that traffic speeds have slowed on a specific stretch of highway, more cars are exiting at off-ramps, fewer vehicles are travelling in one lane, and that beyond a specific mile marker, traffic speeds are increasing. CEP would infer that a complex event has occurred: an accident, by inferring events in analyzing and correlating the events as a whole.

There are many, many applications of CEP: credit card fraud detection, web analytics, stock trading, weather prediction, security monitoring, and others. New applications of CEP are emerging as technology vendors find new uses for the technology.

As of Tech*Ed 2009, Microsoft announced that it is indeed creating a CEP offering to be based on the SQL Server 2008 R2 platform. Tentatively named Project Orinoco, it is expected to be released by the end of 2009.

As far as how it will likely align with BAM and BizTalk, see Figure 15-6.

Figure 15-6. Microsoft CEP as an event processor for BizTalk and BAM

Summary

This final chapter focused upon best practices for BAM adoption, BAM’s architectural evolution through the years and how it maps to BizTalk Server 2009 BAM, BAM as part of a comprehensive operational intelligence strategy, and where BAM may be heading in the future.

IT has become more commoditized, and the bar has been raised for developers to become architects, demonstrating technical, leadership, and business superiority in their day-to-day function. Architects are also being asked to do a great deal more with a great deal less: fewer resources, less funding, tighter deadlines, and much higher quality standards. As such, it’s increasingly important to utilize the data around you to make as many informed decisions as possible using powerful technologies such as BAM. It’s our hope that this book will help you to achieve that goal.