Why SaaS rocks

I hear a lot of opposition to software as a service from customers, ranging from an unformed mistrust of anything that crosses the firewall, to the feeling that anything that runs in a browser must be a toy, to a full-blown (and justified) concern of non-American companies about having their data stored on US-based servers where it is presumably accessible to US government agencies on demand. Keeping in mind that many of them are large, fairly conservative financial services organizations, I obviously have a long way to go in terms of convincing them otherwise, yet I still try.

Going back to Tim O’Reilly’s original treatise on Web 2.0, SaaS is baked right into the definition in two important ways:

  • the web as platform
  • the end of the software release cycle

The first of these is likely what sells most people originally: the idea that nothing needs to be installed at your own site, and all you need to do is pay $x per month per user (where x is about the cost of a couple of cappuccini at Starbucks) to have access to a fully-functional application. Think that this is only for small businesses? Salesforce.com announced yesterday that Dell is increasing their number of Salesforce.com subscriptions from 15,000 to 40,000 users. There’s all sorts of good reasons why to do this — lower TCO, small ongoing expense versus a large capital expenditure, no need to bring a new servers and applications into your data centre — but the somewhat unspoken reason is that it’s a way for the business to escape the tyranny of IT when it comes to purchasing applications. I’ve seen many cases of a smallish business unit within a large organization wanting to bring in new technology (BPM, BPA and BI are all ones that I’ve seen in this scenario), but IT adds on an unduly large burden of corporate standards and application vetting that kills the ROI, and the business goes back to their paper and spreadsheets. I’m not saying that IT shouldn’t be involved in these decisions, but when their time spent reviewing and “architecting” a packaged solution costs as much as the external costs, something’s wrong. If the business can get equivalent functionality from a SaaS offering with much less IT involvement and a small monthly bill rather than a large up-front capital expenditure, that’s going to look much more attractive.

The second driver for SaaS from O’Reilly’s definition is where the benefits will really accrue in the future, although that’s likely unrecognized by many people. The idea that you don’t have massive software releases that take the system down for hours or days, but that new features are gradually introduced with little or no fanfare, means that there’s much less disruption to the users, and that they’ll be pleasantly surprised by new functionality. I had exactly this experience of pleasant surprise this morning, when I noticed that Google Reader, which I’ve been using for a couple of months now, has gone from listing the number of unread items as “100+” to the actual number, a feature that I sorely missed from Bloglines since I almost always have more than 100 unread items and I really want to know how many more. They didn’t, to my knowledge, disrupt service in order to add this new functionality: it just appeared in my browser this morning (or maybe before, I’m not all that observant sometimes). I believe that there’s still the need for some major upgrades, such as a complete UI paradigm shift, but most of the enhancements to most business applications could be done incrementally and introduced as they’re ready, if the infrastructure is there to support it. That requires a browser-based application to avoid a download and install each time something changes, if not actually SaaS, but it also requires a new mindset for development teams about agile development and release: something that is much more prevalent in the SaaS vendors than in corporate IT groups.

If you read my post on Enterprise 2.0 updates recently, or the original Dion Hinchcliffe post that inspired it, it starts to become clear that Enterprise 2.0 will be dependent to some degree on SaaS, at least in the short term: many IT organizations are just not ready to start installing this new breed of application on their own servers, and the business groups will look outside to get their problems solved. This will lead to a further commoditization of IT, since once the business is using SaaS successfully, that genie’s not going back into the bottle.

Update: Google Reader also added search capabilities in this set of incremental upgrades, which I didn’t even notice (as enamoured as a I was with the accurate unread item count) until I read it on Mashable.

Summer’s over

My blogging has been very light for the past month: summer is short in Toronto, and we’ve had an amazing run of good weather in August, so I’ve barely kept up with my customer projects and have totally neglected blogging. Now that the days are getting noticeably shorter, the nights cooler and everyone with a real job seems to be back from vacation, I think that it’s time for me to get back to work.

I have several blog posts partially completed (James Taylor’s book review, a few product reviews, a couple of short articles) that really need to get done, and some preparation for the fall conference season:

  • September 17-19, I’ll be covering the Gartner BPM Summit in Orlando
  • September 25-26, I’m speaking at the Forrester IT Leadership Forum in Carlsbad
  • October 2, I’m most likely covering the Web 2.0 University session in New York
  • October 11, I’m back in New York to present at a TIBCO seminar
  • October 23-24, I’m speaking at the Business Rules Forum in Orlando

November doesn’t look much better: I think that there’s an OMG BPM/SOA workshop (I had a note in my calendar but can’t find any information on it, and no one has added it to the shared BPM events calendar), I’m speaking at the Shared Insights BPM conference in San Diego, then I’m off to Bangalore to speak at SOA India.

Email woes

Sometime after 7pm Eastern tonight, Google decided to do some maintenance on my kemsleydesign.com email account, which is hosted on Google. Some notice would have been nice, instead of getting errors through Outlook, then attempting to access the webmail to see a notice that Google Mail is unavailable for “up to” 24 hours.

24 hours?? I guess this is how they get us to move from the free Google mail accounts for our domains to the paid ones.

I’ve reconfigured to reroute my email elsewhere, but if you sent me something between 7-8:30pm Eastern, it may be sitting in a bit bucket at Google.

BPM Think Tank wiki

The wiki for the recent BPM Think Tank has been opened up for public viewing, and Derek Miers has pre-loaded it with links to some of the related documents as well as links to my coverage of the sessions.

If you attended, you should have received an editing password for the wiki, which allows you to add your own notes on any of the pages — please do, since it enriches the experience for all readers.

BPM Think Tank Day 3: Roundtable wrapup

Last BPM Think Tank post, I’ll summarize the notes on the roundtables that I didn’t attend, based on the 3-5 minute summary that each facilitator presented.

Rules and Process (Paul Vincent):

  • Defined types of rules
  • Handling business decisions within processes
  • How to separate and model rules from process at design time

BPM and Microsoft Technologies (Burley Kawasaki):

  • My commentary on the notes from this session: seemed to be an ad for Microsoft technologies rather than much to do with BPM. Not sure why the Think Tank agreed to hold such a vendor-specific roundtable.

ERP and BPM (Dave Frankel):

  • Goal to break down silos in ERP to enable BPM
  • Orchestration of reusable services is not sufficient for processes; need event-driven layered process delegation
  • Need a common data exchange model for ERP system, and an accepted scope for that common model

Goals of BPM Standards (Bruce Silver):

  • Standards reduce risk but never seem to quite get there in terms of portability of process models and interoperability
  • What’s required for portability? The following were suggested, although not everyone agrees on the last two:
    • Identical business meaning
    • Identical graphical view
    • Identical at execution point
  • How standards gets created: a small group of people who are passionate about it and have employers who pay their salary (and usually expenses) to get involved

Metrics:

  • Types of metrics: time, quality, cost, value
  • Measures tend to be lagging but would be more effective if they were leading/real-time

BPM in the Federal Government (George Thomas):

  • [I assume that this means the US Federal Government…]
  • Much of the BPM work is to operationalize activity-based costing, and requires integrated BI
  • Horizontal interoperability required across government departments
  • Need to institutionalize knowledge before the boomers retire
  • Problems with immaturity of current tools and standards
  • BPM is today’s version of a monolithic application, and needs to decouple model from execution
  • Struggles with ongoing legacy modernization

Competencies/Skills for BPM:

  • Mapping target population (business, IT, process experts that span business-IT) to organizational results; use this to create training program
  • Top management needs to believe in a process-centric organization: must understand how jobs are accomplished, how IT Is used to achieve goals, and enough knowledge to understand IT decisions
  • Line management must become metric-driven and knowledgeable about the processes in which they participate, and collaborate across functional silos
  • Performers must be expert at process execution and be workflow-savvy

BPM and Business Frameworks:

  • Like some other groups, spent half of their time defining BPM
  • Lots of noise in the industry about BPM and frameworks
  • Need to understand how to engage the business

BPM Think Tank Day 2: Roundtable wrapup

Here’s some assorted notes on all the other roundtables that I didn’t attend: each of the facilitators gave a 3-5 minute wrap up of their discussion. The notes from all of these sessions are supposed to end up on a wiki for the conference, so there should be more information around eventually as that fills in (unfortunately, the wiki seems to be closed to public viewing at this point, as well as being named after the creator’s company rather than the BPM Think Tank itself).

Barriers to process improvement (John Alden):

  • No acceptance of the need to change
  • Difficulty finding an executive sponsor
  • Resource constraints (time, people, money)
  • Community inaction

Business involvement in BPM (John Jeston):

  • Like many other groups, spend quite a bit of time defining BPM and associated terminology, e.g., “process owner”
  • Need to get CEO attention

Lean/Six Sigma in BPM (Lance Gibbs):

  • Not every project is or should be Lean/Six Sigma
  • Lean = waste removal, which is a good fit with BPM

Approaches to Effective Architecture (Bruce Douglas):

  • Definitions of architecture: layers of services; ecosystem
  • Complexity and effort required to model architecture
  • Differences between models and realization
  • What should be modelled
  • Lack of respect for architecture functions
  • Problems “between the seams” in architecture rather than with the pieces (artifacts)
  • Long-term strategic often displaced by short-term needs
  • Model and validate along the way to developing complete architecture

Innovation in BPM (Angel Diaz):

  • How to help customers innovate with BPM
  • How to start BPM projects
  • Centre of Excellence
  • How to measure innovation
  • The chasm between “define” and “do”: what doesn’t get done, and what’s not relevant once it’s done
  • Divide between BPM and SOA
  • Requires a person to span business and technology (like me 🙂 )
  • Requires personal leadership

BPM and BI (Colin Teubner):

  • Use cases for BPM and BI:
    • BI about a process
    • BI triggering/changing a process (including triggers from dashboards)
    • BI inside a process to automate decisions
    • BI in work environment to provide information to a person for their decision
    • predictive BI driving process work
  • BPRI will assist in some gap closing but thee’s little understanding of BI by BPM vendors

Model-driven Organizations (Fred Cummins):

  • Dramatic changes in business in recent years requires models in order to understand how business works
  • Need management buy-in
  • Cultural change to manage business with models
  • Models can expose embarrassing faults, which causes some resistance to models and to change
  • SOX requires taking responsibility, increases risk if business not understood: drives need for models for decision support

BPM and GRC (Dennis Davidson):

  • GRC = Governance, Risk Management and Compliance (a new acronym for me), an emerging market segment that is adopting BPM technology
  • Involves SOA and BPM
  • Needs BPM to make SOA successful
  • Collaboration technologies, including Web 2.0 and 3.0

BPM Think Tank Day 2: BPEL Roundtable

The second roundtable that I attended on last Tuesday’s sessions was on BPEL, headed up by Ismael Ghalimi. It was great to finally meet Ismael in person: we’ve been corresponding by email and blog comments for quite a while, and have even done a webinar together, but this is the first time that we’ve been in the same place at the same time.

We started with a discussion of BPEL4People, and how it’s changed from the original specification (which proposed implementing human-facing tasks as web services rather than changing BPEL) to the current specification (which proposes extensions to BPEL for human-facing tasks).

The title of the roundtable was “is BPEL relevant”, and we covered several aspects of that. First, a few people around the table (which included a few vendors with a vested interest in BPEL) stated that BPEL is relevant in the same way that SQL is relevant: as a standardized language that allows a separation of the design/development environment from the execution environment. Based on the lively discussion, some of these guys have spent a lot of time thinking about the BPEL-SQL analogy. My argument (I have no vested interest, so could have easily argued the opposite way) was that maybe it *should* be relevant in that way, but really isn’t in the consolidated model-design-execute environments that we see in BPM today. The real question may be, at what level is BPEL relevant: model, design, code or execution? Everyone agreed that it’s not relevant to business users or analysts, but it’s not clear where the line of relevance lies.

We also discussed how native BPEL execution providing code monitoring during execution, such that any code faults will have more semantic information included without having to build a monitoring stack on top of it. What remains to be seen is if BPEL4People will provide some level of business-relevant monitoring, or if that still has to be built on top of the execution layer.

What we’re seeing is that for the most part, it’s the larger vendors that are adopting BPEL — possibly as a common language to glue together all the BPM pieces that they’re acquiring — whereas the smaller vendors provided a consolidated (and therefore closed) suite environment where the execution language doesn’t matter, and in fact, their engine may be a competitive differentiator.

Can RSS replace trickle feeds for BI?

I was having a conversation late last week with a SaaS BI vendor about how organizations get data into their online data warehouse (ftp seems to be the most popular method), when it struck me: why couldn’t they use an RSS feed from a transactional system to feed data into the data warehouse for BI purposes (or Atom, for that matter)? Near-real-time data is essential for many types of BI analysis, so there has to be something better than once-daily uploads.

BPM Think Tank Day 2: BPMN/BPDM Roundtable

I’m just getting to the last of the BPM Think Tank sessions, namely, the roundtables and one lunch session that I had documented on paper. The three sessions of roundtables spanned Tuesday and Wednesday afternoons, and were some of the best conversations that I had at the conference. I’ll cover each of the ones that I attended in a separate post, then the summaries of the others in another post, just to keep things from getting too long. These were fairly unstructured, general sessions so the notes might be a bit fragmented

The first roundtable that I attended was BPMN and BPDM, with Stephen White of IBM and Antoine Lonjon of MEGA.

There are insufficient books and tools for educating the community on how to use BPMN for different purposes. There is a requirement for a reference document to educate end-user organizations that is smaller and more understandable than the specification (possibly both a business-oriented primer and a technical reference). Stephen stated that additional reference documents will be available within a few months. There is an HTML version of the specification online at ModelDriven.org.

Small consulting organizations and independents can’t realistically get involved in standards creation so we’re always “users” of the specification. I didn’t raise this point, but do agree with it — paying my own travel expenses and missing out on days of revenue to attend standards meetings several times each year is just not in my budget.

BPM vendors are unlikely to replace their own internal model formats with BPDM, but will translate to/from BPDM. Vendors need to review and understand BPDM and how it maps between different representations. There is a need for BPMN/BPDM conformance testing and certification of BPA/BPM products.

BPDM gives BPMN credibility as a modelling format since the specification is now “complete”. There was a great deal of discussion, both in this session and at other times during the think tank where this same point was raised, namely, that BPMN was rushed out without a serialization format, and that may have been a short-term mistake. One person at the table was concerned that combining BPMN and BPDM, and thereby increasing complexity, may be a mistake.

A comment that Phil Gilbert made on my TIBCO webinar Q&A post made a valid point about how there’s two main use cases for BPMN: non-executable process mapping and analysis by business analysts, and “visual coding” to create an executable process. We discussed this a bit at the roundtable, particularly around how business analysts could use the basic shapes (i.e., skip some of the internal graphic symbols that distinguish between different flavours of the shapes) and hence might benefit from a much simpler training program to get started. There was some discussion about how far up the chain that BPMN will or can be used for modelling businesses, e.g., whether it can be extended to strategy and goals or whether that’s more the mandate of BMM (Business Motivational Metamodel)

I had an interesting side conversation with Antoine after the roundtable ended about adoption patterns for BPMN and BPDM. Although standards organizations tend to have the “if you build it, they will come” attitude towards standards adoption, I believe that there needs to be some good reasons put forward for why BPDM provides benefits to the end customer and for the BPM vendors before we can expect to see widespread adoption.

BPM Think Tank Day 3: BPM & SOA panel

We’re starting to wind down a bit, and many of the east coast people have taken off already to avoid the red-eye flight home so the audience is getting a bit sparse. Those of us with presentations this afternoon, however, are still here.

First after lunch is a panel on BPM & SOA, and how they complement each other, with Tony  Baer of onStrategies and Brenda Michelson of the SOA Consortium. This is more of the mini-presentation format rather than a true panel, but I promised Brenda that I wouldn’t blame the presenters for that. 🙂

Tony started out with the “BPM is from Venus, SOA is from Mars” phrase, which we’ve all been bandying about for a while, although he really meant ‘business is from Venus and IT is from Mars). Considering, however, that Venus is the goddess of love (collaboration in its most basic form, perhaps?) and Mars is the god of war (technology shoot-outs and other battle language), that may not be far from the truth.

He addressed the culture issues: both business and IT talk about business processes, but business tends to take a top-down approach versus IT’s bottom-up approach, and business is using BPM to rationalize the business whereas IT is using SOA as the next great way to integrate applications. He sees a process orchestration battleground between BPM and SOA about where to do integration in a process. He also pointed out that BPEL is still at the “checklist” level (that is, it’s on the RFP checklist but not actually used) for most BPM applications, an opinion that I stated here a couple of weeks ago.

Brenda was up next talking about business-driven SOA and the SOA Consortium, and looked at the correlation between an Economist survey of late last year with her personal findings in touring around talking to CIOs and CTOs: the top thing that they state is critical for both revenue generation and cost cutting is the creation of services. One CTO saw BPM, SOA, Lean and Six Sigma all as the same basic thing, namely business strategy and structure, and they need to work together without artificial divisions between them in order to enable a platform for business agility.

Before SOA, business and IT strategy weren’t well aligned and were often developed independently, and the business process became an output of an IT solution rather than driven directly by business requirements. Business and IT need to collaborate on both strategy and architecture, which in turn drives out portfolio planning and delivery of the business solutions. She pointed out that also “enterprise architecture” is currently mostly technology architecture with a bit of business architecture on the side (if you’re lucky), in the future it will become more balanced with equal contributions from business and technical architecture.

Part of what the SOA Consortium is doing is providing guidelines for how the too-technical technology architects can become more valuable enterprise architects, and to break the artificial divide between business and IT. Part of this, I think, is similar to something I posted a year and a half ago, where enterprise architecture is not an IT function, but something that is in a strategic position between business and IT.

We’re off to do the last of the roundtables now, where I’ll be leading one on Enterprise 2.0 and BPM mashups. My notes will be on paper, and I’ll summarize them over here sometime on that overnight flight home tonight.