Small company security

A few weeks ago, I was involved in making a proposal to a bank for a consulting gig related to business intelligence. Although we had an inside track on what they wanted, and we proposed a team that could deliver the goods, they decided to go with one of the big management consulting firms, in part because they felt that the larger firm presented a lower risk.

I fought against this prejudice for years when I ran a small (40-person) systems integration company, and were shut out of some opportunities because of our size. Customers who did hire us realized that small is good: we tended to attract a better quality of team member, keep them well-trained, and motivate them appropriately through the right combination of profit-sharing and foozball tables. From the customer standpoint, they held a great deal more leverage over us than they would over a larger SI because they were a larger percentage of our business, and we were very motivated to make them happy, repeat customers who could be used as references. Our reputation was our main marketing asset, and the only way to make that work was to out-perform the big guys.

These days, given the abysmal track record of a couple of the big firms, I find it hard to believe that the myth of “big company = low risk” is still alive and well. The last time that I was involved in a project with one of the big SIs, it was more than a year late (at last check) and I’m assuming that it’s also way over budget. Also consider some of the recent layoffs announced at big companies, including a whopping 13,000 at IBM. Do you think that they considered the impact on your project before they laid off a staff member who works with you, or supports the project in some way?

Risky business, hiring these big companies.

OASIS takes on the meaning of SOA

OASIS announced yesterday the creation of a technical committee to develop a core reference model for Service Oriented Architecture (SOA). To quote their goal:

The SOA reference model will offer an understanding of the core elements within a service oriented environment and the associations and relationships among those elements. The reference model itself will not be directly tied to any standards, technologies or other concrete implementation details. Rather, it will be an abstract, designed to be used as a tool by software and enterprise architects developing specific SOAs.

The end-user organizations seem to be strongly behind this, given the participation of Boeing, General Motors, Lockheed Martin, Mitre, VISA, USA’s Department of Homeland Security, Japan’s Electronic Commerce Promotion Council, and Canada’s Public Works and Government Services. However, The Register reports today that some of the biggest names in enterprise computing have not yet hopped on board: Microsoft and Oracle, to name two. Shame, shame; you guys aren’t planning to go the proprietary route, are you?

SOA and process designers

A post last week on the problem of the economics of process change by Christopher Koch at CIO.com states the problem succinctly:

IT is in a mess because we have business processes that are locked into source code that is difficult to change or modify?that?s the real issue underlying the argument. That makes customization a dirty, expensive word.

Although he admits to possibly being “drunk on the Service Oriented Architecture Kool-Aid” that’s around, he sees SOA as a potential solution to the problem:

There needs to be a separate layer in the architecture for integration and business process change and coordination. Though web services aren?t always at the core of the layer, the concept of services is.

“Services” as a concept is interesting in this context, although I believe that SOA is just the flavour of the month in terms of naming. We did things like this years ago through appropriate encapsulation of functionality, and although our tools were a bit cruder than what is available now, we were essentially building services — when we did it correctly. Web services, WSDL and UDDI certainly make it easier to share these services, and I completely advocate their use for services to be shared within or between organizations.

The basic issue is that process designers shouldn’t need to understand the internals of the applications that they are orchestrating: they need to see applications such as ERP as a set of properly encapsulated, business-oriented functions that they can call at any point in a process. That means that the relevant functions within “legacy” applications (for lack of a better word) need to be exposed as discrete operations, and that an appropriate process orchestration tool be used to tie them all together.

And in another article of Mr. Koch’s that he links to from the above-mentioned post, he wraps the whole issue together with enterprise architecture, a concept that I also mentioned in a post last week. As more companies recognize the flexibility and business alignment that EA brings, process orchestration will take a more central role since it allows the IT assets that are enumerated through EA to be combined in new ways to serve the business needs.

Biz blogging

These past few weeks have seen an incredible focus on corporate blogging in the mainstream press, culminating in the May 2nd cover story of BusinessWeek, “Blogs will change your business”. (Given the topic is in part about the immediacy of press via blogging, and is coordinated with their (faux?) blog, the irony of a weekly magazine publishing their May 2nd edition more than a week before that date is not lost on me.) The print-based press is jostling for position in a world where blogs provide news and analysis ahead of them, and many are struggling with subscription models for news. Hugh MacLeod’s recent post about Les Blogs conference this week in Paris was spot on:

There a was session there where journalists were asking a lot of questions. I came away thinking, “Dinosaurs don’t like meteors”.

Although the dinosaur/meteor analogy may prove to be overly dramatic — TV was supposed to kill print media, remember? — plenty of others are also tolling the death knell for print.

More interesting blog fodder, however, is about blogging as a corporate marketing tool, especially for small businesses: we can make a serious marketing impact by blogging about our unique abilities, that is, the work that we love to do and that we do best. I quote an earlier gaping void post:

As a marketing tool, my gut instinct tells me that with blogs, the more expensive, molecular, “niche” and/or “bespoke” your product is, the better.

Although Hugh runs a Savile Row bespoke tailoring firm and I do strategic IT planning and architecture, his comment rings true for me: I deal with technologies and concepts (BPM, EA, BI/BAM) that are still considered niche in many of the large players in my target market (financial services); everything that I do for a customer is bespoke, because I fill in the gaps between the technology and their specific business. And in order to maintain visibility as an expert and an evangelist while keeping committments to my paid customers, I need to do this on my own publication schedule. What better place to do that than a blog?

Consider this my calling card.

Clearly…good customer service

Since I am often involved in helping my customers improve their business processes and their customers’ experience, I’m always on the lookout for examples of good and bad customer service in any industry. I deal with a lot of suppliers for business and personal items, mostly online, and rarely does one jump up and surprise me with their fabulous customer service. Recently, however, ClearlyContacts.ca has done just that.

Buying contact lenses online in Canada is a relatively new phenomenon, unless you order from the US and pay extra for shipping, duties and border clearance. When I lived in California, I ordered from 1800Contacts.com, so I recently decided to take my optometrist’s prescription in hand and order from them again, border crossing be damned. I went to the 1800Contacts site…only to find that they don’t carry my type of lens any more. Damn. I googled around and found another site, CoastalContacts.com, that did carry them; I filled my online shopping cart and was ready to check out when I saw that icon at the top of the screen, filling my heart with joy: the letters “CA” in a circle, right beside other circles: “US”, “UK”, “EUR” and “AU”. I clicked on the CA icon in trepidation, expecting it all to be some sort of dream, and was redirected to ClearlyContacts.ca, which appears to be Coastal Contacts’ Canadian-based shipping point.

I ordered on Thursday, but when I tried to check the order on their website the next day, I got Java/SQL barf all over the screen. To give them credit, the barf screen included a mailto: link to the site administrator, so I clicked and complained. Within a couple of hours, I had a response that explained that they were having trouble with the site, but that my lenses had shipped that day and gave me a Canada Post package tracking number. The email included a great tagline in the signature block:

Passionately committed to making every experience with Coastal Contacts positive and highly satisfying. For everyone. Every time.

The lenses arrived on Monday afternoon, all the way from Vancouver, days before I expected them. The best part? On the side of the ClearlyContacts packing box was printed a motto to live by:

Dance, Sing, Floss and Travel

The fact that they serviced my order correctly and efficiently may be considered a given (although this was a new supplier for me so not pre-supposed), but there’s some great customer service lessons to be learned from this:

  1. If one of your customer interface channels has problems, be able to respond to the issues via another channel. This requires proper integration of information and processes behind the scenes.
  2. In today’s market, it’s not enough to be committed to servicing your customers’ needs, you have to let them know that you’re passionate about it. That requires, of course, that you are passionate about it.
  3. Once you’re absolutely sure that you’ve served your customer well, leave them with a smile on their face.

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.

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.