Treating your partners right

I’m spending a few days going through some “virtual lab” FileNet training courses. Although I’ve worked with their BPM software with my own customers for over 10 years, and even worked for FileNet for a brief (but very informative in terms of corporate politics) period, it’s always a good idea to keep on top of the new versions. The virtual labs are a huge improvement over classroom training for me: not that I don’t want a trip to California, but hey, I’m the one paying for it, and I can’t just walk away from my real life for a couple of weeks. These are really well done, too: full classroom materials and notes, lab exercise books, canned (Flash) demos of how to complete the exercises, online access to a FileNet P8 system, and very responsive technical support. Since I already know a great deal of what’s in the course material (I think that I wrote some of it!), I can zip through pretty quickly without being bogged down by newbies in a classroom.

The cost of FileNet — and other vendor — classroom training just doesn’t make sense for the small incremental value that I would get from it: to become certified in a product via classroom training would cost me thousands of dollars in course fees alone, plus travel expenses and lost revenue opportunities. Considering that no single product is more than a small part of my current business, the cost-benefit analysis just doesn’t fly. FileNet has made it hugely attractive to partners to take the virtual lab courses right now, probably because there’s a lot of other partners out there running the same numbers and coming to the same conclusion: for occasional business, and especially for small/one-person shops like me, this stuff is way too expensive. Most of what I do with my customers, even on a FileNet-related gig, has nothing to do with FileNet: I’m a strategic IT planner/architect, so it’s about developing a strategy for selecting and applying technology to business, high-level business process redesign, enterprise architecture and a host of other things. When we do get down to the planning and design of the FileNet-based solution, I need to know portions of the product well, but it’s usually a small part of my engagement and you can be sure that by then, there’ll be people around with the full installation, administration and developer certifications.

For those of us who make it our business to know multiple vendors well and who have been involved in actually implementing (as opposed to just selling) systems, we bring value to our customers not because we’re certified with any particular vendor, but because we understand how the rubber hits the road. In other words, I want all (or most) of the training that I would need to be certified by the vendors, but the vendor certification itself means very little to me or my customers. I’m selling my expertise and experience, not reselling my investment in vendor classroom training.

Message to vendors, #1: Stop trying to make money on partner training: it should be a loss leader and considered a cost of sales development. I have a big problem with paying you thousands of training dollars to give you a knowledgeable player (me) in the field that helps you sell more software, when I’m doing consulting that is often quite peripheral to your product. If I meet the requirements of your partner program, give me your software and train me for free, or for very cheap. That goes for conferences as well: if I’m good enough to be in your partner program, don’t charge me thousands of dollars to attend your partner conference, because by the time that I add my travel expenses and lost revenue for the week, it’s not worth it.

Message to vendors, #2: Plan your certification programs to include people like me, who do strategy, planning and design, but don’t do coding or installs. Although I’ve done it in the past, I’m very unlikely to be writing code or installing systems any time soon. I use the term “BPM solution architect” to describe what I do on a BPM project, but that term has somehow been perverted to mean either a pre-sales technical consultant (by FileNet, for example) or a programmer (by wishful-thinking customers who believe that one person has the experience to do the design and architecture, but still has a low enough price point and is not too rusty to do the coding).

Sure, if you make the training free, then you’ll spend some time fending off people who aren’t serious about your product or even capable of understanding it. However, charging a large fee for training definitely means that you cut out the small, very capable players (because we can do something unrelated to your product equally well), and based on my experience with large, well-funded systems integrators and consultancies, there’s no guarantee that the ability to pay is accompanied by the ability to do something good with your product.

Caution: rogue TLAs

I was listening to a presentation on IBM WebSphere today when the speaker, Deon Newman, IBM’s Director of WebSphere Marketing and Communications, made what I consider to be an excruciating misappropriation of a TLA. (I know, two consecutive posts about IBM: consider it a statistical anomaly)

First of all, the presentation was supposed to be about using WebSphere to automate business processes, that is, business process management, or what most people who have anything to do with process-based technology would abbreviate as BPM. However, it was very narrowly focussed on using WebSphere MQ V6 for the EAI (system-to-system) portion of BPM, in spite of a nice boilerplate slide on integrating people, processes, information and applications. Fair enough, still some interesting information, but if these MQ guys are going to join the party, they have to realize that MQ-type EAI is part of a larger BPM picture.

To confuse things further, there is a field of business intelligence and analytics called business performance monitoring — also abbreviated as BPM — which is what we used to call executive information systems (EIS) or decision support systems (DSS). Within the process world, the monitoring of business processes and performance is referred to as “business activity monitoring” (BAM), probably to distinguish it from the “real” BPM, and because it can include raw activity data as well as aggregate performance measures. The upshot is that for process-centric players, BPM means business process management, and monitoring of the processes and other performance measures is BAM. Gartner published an interesting report on the convergence of BPM and BAM last year, but they still classify them separately, and under those names. To clarify the overlap, a BPM system may include “BAM Lite” capabilities for monitoring the processes that it models and executes, but a full-on BAM system allows for inputs from several systems, including BPM systems, to create an overall view of the business activities. Of course, there’s also another BPM, business process modelling, although that is widely accepted as part of business process analysis (BPA) because of the round-trip nature of modelling and simulation.

Anyway, at the end of the presentation, Mr. Newman was asked a question about whether WebSphere MQ included BAM. He started his response by re-labelling BAM as “business process monitoring” and stating “We use the moniker ‘BPM’.” Huh? A third, slightly different meaning for an already overloaded TLA? Tsk, tsk. I was left with the feeling that either IBM doesn’t really have a clue where WebSphere MQ fits into the world of BPM (that’s business process management), or they’re not paying attention to anything that anyone else is saying, or they’re attempting some creative marketing spin.

I’m not beating up on IBM specifically, I’m beating up on the marketing department of all vendors who misuse commonly-understood terms or invent completely new ones, to the detriment of the businessperson who is trying to wade through all of the doublespeak. Although some part of what I do with any customer is to sort out vendor terminology and product taxonomy, it’s not always a very exciting part (for me), and I wish that the vendors could just follow some basic guidelines for not confusing the customers. Like agreeing on their TLAs.

IBM tops AIM market, but what of BPM?

A press release this week from IBM announces that a preliminary Gartner report on application integration/middleware (AIM) and portal software has crowned IBM as the market leader based on 2004 licence revenue. Their figures put IBM’s share at around 37% of the worldwide market, with chief rivals BEA, Oracle and Microsoft trailing far behind at 7.2%, 4.4% and 4.3%, respectively. The full report is due out at next week’s Application Integration and Web Services Summit.

As you poke around in the data, however, you find out that the number is made up of several products, including application servers (where they compete with BEA), integration software (where they compete with TIBCO, Microsoft BizTalk and webMethods) and portals (where they compete with Microsoft SharePoint). In fact, I suspect that anything that carries the “WebSphere” brand is considered part of their AIM stable, including ongoing licence fees for tons of pre-WebSphere-era MQSeries installations connecting ancient IBM mainframes using proprietary protocols. If you check out IBM’s software product list, there’s a whole lot of WebSphere going on, and it didn’t all start under that brand. In fact, I remember when what is now WebSphere MQ Workflow was rebranded from “FlowMark” to “MQSeries Workflow”, prior to its re-rebranding as WebSphere a year or so ago. Since MQSeries was the hot new brand at the time of the first rebranding, it was seen as an attempt to “standardize by branding”, although FlowMark wasn’t even based on MQSeries until much later.

From a BPM standpoint, the biggest complaint that I have about IBM’s products is the apparently piecemeal strategy. In recent years, we’ve seen a number of products put forward by IBM as BPM and/or workflow: WebSphere MQ Workflow (a somewhat clumsy workflow product that never really developed into a cohesive contender), Content Manager’s Document Routing (a very simple routing capability for document-based workflows), Lotus Workflow (I’m not even going there), Advanced Workflow (now apparently being sunsetted), and the latest entrant, WebSphere Business Integration.

WBI, previously called WebSphere Process Choreographer, is based on the CrossWorlds EAI product acquired by IBM: just type in www.crossworlds.com and see where it takes you. Because of that origin, it’s coming from the EAI space, and my concern is that the product focus will remain on integrating systems and will never fully develop the human-facing functionality, including business-focussed tools for modelling, simulation and analytics. Gartner’s 2004 magic quadrant for pure-play BPM doesn’t mention any of the IBM products, although they did show up in the 2004 magic quadrant for business process analysis due to the Holosofx acquisition.

If this is going to be the next-generation BPM product, IBM needs to stop spending so much time listening to the IT departments (who get far too excited about EAI) and spend more time listening to the business departments in order to develop the human-facing components that they need to move into the pure-play BPM market. At the very least, they need to perform a mercy killing on MQ Workflow as soon as possible to reduce customer confusion and focus their efforts on a single BPM product offering.

Of course, there’s always going to be some platform limitations to WBI: it’s going to require WebSphere Application Server and WebSphere MQ. Given the market penetration of WAS and MQ in large organizations, however, I don’t see that as a problem; the opportunity to grab a huge BPM market share is theirs to blow.

Legacy attitudes

I work mostly with large financial services clients, which means that there’s a lot of legacy software around. They seem to be pretty good at updating the hardware to avoid the threat of an unsupported system outage, but most of the custom software just keeps getting older and older. In many cases, large portions of the software aren’t even used any more, but have been superceded by functionality of newer systems or processes; however, no one has the time or budget to go in and prune all that unused code out of the production systems. Very much of an “if it’s not broke, don’t fix it” attitude, but unfortunately that results in a lot of unmaintainable garbage that still, somehow, has to be maintained.

As big of a problem as legacy code is, the bigger problem in some organizations is their legacy attitudes.

One example of a legacy attitude is that regarding corporate software standards. There have been huge benefits for companies that standardize on a small number of software vendors, such as licensing deals (at first) and IT training costs, but somewhere along the line, the practice of barring all vendors except those on a rigid corporate standards list is going to come back and bite these companies where they least expect it. Not only are they potentially blocking best-of-breed vendors from coming to the table with business solutions, they’re potentially blocking new delivery mechanisms such as software as a service. As Chris Lindquist, CIO Magazine’s technology editor, recently wrote:

The big problem for these [software as a service] providers until recently has been mindset — software as a service just sounds dangerous to a lot of companies that have built themselves on foundations of millions of lines of customized code wrapped around software from a handful of vendors.

There’s a lot of other legacy attitudes out there, from IT career paths (why would a company force a brilliant technical mind to become a mediocre project manager in order to advance?) to the use of IM (if someone is responsible in their communications and corporate safeguards are in place, why does the medium matter?).

Challenge legacy attitudes at your own risk, however; in many cases, the people who put them in place are now in management positions, so tread lightly when you call their baby ugly.

Tom Peters… in the boxing ring?

I just had a chance to read the details of last month’s London Business Forum event featuring Tom Peters and Richard Scase in a boxing ring:

The room was cavernous, its high ceiling vaulted with oak beams. In the centre was a boxing ring, shining under floodlights, and on all sides were hundreds of seats, arranged as if for a prize fight, their legs wreathed in tendrils of dry ice. The delegates filed in via a mezzanine, some open-mouthed with confusion, wondering for a split-second if they had the right place, as a familiar tune thundered over the giant sound system: “Eye of the Tiger.”

Thus began the London Business Forum 2005.

…Newcomers to the London Business Forum were told they should expect the unusual and the speakers duly arrived in a burst of disco lights and dance music, wearing brightly coloured silk capes.

Too funny! I definitely want to attend more conferences like that. In fact, I want to do more business like that in general: more fun, more creative, more engaging. I’m often in the position of trying to get passive members of a team to become active participants, and having some unusual “fun” components is a great way to engage people, although I can’t see myself in a boxing ring wearing a silk cape any time soon.

Don’t miss the great quote from Prof. Scase on leadership: “We currently have too many 21st-century managers and not enough 21st-century leaders. We have a flood of 300,000 MBAs and I think they should be treated like garden manure: spread thinly.”

Think big, start small

I watched an SAP presentation today about their NetWeaver platform, and although the product was only of peripheral interest to me, I love their philosophy on how to get started on a project: think big, start small.

I can’t even count how many projects that I’ve seen fail, or miss their targets significantly, due to over-reaching on the first phase. Usually, someone gets all excited about the technology and before you know it, they’re trying to implement the 8th wonder of the world in Phase I. Schedules slip, but even worse, vision slips: often, no one is left with a clear idea of what is to be accomplished, or the path to getting there. [Of course, the converse is just as bad: the pilot (a.k.a. Project In Lots Of Trouble), where someone hacks together a system without proper design or testing, and it becomes the cornerstone of a future legacy system, but that’s a story for another day.]

This type of scope creep is especially prevalent on BPM projects, since it’s so (conceptually) easy to just add another step to the initial process, then another, and another. What starts out as a simple process with 2 human touch-points using an out-of-the-box interface and 3 system touch-points using standard adapters becomes a morass of custom interfaces and extraneous exception paths. Without fail, the biggest argument that I ever have with anyone on a BPM project is about keeping the first phase small so as to get something into production sooner.

Of course, as a designer, I believe in getting some amount of the design work done up front: you have to understand the overall scope and the required functionality to provide a framework for the work, but you also have to carve off a reasonable first phase that won’t take too long and will provide a useful system, when implemented. In the case of BPM projects, if you can’t implement that first something inside 6 months, there’s something wrong with what you’re doing.

Think big, start small.

Skype me!

Tons of stuff showing up these days about Skype, a free VOIP service, such as a ZDnet article, “Skype goes for the gold”, discussing how the newly-developing paid add-ons will eventually allow Skype to become profitable while remaining a free service for computer-to-computer calls. The longest-standing paid service is SkypeOut, which allows you to call any landline at greatly reduced rates, presumably because it makes the connection from your computer to the target country via IP, then bridges to a landline for a local call. New services coming out are Skype Voicemail and SkypeIn, the latter being a phone number for your Skype identity that allows a landline user to call you. For example, if you live in South Africa but do a lot of calling with the UK, you can get a UK phone number that, when called, will ring through to your Skype session on your computer, no matter where you’re located at the time.

I’ve been using Skype for a number of months now, for both voice and text (IM). Although I primarily use it to talk to other computer-based users in Australia and North America, I also use SkypeOut for making overseas calls, and for making calls when I’m travelling in order to avoid mobile roaming charges. If my hotel doesn’t have broadband (a rarity these days), I can just find a wireless hotspot, connect my laptop, plug in my headset and make calls on Skype while I download my email. Okay, I look a bit geeky doing that, but it’s worth it.

My only problem is that at my current rate, I won’t use up my €10 SkypeOut credit before I’m 90: I made a four-minute call to the UK earlier this week that cost me less than €0.07.

The Case for BPM

Another interesting lunchtime webinar today, “The Case for BPM”, this one featuring Janelle Hill, a VP & Research Lead from META Group (acquired by Gartner as of last week), and Gary Morgen, a VP from Citigroup. It was sponsored by TIBCO, but the first two speakers ran overtime and the poor TIBCO guy had to squeeze his 11 slides into about 30 seconds. Some would say that’s all the time that a vendor should have in an educational webinar, but come on, give them a break, they paid for it.

I really liked Ms Hill’s focus on tying process improvements (and hence the use of BPM) back to business performance objectives or a process improvement methodology such as Six Sigma: although that might seem obvious, there’s a lot of people who get wrapped up in the cool technology and lose sight of what we’re actually trying to do here, which is to improve someone’s business.

I disagree with her broad description of a BPM suite as “unifying workflow, EAI, document/content management, portal and web services technologies”, because I don’t consider content management or portals to be a part of BPM, but rather complementary technologies. Given that we’re migrating to an SOA world, however, the boundaries are starting to blur.

Mr. Morgen talked mostly about Citigroup’s TIBCO/Staffware implementation, but he also had some great words about reducing time/cost of application development by using best-of-breed vendor solutions rather than building it themselves: a refreshing viewpoint to hear from the financial services world, where huge organizations have spent billions of dollars in the past writing their own word processors and database engines. I’ve written previously about the value of using COTS components such as e-forms, so I’m completely aligned with Mr. Morgen’s views on this subject.

I also like the cool Blackberry integration that they’ve done to their workflow, although I don’t want to appear too wrapped up in the technology.

TIBCO will be making this webinar available for download or replay on their website soon; even if you’re not interested in TIBCO/Staffware specifically, I recommend listening to Janelle Hill’s portion for a reality check on establishing your business drivers for BPM.

Also, it will be interesting in the months ahead to see how Gartner and META reconcile their sometimes very different opinions on BPM.

The dreaded “consultant” title

Not unlike the prejudice regarding conference pricing that I discussed in this post, I just got dissed by DCI for using the title “consultant”.

I had a call from DCI this morning, but I was a bit distracted with real work and thought that this was a sales call, so I wasn’t paying a lot of attention. I just wanted to get through to the part where he would say “would you like any more information”, I would say no and get off the phone. Instead, he said something like “Our business networks are vendor- and consultant-neutral, so judging by your title we don’t think that’s it’s appropriate for you to join. Do you require any other information about us?” I was completely in the dark about what he was talking about, so I said no and hung up.

A few minutes later, I started wondering what this was about, searched through my browser history for DCI, and realized that I had applied to join their Business Process Management business network, about which they claim:

The Business Process Management Network provides a forum for you to learn and share best practices, challenges and solutions. Learn how to effectively identify, analyze and design processes to improve the overall flow of information within your organization.

Members of the Business Process Management Network are involved in the strategy, implementation, execution and management of all functions across the enterprise. They are the individuals who work together to identify, define, streamline and improve processes through business and IT solutions — to meet the needs of the organization, on time and within budget. Members include:

  • Business Analysts
  • Systems Analysts
  • Business Managers
  • Business Process Owners
  • Change Agents
  • Directors / VPs responsible for Enterprise Management
  • Financial and Compliance Professionals
  • Process Analysts and Designers
  • Project and Program Managers
  • Quality Assurance Professionals
  • Strategic Planners

Okay, count me in. I have lots of best practices experiences to share. I’m involved in strategy and implementation. I identify, define, streamline and improve processes. I take on the role of business analyst, system analyst, change agent, process analyst and designer, and strategic planner.

However, since I used the word “consultant” in my title as a sort of shorthand for what I do, they turned me down. Is this some sort of weird discrimination? Are there so many unqualified people using the term “consultant” that I have to abandon it for all time in order to not appear incompetent by (word) association? Or does DCI feel that having a “consultant” in their midst might detract from their own educational programs?

Luckily, since I run the show, I can take on whatever title that I want, so it’s time to go for something that won’t get me banned from the nice places. Or even from DCI.

Alphabet soup for lunch

Just watched a great lunchtime webinar, “The Business Value of Process Standards”, although I was dining al desko and managed to drop sunflower seeds into my keyboard that required some mid-webinar keyboard surgery. I mentioned this webinar in a previous post on BPM standards, and was glad to see that it lived up to my expectations. eBizq usually makes the webinars available for replay on the same link within a couple of days, so you can check it out if you missed it live.

Jeanne Baker, the primary speaker, is VP of Technology at Sterling Commerce, but she was speaking in her capacity as Chairman of BPMI and didn’t even mention Sterling’s products. In fact, the webinar was sponsored by Oracle, so the only product that was (briefly) discussed was Oracle’s BPEL Process Manager.

Since the discussion was on standards, the inevitable alphabet soup resulted, but two acronyms floated to the top of the broth: BPMN and BPEL. BPMN is a standard for modelling business process notation, and BPEL is a standard for executing business processes. Conveniently, BPMN maps directly to BPEL, so they work in concert for designing and implementing business processes. Both of the speakers stressed the importance of the BPMN and BPEL standards, a point with which I fully agree.

On the subject of modelling standards, I especially liked Ms. Baker’s comment on the use of UML for process design (which echoes my own sentiments from my previously-referenced posting): “UML is used by poor, hapless process modellers [who didn’t have anything better, such as BPMN].” I was laughing so hard when I heard that, I didn’t get the whole quote, but that’s the gist of it.

It’s also worth checking out the newly-designed BPMI site, it’s a lot nicer to look at and has a great deal more information than on my last visit there. It gives a much better definition of BPMI’s role in standards development, and features an interesting graphic that Ms. Baker also used in her presentation to illustrate BPMI’s involvement the lifecycle of business process management:

The diagram shows Process Designers as an essential link between business analysts and system architects, but that skill set is often absent on BPM projects. As she spoke about the importance of that role, it struck me that although I started my career as a developer and software architect, I now usually sit in the process designer role, while spreading in both directions into business analysis and system architecture. I describe myself as a “technology catalyst”, because I like to make to make stuff happen, especially that bridge between business and technology.

From the BPMI site:

BPMI focuses upon the Business Process as the inflexion point between the business environment and a technology implementation. Our work is relevant to a wide range of audiences as we innovate a seamless transition ‘path to execution’ for Business Processes. Our aim is to unify process thinking across Business and IT disciplines.

A lofty, but very worthwhile goal.