sandy

TIBCO Analyst Summit: Spotfire

Christopher Ahlberg, founder of Spotfire and now president of TIBCO’s Spotfire division, discussed Spotfire’s capabilities and what’s been done with integrating Spotfire into other TIBCO products.

Timely insights — the right information at the right time — is a competitive differentiator for most businesses, and classic business intelligence just doesn’t cut it in many cases. Consumer applications like Google Finance are raising the bar for dynamic visualization techniques, although most of them are fairly inflexible when it comes to viewing or comparing specific data in which you’re interested. In other words, we want the data selection and aggregation capabilities of our enterprise systems, and the visualization capabilities of consumer web applications. Ahlberg sees a number of disruptive BI technologies transforming the platform — in-memory processes, interactive visualization, participatory architecture, mashups — and starting to be able to link to the event-driven world of classic TIBCO.

He did a demo of copying and pasting the contents of a spreadsheet directly into Spotfire, which automatically used the column headers as metadata and created a scatterplot. He filtered and colored the chart dynamically, set thresholds and played around with the data to show what could be extracted from it, then showed a pre-built dashboard of charts that still allowed quite a bit of interactivity in terms of filtering and other view parameters. He also showed a mashup between Spotfire and Microsoft Virtual Earth that allowed a subset of the data to be selected in Spotfire, causing a shortest route between the geographic location corresponding to the data points to be plotted on Virtual Earth.

This puts a much more configurable face on standard analytics, not just in display parameters but also in area like selecting the dimensions to be compared on the fly rather than having them pre-defined in OLAP cubes. Since TIBCO is focused on real-time event processing, the logical step is to see how those events can be visualized in Spotfire: instead of just raising an alert to someone, give them a view of the analytical context behind the alert that makes it easier to close the loop on problem resolution. They’ve packaged this as Spotfire Operations Analytics, which fits most closely into a LEAN Six Sigma manufacturing environment.

There’s a session on Thursday about BPM with analytics which I’ll likely attend to see what they’re doing in that area.

TIBCO Analyst Summit: Go To Market Strategy

Ram Menon, EVP of Marketing and Product Strategy, discussed the go to market strategy for some of the opportunities that Murray Rode identified earlier.

One opportunity for growth is in simplification, in four major areas:

Improved focus on who they are targeting in the sales process, based on their experience of who is most likely to buy and through deepening their penetration within existing customers.
Creation of horizontal bundles that simplify purchasing for IT buyers: SOA starter edition, SOA composite apps, SOA integration, and SOA governance.
Focus on differentiated vertical value propositions that allow a business buyer to match TIBCO’s capabilities to their specific business needs.
Improved user interface and usability in the form of TIBCO ONE for deployment and management, all based on a common Eclipse framework and some of the technology that they acquired with General Interface.

They have a three core SOA messages to the market:

Best in class ESB
SOA service management
Extreme messaging, namely top performance

They also have some BPM-related themes:

Advanced order fulfillment (vertical)
Dynamic claims management (vertical)
Unify BPM and SOA: cross-selling BPM to existing SOA customers

There were two business optimization themes, including a supply chain management vertical, but that went by too fast for me.

Bruce Silver and another analyst later asked about the vertical solutions, and it appears that this is more about marketing and advertising than any verticalization of a product or service offering.

Menon discussed some of the specifics of their expansion into new geographies — including up-to-date localized product materials and websites — and new partner models.

They’ve made a big push for visibility in the market over the last two years, including such efforts as Greg the Architect videos on YouTube, resulting in a much greater chance of TIBCO’s name appearing whenever equivalent IBM and Oracle products are mentioned. They’re also launching TIBCOmmunity, a social network for their customers, although the site’s not up yet so there’s no details on what it will include.

He was followed by two of the VPs of Sales — Robin Gilthorpe for the Americas and Tony Harris for Asia-Pacific — and EVP of Sales Murat Sonmez standing in for the VP for EMEA, each discussing the specifics of their region.

A question came up at the end asking about who they’re selling to within organizations, and (not surprisingly) almost all SOA sales are to IT, whereas BPM is sometimes being sold to business management. TIBCO has a legacy of selling to IT, and I suspect that much of the sales force is most comfortable making the technical sale. Selling to business takes a slightly different set of skills, which makes me curious if they’re specifically recruiting business-oriented salespeople in their current sales force expansion.

TIBCO Analyst Summit: Corporate Vision

Next up was Vivek Ranadivé, CEO, with a summary of where the company came from and some vision for the future: Enterprise 3.0 (yes, he actually said that), focused on event-driven SOA, predictive analytics and the business processes that use them.

He sees their superior technology as key, but feel that customers also gravitate to them because of their neutrality: a direct dig at IBM — who he believes is both not neutral and has inferior point-to-point event technology — and at BEA being acquired by Oracle (although rumors continue to fly in the industry about who is going to acquire TIBCO, and when).

Although this session was billed as "strategy and vision to remain a leader in the current market of consolidation and competitive pressures", I didn’t hear a lot about how they plan to do that, except for a "we’ll sell more because we’re better" sort of statement.

TIBCO Analyst Summit: Corporate and Financial Overview

TIBCO’s having their first ever analyst summit in the day before the TUCON user conference starts, covering both business strategy and product announcements.

First up was Murray Rode, CFO, with a company overview and their position in the market. Their key market segments are SOA and BPM, as we know, but also business optimization (rules + analytics) based in part on the acquisition of Spotfire a year ago. They see their differentiators as their neutral platform, mission critical engineering and being event-driven and bus-based. They also see "infrastructure becoming the essential part of the architecture" and that companies are using TIBCO to "create apps from infrastructure". A key catchphrase summing up what their products can do is "simpler connectivity, more complete automation".

Their fiscal year 2007 revenue was $577M, I was surprised to hear that 50-55% of their revenue is from services, which includes both maintenance and professional services, in spite of a strong partner channel that presumably is also generated significant professional services revenue based on TIBCO products. Geographically, about 50% of the revenue is from the Americas, 40% EMEA and 10% Asia-Pacific. Financial services is their largest vertical at 25%, with telecommunications at 10-15%. They’re continuing to expand their sales force from the current 170 to 190-200, with each quota-carrying salesperson generating about $2.2M in licence revenue annually, and in addition to growing the sales force, they intend to continue expanding through new geography exploration, acquisitions and partner channels.

BPM is 11% of revenue, business optimization is 25%, and the remainder is SOA, although it’s difficult to separate out in many of the larger deals that may be driven by BPM without the licence revenue necessarily reflecting the importance.

Their growth strategy, in summary, is to build on pure-play leadership and neutrality, direct sales force expansion for broader coverage, fully penetrate Global 2000 before expanding to mid-market, continue Spotfire focus with increased cross-selling, and new geographies and indirect channels.

links for 2008-04-24

SlideShare » List (share powerpoint presentations online, slideshows, slide shows, download presentations, widgets, MySpace codes)

Presentations from this week’s Architecture & Process conference, although unfortunately not all are downloadable.

(tags: ea bpm)

Architecture & Process: Doug Reynolds

Doug Reynolds of AgilityPlus Solutions presented on critical success factors in a BPM implementation. I’ve known Doug a long time — back in 2000 when he was at Meta Software and I was at FileNet — and have had a lot of discussions with him over the years about the BPM implementations that we’ve seen, both the successes and the failures.

He talked about how BPM is similar to other performance improvement initiatives, but that there’s some key differences, too. Any successful BPM project has several facets: solution, project management and change management. Breaking the solution component down further, it includes people, process and technology. He feels that process is the place to start with any solution, since people and technology will need to meet the needs of the process.

In order to talk about success factors, it’s important to look at why projects fail. With IT projects, we have a lot of failures to choose from for examination, since various analyst sources report failure levels of up to 70% in IT projects. In many cases, projects fail because of poor requirements or ill-defined scope; in BPM projects, the business process analysis drives the requirements, which in turn drive the solution, highlighting the critical nature of business process analysis.

He highlighted eight signs of a healthy BPM implementation, using the word semiotic as a mnemonic:

Stability. The system must be stable so that the business is able to rely on its availability.
Exploitation. You need to exploit the technology — put it to work and continually improve your usage of it — in order to get the benefit. Buying a system that was very successful for someone else doesn’t automatically confer their level of success onto you.
Management and leadership. You need executive sponsorship with vision and direction, but also have to consider the impact on middle management, who are heavily affected by changing processes in terms of how they manage their workforce.
Inertia. You need to actively change the way people work, or they’ll keep doing things the old way with the new system.
Ownership. Ownership of the solution needs to stay with the business, not transfer to IT, in order to have the focus stay on benefit rather than capability.
Transparency. Some aspects of work may appear to be less transparent — e.g., you can’t tell how much work there is to do by walking around and looking at the piles of paper — but the metrics gathered by a BPMS actually provide much more information than manual methods. This “Big Brother” view of individual performance can be threatening to some people, and their perceptions may need to be managed.
Integration. Integration with other systems can be a huge contributor to the benefits by facilitating automation and decoupling process from data and functional services. However, this can be too complex and cause project delays if too much integration is attempted at once. I completely agree with this, and usually advocate getting something simpler in production sooner, then adding in the integration bits as you go along.
Change management. Change management is key to bringing people, process and technology together successfully, and needs to be active throughout a project, not as a last-minute task just before deployment.

Doug encouraged interaction throughout the presentation by asking us to identify which two of these eight are the most foundational, and eventually identified his two foundational picks as exploitation and inertia: using the system the best way possible, and ensuring that change happens, are two things that he often sees missing in less-than-successful implementations, and are required before the rest of the things can occur.

Architecture & Process: Jaakko Riihinen

Jaakko Riihinen, head of enterprise architecture for Nokia Siemens Networks, spoke about business process architecture: a deep dive into the details of one set of models that they use in their EA efforts. He started with definitions of architecture, process and abstract modeling, reinforcing that a presentation view of a model is just a view, not the entire model. In his definition of architecture, I especially like the analogy that he made of architecture being the external energy that keeps systems within an organization from evolving into chaos. In general, architectures tend to satisfy nonfunctional requirements, such as optimization of system economics.

One of the issues in modeling processes is the different types of models that may be used in different departments, and the ultimate goal is to have a set of process models for the entire organization rather than having them be constructed piecemeal. He characterizes processes in three types: transactional, creative (team collaboration on work product), and community (dynamic, self-organizing); the modeling method that is the focus of this presentation addresses transactional processes.

He shows three elements of their process architecture:

A process integration model, showing the high-level view of how processes and work products interact. This is the functional design of the process architecture.
A process behavior model, which is a standard swimlane process model that shows the detailed view of one of the process nodes from the process integration model. It’s different from BPMN in that the work products are shown within the sequence flow rather than attached as artifacts since they are focused on linking the activities closely to what triggers them and what they produce.
Work instructions for performing one activity in a process.

Other characteristics of a process are also modeled:

Process instantiations, which can be scheduled or event-driven; where event-driven can be based on work product (e.g., inbound document) or an explicit event (e.g., timeout).
Execution constraints, either a free-running schedule (activities execute as soon as inputs are available) or an imposed schedule (e.g., periodic reporting)

The process integration model shows the instantiation methods for each process, as well as showing how multiple processes can provide input to another process in a variety of ways, including both informational and triggering.

All of this provides the notational background to discuss the real issue: normalization of process models and process architecture, using methods derived from classic systems methodologies such as control system theory and critical path analysis. The benefits of normalization include unambiguous definitions that are easier to understand, and better recognition and reuse of process patterns, but the real benefit is that this turns process architecture from an art to a science. There are four basic rules for process architecture normalization:

Structural integrity: closing alternative paths within parallel paths, and closing parallel paths within alternative paths (these are basic topology constraints from graph theory, and would be enforced by most process modeling tools anyway)
Functional cohesion: no disconnected activities
Temporal cohesion: no synchronous processing by activities outside the process (which implies that you would not use the BPMN method of separate pools for separate organizations since messaging between pools would not be allowed, but would consider that separate organization’s activities to be part of the process if your internal process needs to wait for a response from the other organization before continuing the process)
Modularity: activities or roles having different cardinalities belong to separate processes (this helps to determine the boundaries between processes, e.g., sets of activities that pertain to the entire company are usually in separate processes from those for individual business units), variance at the process level (when alternative paths in a process become sufficiently complex or encompass most of the process, create two variants of the process), variance at the integration model level, deployment details, process components (subprocesses shared between processes)

Determining the boundaries of a single process may involve combining what are considered to be separate processes into one: we discussed the example of employee onboarding, which involves several departments but is really a single process. Looking at the triggers for activities and processes also helps to determine the boundaries: activities that asynchronously create work products that are consumed by other activities are usually in a separate process, for example, as are activities that are performed on different schedules.

They’re using ARIS, and have configured their own metamodel for the process integration model and behavior model. Riihinen is also interested in developing automated methods for normalizing process models.

His slides are incredibly dense with information, and fascinating, so I suggest that you check them out for more details on all of this. In particular, check out the slides that show examples of the four process normalization rules.

As you can tell by the above URL, the conference is using Slideshare to publish (but not allow downloads of) all presentations here.

Architecture & Process: Robert Pillar

The first breakout session of the day was on connecting BPM, SOA and EA for enterprise transformation, with Robert Pillar of Microsoft. He’s talking about how compliance is the key driver to the coalition of BPM, SOA and EA, but that the coalition starts with holistic collaboration. There are barriers to this:

Organizational barriers: IT organizations and silos between EA, SOA and BPM groups
Cultural barriers: lack of understanding the business value, lack of understanding the concepts, and old-style mentality
Political barriers: resistance to change
Collaboration barriers: resistance to meetings and collaboration

Risks and benefits must be measured.

At this point, someone in the audience spoke up and said “we understand all this, can you just skip ahead to any solutions to these issues that you have to present?” Incredibly rude, and really put the speaker on the spot, but he had a point.

He had a summary slide on why to choose SOA:

It offers a focus on business processes and goals: supports customer centric view of the business, allows design of solutions that keep requirement changes (agility) in mind
It offers an iterative and incremental approach following EA and BPM initiatives: make change happen over time, allow employees learn about the concept of services
It offers a means to reap the benefits of existing investments on technology: reuse IT resources, focus on business problems without being entangled in the technology

He sees EA and BPM as leading us to SOA, which is a valid point: if you do EA and BPM, you’ll definitely start to do SOA. However, I see many organizations starting with SOA in the absence of either EA or BPM.

Architecture & Process keynote: Tom Koulopoulos

The afternoon keynote was by Tom Koulopoulos, the well-known and well-respected consultant who founded Delphi Group and is currently also at Babson College’s think tank on business innovation. He’s worked extensively in the business process/knowledge management space, so I’ve tracked his excellent work and writings for years. He spoke to us today about innovation.

Innovation is change that creates value.

Innovation and invention are separate concepts. We’re surrounded by invention, and we have a hard time picking out innovation from the noise created by the relentless invention of (often useless) gadgets. Is this invention for the sake of invention, as Koulopoulos says, or is this the necessary process for eventually refining out a few good ideas?

Innovation is the collaboration between an idea and the marketplace. The market will not be able to predict the effect of true innovation, since there’s no context for understanding that: consider that the most extreme, ambitious prediction for the world market for mobile phones was 50 million handsets, a number that’s off by two orders of magnitude today.

Innovation really happens when behaviors start to change. It’s a process, it’s not about an invention. It’s an ecosystem where good ideas are captured, inventoried and reused to help them come to fruition. Today, many of the innovations are in business models, not the product or service.

Koulopoulos had seven lessons of innovation:

It’s about the process, not the product.
Build an innovation competency. You have to build a competency in innovation within your organization in order to encourage, support and reward it. Many organizations institutionalize the idea of being the incumbent rather than look for ways to find innovation, putting up both cultural and logistical barriers.
Separate the seeds from the weeds. You need to allow some ideas to grow in order to see which they are and allow for disruption to occur, but at some point you need to be able to tell the difference.
Fail fast. Some portion of your time needs to be spent on activities where there is no expectation of success, since it gives you the breathing room for serendipitous innovation.
Build for the unknown. Sometimes an innovation intended for one application becomes a success for something completely different, but sometimes it’s just a complete leap of faith to build something for an environment that’s impossible to assess until you get there.
Challenge the conventional. New companies, or those moving into a new field, are often more innovative than those who are existing experts in the field. Hoover couldn’t have invented the Roomba.
Abandon success. If you’re in a position of strength, take a risk and do something completely different that hasn’t been done before.

He told how his son uses the interactive toy builder on lego.com, collaboratively creating toys online with other site visitors, and how there has been a fundamental shift from wanting to protect our ideas to wanting to share our ideas. Not just with today’s kids, either: science methodology, as indicated by trends in Nobel prize winners over the past century, is shifting from individual effort to team effort.

He closed with a quote from Morpheus in The Matrix: “I didn’t say it would be easy Neo. I just said it would be the truth.” So it is with innovation.