Why You Should Attend RubyRx

I attend a lot of conferences as a speaker, covering Java, .NET, Ruby, and Agility (plus a few other random topics). The most obvious differences between all these conferences are the technical topics, but other surprising differences exist as well. One of the most striking is the presentation style and content of the Ruby conferences. The quality of the presentations at Ruby conferences is nothing short of stunning. They tend to have not only fascinating topics, but really compelling presentation skills. It's as if everyone at Ruby conference have read and internalized Presentation Zen by Garr Reynolds. No bullets in sight, lots of images, cool transitions, and just generally entertaining. It helps that virtually everyone at Ruby conferences use Macs, and therefore Keynote, which is light years ahead of PowerPoint. Keynote alone won't make a great presentation, but it certainly helps.

Not surprisingly, the worst conferences are those that force the speakers to use hideous conference-themed slide decks. Some conferences force you to create your presentation using a hideous template, then have some clueless intern enforce their misguided rules (up to the point of making changes to the slide show). The worst by far is Microsoft's TechEd. First, you must use PowerPoint (not too surprising, I guess). But last year I took a lot of time making slides with lots of images, centered text, and other transition tricks...only to have them disappear before my talk at the hands of someone who didn't have a clue. They literally took slides upon which I had big, centered text to emphasize a point and changed them to a slide with a made-up title and a single bullet point. This ham-handed treatment of my material is why I'm not doing TechEd this year.

But I digress. Ruby conferences on average have stellar presentations. And the RubyRx conference in Raleigh in late February sounds like it's going to be the exemplar of outstanding talks. It combines the expertise of the No Fluff, Just Stuff conference organization with a great lineup of speakers, including Matthew Bass, David Bock, Chad Fowler, Stuart Halloway (talking about Clojure!), Yehuda Katz, Russ Olsen, Jared Richarson, Venkat Subramaniam, Bruce Tate, and Glenn Vanderburg. And I'm going to be there too, like a kid at the adults table.

RubyRx sounds like it's going to be the great early 2009 Ruby conference. Come see what the fuss is about, both technologically and presentationally.

Upcoming Keynote: Smithying in the 21st Century

I have two keynotes that I'm giving at various conferences this year. The first out of the gate was On the Lam from the Furniture Police, which I debutted at the Code Freeze conference in Minneapolis -- I'll have more to say about this keynote in a future blog post when it's about to appear again.

Smithying in the 21st Century comes next. I love metaphorical titles, and this one harks back to the changes in the blacksmith profession just after the turn of the century (in this case, the 20th one). If you were a blacksmith 1890, you had a terrific career path. However, once automobiles came along, the profession gradually diminished to a shadow of what it was.

Here's the abstract:

Blacksmiths in 1900 and PowerBuilder developers in 1996 have something in common: they thought their job was safe forever. Yet circumstances proved them wrong. One of the nagging concerns for developers is how do you predict the Next Big Thing, preferably before you find yourself dinosaurized. This keynote discusses why people are bad at predicting the future, and why picking the Next Big Thing is hard. Then, it foolishly does just that: tries to predict the future. I also provide some guidelines on how to polish your crystal ball, giving you tools to help ferret out upcoming trends. Don't get caught by the rising tide of the next major coolness: nothing's sadder than an unemployed farrier watching cars drive by.

I'm debutting some form of this one twice in 1 day! I'll give a short version of this keynote at the International Association of Software Architect's ITArc Atlanta Regional Conference as 1/2 of the opening keynote on Friday morning. Then, I get on a plane and fly to Milwaukee, where I'm scheduled to give the first real version of it as part of No Fluff, Just Stuff Greater Wisconsin Software Symposium. The research has been a blast, and I'm looking forward to putting it in front of people. There should be some interesting surprises lurking...

Standards Based vs. Standardized (SOA & the Tarpit of Irrelevancy)

This is the second in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. The first installment is here.

Back in the very early days of Java web development, interacting with the tools sucked. Every servlet engine vendor had their own deployment scenario, and they varied wildly between vendors. I worked on several projects where we moved a web application from one dysfunctional servlet engine to another (this was in the early days, and they all sucked in one way or another). Then, the J2EE standard came along, including the WAR file format. Suddenly, you had a fighting chance (well, after a few iterations of the standard) of deploying to multiple application servers (notice how "servlet engine" became "application server"). And the vendors hated that.

They hated it because the J2EE standard turned their application servers into commodities. And the price of commodity software quickly approaches zero. That's why the application server vendors immediately started building more elaborate stuff on top of J2EE: portlet engines, content management, elaborate load balancers, etc. They knew that something like JBoss would come along and support the J2EE standard, making it impossible to charge $17,000 per CPU to deploy their application server (this number sticks out because one of my clients in the early 2000's paid WebLogic exactly that...for 8 CPUs). The J2EE standard essentially ran the server vendors out of the business of supplying just an application server.

Contrast that with database vendors. They are still able to charge big bucks for their servers, and keep companies (sorry, Enterprises) on the upgrade treadmill. An ANSI standard for SQL exists but (and this is the key part) it is so weak that it's useless. When last I checked, the ANSI standard for SQL didn't even include indexes, and no one would reasonably deploy a database server without indexing. The database vendors dodged the commoditization bullet by ensuring that the SQL standard would remain toothless in perpetuity.

Now, let's apply this to Enterprise Service Buses. One of the bits of marketing mantra touted by all the vendors of these Rube Goldberg machines is "standards". And they're selling these things into Java shops accustomed to the J2EE standard, so companies equate "standards" to "works the same across all players". All these shops are thinking of standards under the J2EE light, not the database server light. But here's the rub:

 ESBs are standards-based but not standardized.

This distinction is important. All the extant ESBs use standards in every nook and cranny, but it's all held together by highly proprietary glue. The glue shows up in the administration tools, the way their BPEL designer works (along with their custom BPEL meta-data), how you configure the thing, how you handle routing, etc. The list goes on and on. These vendors will never allow the kind of standardization imposed by Sun in J2EE. The last thing the vendors want is to see their (crazy money making) babies turned into commodity software again. They'll make noise about creating a true standard, but it won't happen. They want to be more like the database vendors, not the application server vendors.

Even the open source offerings in the ESB space suffer a little from this because they are giving the bits away and selling consulting and training. This is a good business model (look what it's done for JBoss), but they have the same motivation to keep you locked into their version of proprietary glue.

Having proprietary glue is not necessarily a bad thing. It's one of the factors you have to consider anytime you are thinking about turning part of your infrastructure over to a externally developed piece of software. Obviously, no one is going to build their own database server -- it makes good sense to buy an existing one, and fight the nasty battle if and when it comes time to move to another one. BUT, you need to understand the distinction between standards-based and standardized so that you don't buy yourself into a real long term nightmare.

Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)

This is the first in a series of blog posts where I discuss what I see wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors. The first installment is about how the need for SOA arose: tactics vs. strategy.

No company starts out as an Enterprise, they all start as a company, with just a few employees. As such, their IT needs are small, handled by a small group of developers who can chat with each other over lunch about what's going on in the IT "department". As the business needs software, they have some process to get the requirements to the developers, and they write code. Thus, the accounting department comes to the developers and says "Here are our requirements for our new accounting application", and the developers build some version of it. Inside that application are some small parts of something that the entire company cares about, for example, some of the aspects of customers. Meanwhile, the marketing department comes to the developers and says "We need an application, and here are the requirements", and the developers build it. Of course, this application also encapsulates some aspects of a Customer (not the same as accounting, but possibly with some overlap). It is rare indeed that anyone looks around and tries to come up with a comprehensive strategy for application interoperability: you don't have time for that -- you're a small company, and if you don't get your software, you'll go out of business. This goes on for a while.

Then, one day, you wake up, and you're an Enterprise. The CIO looks around with dismay at all the actual entities the corporation cares about because they are scattered in bits and pieces in all these different siloed and packaged applications. And the database stuff is a mess, with shared tables and views and ETL jobs running on cron jobs. And the CIO throws up in his mouth, just a little. The CIO looks at the landscape, and realizes that the technical debt incurred over the last few years can only get worse from here, so he calls out "Help." Big software vendors are highly attuned to people in big companies (sorry, Enterprises) who can write checks saying "Help". They ride in with a solution wrapped around the SOA moniker. More about our friends the Enterprise vendors in a future part of the series.

What I'm concerned about in this post is the overall landscape, which is another way of asking "How did you get where you are now?" You got here because of 2 reasons: first, you took the path of least resistance when you were a company (before you became an Enterprise) because, if you had taken the time to build a comprehensive strategy, you'd have never survived as a company. Second, and more important, what is strategic to the business is always tactical to IT. Business people can go into a conference room and change the entire direction of the company in 2 hours. Or, the business may decide to merge with another company that has truly dysfunctional IT, but other business concerns override that. IT can never move as fast as the business, with means that IT always has to respond tactically to the decisions and initiatives brought forth from the business. No matter how much effort you put into a comprehensive, beautiful, well-designed enterprise architecture, it'll be blown out of the water the first time the business makes a decision unlike the ones that came before. The myth of SOA sold by the big vendors is that you can create this massively strategic cathedral of enterprise architecture, but it always falls down in the real world because the COO (and CEO) can override the CIO (and his sidekick, the CTO). If you can convince your organization to allow IT to set the strategy for what capabilities the business will have long-term, you should. However, your more agile competitors are going to eat your lunch while you build your cathedral.

Any enterprise strategy you implement must realize that you will always be in tactical mode in IT because the business strategy doesn't require physical labor. Any enterprise architecture you develop must allow the business to evolve according to it's wants (and needs). This is what my colleague Jim Webber calls "Guerrilla SOA" and what I call "Evolutionary SOA". More about the details ofp evolutionary SOA in upcoming installments.