ZapThink </>
Balancing Repeatability and Situationality with Process Mashups
Document ID: ZAPFLASH-20081215 | Document Type: ZapFlash
/By: Jason Bloomberg/
Posted: Dec. 15, 2008
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
<http://www.zapthink.com/report.html?id=ZAPFLASH-2006320>. 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
<http://www.zapthink.com/report.html?id=ZAPFLASH-2008212> 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
<http://en.wikipedia.org/wiki/Situational_application>. 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
<http://www.zapthink.com/report.html?id=ZAPFLASH-20081107>, 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 <http://www.zapthink.com/lza.html> 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.
