Balancing Repeatability and Situationality with Process Mashups

At the center of the perfect storm of Service-Oriented Architecture (SOA), Web-Oriented Architecture (WOA), and the business-centric take on Web 2.0 we call Enterprise 2.0 is the notion of the enterprise mashup. Loosely defined as governed, managed compositions of Services in the context of a rich, Internet-based user interface environment, enterprise mashups have become a key driver for SOA initiatives, even though such applications as yet have relatively limited use in the enterprise.

In fact, mashups’ greatest strength is precisely what limits their applicability: using a mashup includes creating the mashup. In other words, putting mashup capabilities into the hands of a business user means empowering that user to create the application as they use it. Sounds good, but how often does IT really want users of applications to be responsible for creating and modifying those applications as well?

Falling into this “to use it is to create it” category of application is a class of application we call situational applications. Situational applications are ad hoc applications that meet short-term needs of individuals or teams of people, useful for a particular situation but unlikely to provide value long-term. Many situational apps are essentially data mashups, where the user creates the application by mashing together information from various data sources to meet some particular business need.

This association of situational app with data mashup, however, shortchanges the full power of the enterprise mashup. Remember, the point to composing Services in the context of SOA is to support flexible business processes — but the business process a data mashup supports is essentially the process of mashing up data: a useful process, to be sure, but a limited example of the wide variety of business processes that the enterprise might like to automate. For such processes we might look to a “process mashup” instead of a data mashup. So, what are process mashups, why would you want them, and how would you implement them in the enterprise context?

Process Mashup: An Example
ZapThink has been discussing process mashups in our Licensed ZapThink Architect course for a while now. The example we use in the course centers on a call center application. Call centers, of course, are the perfect breeding ground for Service-Oriented Business Applications (SOBAs), which are compositions of Services that implement business processes, because of the “swivel-chair integration” problem. In a traditional call center, the call center representative (CSR) requires access to multiple systems to do their job, typically including mainframe green screens, client/server interfaces to customer relationship apps, Web interfaces to the corporate portal or Web site, as well as a specialized interface to their phone system. To meet the needs of a customer who calls in, the CSR must swivel back and forth between screens, a slow and error-prone approach that cries out for a better way.

SOA, of course, enables that better way. By abstracting the various applications as Services, the call center is now able to build a streamlined, flexible interface for the CSR that solves the problems with swivel chair integration. Implementing a customer service SOBA to support such an interface is a no-brainer, and many of today’s call centers have already implemented SOA for this purpose.

Implementing a SOBA, however, is only part of the story, because the CSR is only one player on this stage. If we run through the rest of the cast of characters, a more complex picture of this application emerges, as we show in the figure below.

Process Mashup in Action

The figure above illustrates how several people interact with the customer service SOBA in different ways, depending upon their roles:

• The executive (1) is interested in key performance indicators (KPIs) for the call center, namely call time (the lower the better) and customer satisfaction (the higher the better). As a result, she interacts with the SOBA via a management dashboard that provides simple visibility into these two KPIs. Based upon the information she sees there, she makes policy decisions, and communicates those to the call center manager.
• The call center manager (2), in turn, is responsible for the business processes that the call center runs. In other words, he is responsible for the scripts the CSRs follow, and how the SOBA supports the processes those scripts delineate. He’s also looking at the KPI dashboard, as well as a read-only view into the process flows the SOBA implements. Based upon his boss’s policies, he makes adjustments to the call center’s processes, and communicates those changes to the business analyst.
• The business analyst (3) is the only person in this example with the ability to make changes to the behavior of the SOBA. In other words, this person is the only person in the call center with a mashup interface. Based upon the instructions from her manager, she makes changes to the behavior of the SOBA directly in the SOBA’s mashup interface.
• The CSR (4) is perhaps the most sophisticated user of this app, as she requires the full capabilities of the SOBA to meet customer needs as she runs through the various call center scripts. She’s clearly not supposed to change the functionality of the app, however.
• Last, but definitely not least, the customers interact with the SOBA as well, either because it supports the corporate Web site (5) or indirectly via phone when they call into the call center (6). Customers have limited read/write capabilities on the Web site, but also cannot change the behavior of the application, beyond perhaps some simple personalization capabilities.

Business Empowerment in Action
This example teaches many lessons on what it means to be an enterprise mashup, as well as the nature of process mashups. First, governance plays a critical part of the story, as the organization has policies as to what capabilities different individuals have. Business empowerment, in fact, requires governance, as there’s no way IT would provide increasingly powerful tools to the business unless there were a flexible way to manage the use of those tools.

Secondly, the business analyst role as the person with the mashup interface is a specialized, limited role. Only a relatively small number of people in the organization would ever have mashup interfaces, and even then, they would only be able to make certain changes via those interfaces. And while this example places the business analyst on the call center team, in reality this role may be an IT role, especially if the mashup tooling is highly technical. Ideally, mashups are for the business-centric knowledge worker, but that level of usability depends upon the tools.

Thirdly, it’s important to note that this application is a process mashup rather than a data mashup, since the purpose of the app is to support the call center processes. While technically the actions the business analyst takes to modify the app constitute a process in their own right, that process isn’t the point of the app, the way it is with a data mashup. In other words, this SOBA is less situational than a typical data mashup, where the mashing-up process may be different every time the users interact with the tool.

Situationality, therefore, is not always a priority with mashups, as situationality is less important than repeatability for most automated processes. After all, the reason you’d want to automate a business process in the first place is because you expect to run the process many times, otherwise automation would never be cost-effective. Situationality and repeatability, however, are two ends of a spectrum; the interesting processes from our standpoint are the ones that fall in the middle somewhere. Such processes have a level of variability that requires a measure of situationality to the applications that implement them, while being sufficiently repeatable to warrant automation. It is such processes that process mashups (and SOA in general, for that matter) are particularly well suited for.

The ZapThink Take
The tooling and infrastructure organizations require to support data mashups vs. process mashups will vary, and therefore, making a clear distinction between the two makes sense from a technical viewpoint. This distinction, however, may be lost on a business audience. After all, from the business perspective, processes always involve information, and there’s no way to get value out of information without doing something with it, and when the business does something, that activity constitutes a business process. For the business user, the empowerment story is far more meaningful than the distinction between data and process.

Be they data mashups or process mashups, therefore, the enterprise mashup story is worthy of its position at the center of the perfect storm, only now that storm is at the intersection of business empowerment, business agility, and business process. It may be difficult for the IT organization to keep its head above the water with the technical details, but getting a handle on the full power and diversity of enterprise mashups is becoming an increasingly important part of understanding how IT can deliver business value in the SOA-enabled Enterprise 2.0 world.