Some may think I’m being unhelpfully mean with my criticism of Mr. McGovern’s post. So, let’s try a different approach. Using the same basic content that James put together, I’ll demonstrate the difference between leading and following. I’ll indicate where I feel that I deviated from James’ content with italics.
How do we get Ruby into the Enterprise.

I’m a fan of Ruby, and an Enterprise Architect, and I’ve given some thought as to how Ruby might become important in the Enterprise architecture space.

First, the problems:

• Enterprise architects are, by and large, a conservative bunch
• Fortune 500 Enterprises are more focused on legal transparency than performance.
• Ruby’s “enterprise infrastructure” is lacking
• Model-Driven Architecture is taking over

Let’s address how we might be able to solve those problems:

Conservative Enterprise Architects

The key here is critical mass – nothing gets done in F500 enterprise architecture w/out lots of tongues wagging. We need one ore more of the following:

• A large hardware vendor to adopt Ruby as a solution. IBM or HP are obvious choices. This is obviously hard, and largely out of our control. The best way to do this is probably to build Ruby up in small and medium enterprises. OVer time, this will help make it more legitimate and more interesting to build solutions around
• Consulting Agencies (Bearingpoint, Wipro, etc) need to develop a Ruby practice. Thoughtworks is already doing this, and while they are small, they have a lot of press. This is an area where continued success will force the big consultants to take notice.
  
• Articles about Ruby in the enterprise need to show up in major magazines. This is probably the easiest one – we know that Ruby has some legs, and magazines like to talk about interesting new things.
• Coverage by analysts. Unfortunately, analysts are the classic lemmings – uninterested in new things, because they don’t like having to argue a position. This won’t happen until one or more of the others do.

Transparency over Performance

I bet you didn’t realize this was true, but yes, Fortune 500 companies are forced by Sarbanes-Oxley and other laws to worry much more about complete business transparency and ethics than they are about raw performance. This is not to say that performance isn’t valuable, but it is just not as important as transparency. And don’t forget, as an enterprise architect, I get several calls a day from people who tell me their product will improve productivity. But a product that could improve transparency? That would be very well received! A transparent enterprise architecture is one where every step is monitored, logged and compared to the last for correctness, where alerts are generated when things change in unexpected ways. Essentially, you need to think of your data as prisoners, and your enterprise architecture as the jail that they are forced to live in. If the data escapes, or it goes somewhere its not supposed to, you’re fired. What does this mean for Ruby? Extensive Security Analysis. Extremely accurate and voluminous logging, and a bunch of other things that I won’t get into here.

Enterprise Infrastructure

If your Ruby server goes down, how is that communicated to the operations team? How about detecting dictionary password attacks? What about integration with SNMP or JMX? Those are the kinds of things that enterprise systems need to support. You need books – on how to make Ruby applications monitorable and traceable, written by people with extensive enterprise experience. You need robust toolsets for integrating with enterprise authentication systems, with enterprise monitoring systems. You need development tools that make the already easy mechanisms for producing code in Ruby even easier.

Model-Driven Architecture

Over time, I’ve become a big fan of MDA, and I think it is the wave of the future. If this comes to pass (and I hope it does), then the traditional metrics of “it’s easy to produce code in language X” no longer really apply. However, I think there are some interesting things about Ruby that might make this easier – especially when you look at Rails – techniques that make Ruby-based MDA more robust and flexible to change than other language choices. I feel very strongly that agile development is on the downswing, and MDA is the wave of the future. But that doesn’t mean Ruby can’t keep up. Because Ruby is a programming language, not a development methodology. You may disagree with me, but that’s fine. I can handle a diversity of opinions on this issue without assuming that everyone else is a sellout.

There.. That’s what a Thought Leader writes.