My work, BMC Software, Inc. has a lot (7) of what they call “Client Architect” positions open. We have several types of architects, but this one appears to be a high level tech-sales type: working closely with customers to help them fit our software into their business and process, of course, with the goal of making those customer’s IT more effective and, as I always like to throw out, money-makin’.

Put another way, it seems to align nicely with the advice I gave in one of my recent posts, The Disappearing SysAdmin and Enterprise Software Vendors: enterprise software is increasingly more about people and service, and less about the exact software. Or, as “Friends of DrunkAndRetired,” RedMonk put it, “focusing on business and operational context rather than speeds and feeds and feature tick-lists.”

Anyhow, here’s the job listings if you want to apply:
one,
two,
three,
four,
five,
six,
seven. They’re all the same job, we just have seven slots open. You can probably just apply to one of them.

The recruiter who posted on Austin JUG (no link yet) said “[t]his is a critical role within the company and they pay these Architects bases from $110k-125k with 35% incentive component.”

If you put down my name as a reference, I get a tiddy pay-out, so I’d appreciate it. Feel free to email me as well.

As a disclaimer: I’m one person in a 6,000+ person company, so I have no idea about these jobs, I just found them thanks to Kinman noticing them posted on the local Java User’s Group.

Tags: bmc, hiring, jobs, software, sysmgmt.

Steve’s latest post on Sun opening up JES reminds me a trend I’ve been seeing and theorizing about over the past year. The case of the disapearing sysadmin.

Software is Worthless Without People

Here’s the excerpt that stoked my memory, with emphasis added:

One of [Sun’s] customers, used to having Jonathan’s home # for support, suddenly discovers that the software he’d been paying for is now available for free, and says “HA! I’m not paying you $500K for something that’s free!” The punchline, of course, is that upon discovering that they’d essentially be on their own not if – but when – something goes wrong, they add it right back on the PO.

Distilled down, this says that the value in Sun’s software is shifting from the bits to the services and support layered on top of it. That’s a bet that a lot of folks within the software world are making right now. Is it the only way to make money in software? Nope. Is it going to be the dominant pricing format? Not in the next year or two, probably, but longer term? Maybe.

…

I don’t know if it’s literally true that Sun does not have a customer in the world that runs an unsupported product in their datacenter, but figuratively the point is made: enterprises want problems with the software to be someone else’s problem. Therein lies opportunity, as they say.

In the support I’ve done for the past few years, I’ve noticed that it’s a rare find to get a systems administrator or DBA on the other end of the phone. The software we build is a systems management application: it’s a sort of sysadmin in a box. (The company has been expanding up the corporate ladder, but that’s another story.)

As with most enterprise applications, there’s a whole lot of whirling bits and blinking lights under the covers: an application server, a database, a web server, and all the little glue in-between. The other “exciting” part of the application is that it’s whole goal in life is to interact with other computers and applications, sucking out monitoring data (the digital answer to the question of “hey, how you doin’?”).

Now, whenever one computer thing talks to another computer thing, all sorts of problems and errors occur, and you need a person to sort them out. Usually, this “sorting out” means setting some configuration, adding some permissions to an otherwise restricted device, or cleaning up after a messy application. It’s the kind of thing that’s obvious to a person, but completely baffles a computer. (Technically, to say it “baffles” the computer is to be way too kind in anthropomorphizing the computer.)

To summarize:

The Vendor is the SysAdmin

The job of sorting things out for the computer is the purvey of the systems administrator (a sysadmin) or, in the case of a database, a database system administrator (a DBA). In the “the old days,” a vendor could sell some tool software to a customer, the customer’s system would need some sorting out to get the software to run, and the vendor would get ahold of the sysadmin or DBA and say something like “yeah, you need to switch over your primary hoopty-ha to accept tokens with goo-gazits,” and the sysadmin would say, “oh yeah, they disable that by default. Will do. Switching over the hoopty-ha, boss.”

And it was fixed, and your support call lasted 5-10 minutes.

Now, I never lived in such times. I live in the age of the disappearing sysadmin: there are very few sysadmins (as I envision them) in corporate American anymore. My theory is that customers are looking towards enterprise vendors to not only sell them the raw tools, but also all the servicing. This is Carr’s world of “IT doesn’t matter”: you don’t staff up experts in areas that are out-side the core-compentency or domain of your company. To do so would be to waste money, ’cause they’re not going to do anything to differentiate you from your competitors. If you’re an insurance company, you don’t get a bunch of expert IT wonks to keep all your computers happy: you get a bunch of genius risk assessment experts, marketers, lawyers, and those people who come up with all those byzantium policies.

A la carte Sysadmin

Instead of paying for those wonks, you pay an enterprise vendor a shit-load of cash, and call them up whenever something goes wrong. This works out well for you, because IT vendors (now-a-days) are desperate to keep customers and will do anything to keep them. That is, you can usually get them to do things like sit on 5 hour support calls to get your afore mentioned hoopty-has all goo-gazited up correctly. And, you know, you don’t have to worry about maintaining your own cranky stable of IT wonks: not to mention not having to pay all the ice berg “overhead” like health-insurance for them. Nope, you just pay that one fat bill every few years to your vendor.

Vendors: Get Some Sysadmins

What this means for enterprise vendors, of course, is that they need to start staffing up for these expectations. As time goes on, customers will be expecting more and more sysadmin support from vendors, if they haven’t already. Many vendors probably have the belief that their programmers — the people who wrote the enterprise software — can fill this role. That’s far from the truth though: the skill-set of a good systems administrator and that of a good programmer are rarely in the same person.

More importantly, you probably haven’t hired with this in mind, so you can’t just dump the sysadmin role on your programmers. (I mean, you can try, but your customers will stop being so happy to send you checks after they get shitty service, and some of your programmers, longing for the Divine of the Abstract while they’re wallowing in the icky-goo of a sysadmin’s tasks, will up and leave.)

The Software as a Service Angle

The whole web-based SaaS fits with the vendor-as-sysadmin trend to a great degree: with “nothing” to install but a web browser and maybe a simple desktop app (think of Flickr as a good model for this with their web based app and a simple Uploadr thick-client tool), you don’t really need a legion of IT wonks to take care of the boxes that your enterprise apps run on. Nope, you just fire up the web browser, and any errors you see are completely in the court of the vendor you’re paying for that web app. You couldn’t even sysadmin the app if you wanted to: you don’t have access to the computers the app runs on.

From the vendor’s vantage, offering SaaS has the potential to save money: it’s much easier to troubleshoot problems on your own systems than you’re customer’s systems over the phone. Not to mention you can actually be pro-active in fixing problems and preventing them from occurring (everyone who’s done any enterprise software support has the story of the customer who did something like edit a configuration file, delete a vital file, or otherwise do something a long-beard would roll his eyes at).

Selling Software and Service

One customer once told us, “we evaluated your competitors, vendor A, B, and C. In the end, you were all more or less the same: we could easily fit your app into our business process [not the other way around, you’ll note –Coté]. But, you guys had the best customer service, so we went with you.”

That is, the software on it’s own wasn’t the major differentiation, it was the software combined with the service. More importantly, the value, in this case, shifted more towards the service than the software. As Steve points out, this means you can open source (or “give away” from the perspective of the money-folks) your software and still make money.

This probably isn’t true for every vendor right now, but I’d wager a few bucks that they’ll go that way soon. Hell, they used to just give the software away with the big iron. It wasn’t ’till later that we injected value into the software itself. It’ll probably take another few decades before the cycle comes full circle and software, once again, becomes second fiddle to the service, and other goods, the vendor provides. That is, the enterprise software market will become a conversation.

Update: the SaaS strategy that Ray Ozzie’s “The Internet Services Disruption” memo talks about fits nicely with the above as well.

Tags: business, enterprise, it, software, sysmgmt.

When bookmarking or link posting, it’s proper etiquette to put in a “via” that indicates where you got the link from. I do this a lot in my own bookmarks in the descriptions, e.g., “(via mray)” or “(via sog)”. That great wunderkammer, boingboing is the prime example of this behavior, they’re really good at doing it.

For quite sometime, I’ve been fretting over whether I should do vias in del.icio.us as tags instead of parenthetical stuff in the descriptions: if I got a link from Matt Ray, I’d use the tag via:mray.

Uses

• I could more easily see a list of links I’d gotten from people. I could even make a tag bundle out of it. (This is where smart tag bundles would be nice, so I could just say “put all tags that start with via: in this bundle.) Of course, it’d mean I’d want to do a tag search like via:* for all tags that start with via:. I’m not sure if the del.icio.us search syntax allows for this.
• It’d be a cheap networking/link spelunking thing. If I used the same text in in the via tags as the person’s del.icio.us ID, you code something up to layer on a link between the two of them. That is, you could offer the feature: “If you liked this link, check out more links from the person who sent this to Coté”.
• I can get an idea for who sends me the most links by counting up how many via:mray’s, fro example, I have.
• People could subscribe to all links suggested by mray, scoped down to my bookmarks, or everyone’s bookmarks. That’s sort of like reverse bookmarking…or something.
• People who send me links can track the effectiveness of sending me links. That is, if I like the link enough, I’ll bookmark it, slapping on the via: tag. So, folks who send me links can answer the question “which links that I sent Coté did he really like: like enough to go through the effort of bookmarking?”

How’s That Sound?

Yeah…. So…. Maybe I’ll start doing that. Anyone else do this? Have any thoughts?

Technorati Tags: del.icio.us, tags, web2.0

If you haven’t checked out the Ozzie Microsoft strategy memo, you should put aside the few minutes to read through it. It’s valuable in several ways:

1. It’s an example of exactly the kinds of technical leadership and communication you’d expect at a software company. A software company lives and dies by it’s developers (medium- to long-term at least: you can always vaporware some short-term cash), so it’s obvious that those are the people your most important communications should cater to and address.
2. There’s a start of the “be the infrastructure, not the end product” strategy I talked about a few days ago. That is, in a more DIY/good enough programming/ecosystems culture, for a large company that needs a steady revenue stream, selling the tools is more stable than selling the actual artifacts of those tools.
3. The fact that it’s out shows — intentional or not — a willingness to engage in very
   Cluetrain
   -ish PR. In this new development mentality, the more info you share, the more cred you get: secrecy is for the old foggies of technology. (There are still some issues to be ironed out with non-developers, but the PR for only developers is looking sound.)
4. It has a summary of Web 2.0 development (or “contemporary web-as-platform programming” for all you curmudgeons), in just 7 words: “treat[ing] the ‘raw’ internet as their platform.” The fact that a high-level exec [or his staff, etc…. whatever] can and is articulating it is significant: not to the lucky people already doing it, but to all the BigCo coders who wish they were doing it but can’t get their management chain on board.

Those are just a few highlights, there’s more to be had from it. The most significant thing, of course, is that it’s coming from Microsoft: a huge name that people who make decisions can, and will, take guidance from.

As the last point addresses, BigCo management chains rarely listen to their own highly paid developers; instead they look for outside validation of new technology directions. On that issue in particular, if you’re up on your internal marketing theory, this memo is a big arrow in your quiver. Now go shoot it.

Update: some of the ideas I outlined in another post, “The Disappearing SysAdmin and Enterprise Software Vendors” fit well with the SaaS stuff in this memo, with the change that the ideas in the memo at hand are more consumer software than enterprise software centric.

Tags: biz, ecosystems, enterprise, msft, programming, software, web2.0.

Mr. Twiggs came by to talk to me about a way to put a sort of “here’s all the links to my online self” service together. The idea is that someone such as himself (and definitly such as myself) have all sorts of different content strewn through out the web — flickr, del.icio.us, Amazon reviews, eBay reputations, static web pages, podcasts, Netflix rentals and reviews, etc. — and we want some page to point to that lists all of that stuff, that answers the question, “can I see all of Glenn Twigg’s online life?”

That is, you want a site map, but not just restricted to one site, a site-map that spans the entire web.

I don’t really know of successful system that does this yet…otherwise I’d probably be using it.

The Roach Motel

The metaphor of The Roach Motel (started by Steve Gillmor, I believe) is that all these online services tend to lock your data up in them. For example, you can’t extract and use the reputation data about you from eBay; you can only use that data in the context of eBay. Like roaches to a roach motel, once your data gets into eBay, it can’t ever leave. (Check out this edition of The Gillmor Gang from last year for an exquisite grilling of eBay’s Jeff McManus on this point.)

So, in my mind, what Mr. Twiggs is looking for is a roach motel buster: something that will layer on-top of all the websites and roach motels out there and aggregate the data into a centralized place, or, at least, view.

Roach Motel Busters

While there’s no ultimate Roach Motel Buster, there are what we’d in the enterprise software world call “best of breed” roach motel busters. For the benefit of Mr. Twiggs, here’s the ones I can think of:

• Google Sitemaps – providing a way of helping crawlers understand the important links in your site. Also see this article.
• FOAF – capturing your social networks. Among some blog software, livejournal widely uses FOAF.
• attention.xml – multi-year winner of the Will It Ever Cross the Chasm Award in Excellence…. glibness aside, it unlocks the clamp-down on keeping up with your friend’s (and own) interests. (I favor a less formal approach.)
• Erik Benson’s Megablog – Erik’s put together some scripts (I’m guessing) to centralize much of his online activity into one blog, erikbenson.com. Essentially, it pulls content from a bunch of sites (check out the “Getting Stuff From” sidebar) he puts content into, and “cross posts” that content to the megablog. It’s pretty damn cool, and I’m sure it gets info-wonks like myself all hot and heavy.

So, we can only hope that Mr. Twiggs will figure it all out for us and provide this service and/or format. It doesn’t exist yet, but it’d be a lot cooler if it did.

Technorati Tags: blogs, collab, ideas, infoglut, web2.0

I’ve been borrowing one of the ITIL books, Service Support, from work. As someone who gets jazzed about devices that have SNMP agents on them, it’s an exciting read. So far — on pg. 43 in the service desk section — it’s been great at the simple, but rarely done, task of simply defining all the tasks and motivation that you’d expect IT to perform.

Knowledge Ain’t Cheap

The problem with these books is they’re so damn expensive. I could make my car payment with the amount I’d spend buying all the ITIL books. Unfortunitly, it doesn’t seem like there are free downloads from the OGC: I guess the UK doesn’t have the same “anything the government produces will be free” policy that the US has. Or, more than likely, they’ve figured out a loop-hole with this one.

Manual Meta-Info

The deal with me and books is that I like to write all in them, dog-ear them, and otherwise add in meta-information. On many occasions, I’ve been known to use the blank pages to write letters and other notes. I work books like pairs of jeans: I’m not satisfied with then until they’re broken and worn. When you borrow a book, this isn’t possible, and I keep feeling like I’m only half expieriencing the borrowed book.

Not to mention the fact that these ITIL books would be great references, which is only possible if you own the book. Need to know 18 things to consider when putting together a service/help desk? As they used to say in those Time Life commercials, read the book.

Got Any Cheap Books for Me?

So, if anyone knows where I can get some cheap versions of these books, I’d appreciate it. It could be hard-copy or PDF, I don’t really care.

Technorati Tags: book, itil, sysmgmt

I’ve been thinking about Amazon’s Mechanical Turk off and on for the past fews days; Check out Lenssen’s write-up of it for a definition.

It makes me think of a general rule of technology: if something is going to be commoditized, in order to keep your money-flow stable, you want to be an infrastructure provider. That is, you want to create the raw materials used by the people making and selling the commodity. But more importantly, you want to centralize that raw material.

Middle-man for Questions

Even in a seemingly peer-to-peer environment like the Mechanical Turk, there’s a point of centralization: the middle-man who connects together the node asking the question and the node who have the answer. Because the Mechanical Turk is a service instead of a downloadable server, they can avoid be commoditized out of the market, as with email servers: even if the nodes on both ends of the question/answer loop get really big and popular, they’ll still have to go through Amazon, who can slice off a little take.

Web 2.0 Services Are Middle-men

Most these fancy new apps that are on-line services that cater to developers (check out Udell’s comments in the beginning of the latest Gillmor Gang for more on that) can be, and are, in this middle-man position. What’s different from the middle-man gambits of “yore” is that the middle-man are making it easier and encouraging developers on either side of the service to layer on value and functionality.

Older web companies focused on being both the infrastructure and the sales-man. That is, they made the widgets and they did direct sales to customers. On the web, it’s easy to do both (among other examples, as Amazon and eBay do to much success), but if you have to choose one, it’s usually better to choose providing just infrastructure, and letting a bunch of other people figure out how to monetize it.

Spreading the Risk

There’s a huge amount of risk that no one will take up your service, but then again, once more than one person starts putting nice UIs and products on top of your serve, you’ve spread your risk over those two people: if one of them fails, you still have the other.

So, back to the Mechanical Turk (which is always fun to type), Amazon is hoping that someone else will figure out how to make killer apps (or, at least, “stunning apps”) out of the infrastructure it provides. And once those people figure it out, they’ll take little slices of the revenue.

Many people, Google included, have already built question/answer platforms, but, in my mind, they haven’t really done too much with them. The reason, as some of you wonks out there might thinking, is because things like Google Answers aren’t really extendible: they only do the one thing, you can’t microchunk, free, syndicate, and monazite it.

The Closed Doors of Enterprise Apps

Does enterprise software have a dog in this fight? In consumer software, this line of thinking makes a lot of sense. Profit in consumer software relies on volume: the more people using it, the lower the price you can charge, the lower the price you can charge, the more people will buy it, and the more money you’ll make off the thin margins. (Of course, you might be lucky to be in a story only market, and then price isn’t as much of an issue. I’d suggest that few in technology [Apple] are lucky [or smart] enough to be in that kind of market.)

In enterprise software, you don’t have that many users. Indeed, the more users you have, the more support you’ll have to provide, and the less money you’ll make. This support trap is even more terrible because you usually won’t realize it’s hurting you until it’s too late. (It’s a well know, dirty secret of this type of software that it doesn’t really want users, it wants money. But that’s a discussion for another time.)

So what is it that enterprise software can do with this? The problem with a service as a middle-man strategy is that vendors would have to change their perspective from being the one-stop-shop to being
maintainers of entire ecosystems built around their product. This idea is always thrown out there (hence the whole VAR and partner industry), but enterprise vendors don’t seem particularly adept at applying it: like Tony said, “you want me to take it out of your part of the take?”

All value creation is locked in the company, and extra-company developers can’t easily create new ways of using your software. Essentially, you’re leaving a lot of innovation (in the sense of “new software we could sell”) on the table.

Fat and Happy, Slow and Dumb

The problem is that once you build yourself into a one stop shop, you start getting fat and happy. And after getting fat and happy, you start getting dumb. And the next thing you know, you’re loosing money like blood from an axe to the head.

Building up an ecosystem of partners, sub-vendors, and customers can keep you from getting in this slow and dumb state. Everyone says things are speeding up now-a-days: there’s so many moves in the market, so much information, blah, blah, that you just can’t keep up! From my perspective, it’s not stuff is speeding up, it’s that all these people complaining have gotten slow, and the little dudes at the bottom finally have a way to get a dog into the big-time fights.

This of course, is the old disruption angle. While it’s getting tired to hear, it’s getting even more tiring to see how slowly large vendors respond to it.

So, if you believe the idea the threat of disruption, my suggestion is that you move your mind set from defending the chasm to building toll bridges across the it: instead of preventing others from profiting from your innovations and technologies, help them profit from them, and take a cut. The quickest way to provide that help is to simplify your systems, making it easier for other to latch onto the functionality the systems provide; that is, to make your system into a service that other layer on top of.

The Half-baked Part

The half-baked part of all this is that there isn’t really a know, effective way, to convert a company from fat-and-happy to outgoing-and-smart. So far, it seems like the only way to make money/survive in software with this type of strategy is to sell to Yahoo! or run your company so small that making gobs of cash doesn’t matter.

The Paradox of Success

That’s the Paradox of Success for enterprise software: the more successful (money) they get, the bigger they get, the more it costs to sustain them, and the harder it become to do something different, to change, because the risk of disrupting that sustaining revenue is huge. Change is a bad word at large companies, sometimes even a taboo.

The hard part of finding examples of large companies adopting ecosystems is that it’s easy to repackage old technology in new boxes. Marketing can successfully craft the story that a technology has fundamentally changed, when really, it’s just names and packaging that’s switched around. In those cases, it’s only the low-level coders who know the truth: they know they haven’t coded anything different into the systems, it’s all just the same stuff.

So then — aside from the verbosity of all this — the half-baked part is figuring out how to move a large company from the one-stop-shop to an ecosystem’ish based approach. There’s two parts: (1.) how do you sustain the revenue flow to keep feeding the fat-and-happy monkey, and, (2.) how do you change your people’s mindsets fast enough to deliver this type of market and systems that can thrive in it.

Destroy XOR Embrace

On gloomy days, I think the only way it’ll work is to apply The Kinman Doctrine, aka, FtF, that is, “Fire the Fuckers.” On sunnier days, it seems like it’s just a matter of exposing people to the ideas and giving them enough time to absorb and believe them.

It’s the classic fire and brimstone vs. love approach. Too bad the first way always seems to win out.

Tags: biz, ecosystems, enterprise, peopleware, software.