Applied IT vs. Computer Science/Technology

I wonder if one of the root causes of the ever widening gap between the Business and IT are the business schools?

During another vendor demo, two of the presentations specifically covered business processes with workflow definitions along with business rules. Mid-way during the presentation, one of the audience asked, "These tools are typically used by someone from IT, right?"

Without missing a beat, the vendor said, "No, this should be really familiar to anyone who has used Visio to diagram a workflow and the rule definer should be very familiar to anyone who has used Excel macros." Needless to say, that went over like a led zeppelin and the room fell silent. "Don't you have business analysts," asked the vendor? "They are usually the people who do this but, at most of our deployments, the end-users in the business write and test their own rules. Sometimes, they might have the help of a very junior IT person if the logic is particularly complex or chained, though."

Again, more awkward silence. I interjected with, "We actually don't have a job classification of business analyst here but, these responsibilities would probably fall into the domain of a program manager or an operations analyst," whereupon all of the program managers glared at me. As an aside, most of the program managers work in IT!

Of course, my knee-jerk reaction (which I kept to myself!) was the thought of me having to do my job and part of the businesses' job, too! Taking a mental step back, I really wonder if this is fair? I've worked in many different environments and to a large degree, the one tool almost everyone on the business side can use far more efficiently than I can is Excel. I've seen some pretty amazing and impressive spreadsheet macros in my career. However, perhaps the business-people who are capable of these feats of spreadsheet scripting are just as rare in the business as it is to find a good programmer in an off-shore outsourcing company?

In this age of self-service, why aren't business schools teaching their students to exploit common, desktop technology? Not just use, but really exploit and actually design curriculums to require these tools to be used at progressively complex levels. Instead of making them take a programming course, why not focus on some applied technology courses starting in their freshman year where they need to build some fairly complicated financial models involving multiple cases and decisions? The last time I looked at a B-School curriculum (about 2 years ago), this kind of coursework didn't appear in the calendar until until 3rd or 4th year. Back in the paleolithic age, when I was in school, this level of applied technology was usually relegated to MBA students!

Getting back to the demonstration, I had the impression that most of the spreadsheet users in the room were really skilled with the layout tools in a spreadsheet, maybe even knew how to add columns and do some basic cell manipulations but otherwise, were pretty much dead in the water. Am I off-base? I'm certainly not trying to shift the blame, by any means; I'm just as disappointed at the miserable job the majority of IT has done with respect to delivering value to the business (current employer not excepted) but, I'm sure there is a bit of blame to share.

Gartner or Graft

I was recently in a presentation by given by a CRM vendor. At the tail end, one of the members of the audience asked about the recent slippage by the vendor out of Gartner's magic quadrant. The reps were candid, yet resigned. They said that there was a corporate decision to stop paying Gartner money and invest marketing funds, otherwise.

• Pay Gartner, stay in magic quadrant.
• Don't pay Gartner, fall out of magic quadrant.

The reps looked pretty apprehensive so I said, "Don't worry, for those of us who understand exactly how most industry analysts operate, this works in your favor, not against it." To go one step further, the next time a sales rep or marketing droid calls me up and mentions where they are in the magic quadrant, I'll very curtly inform them how little I think of that analysis and what a corresponding waste of money that line item of their marketing budget Gartner payola is.

I have to say that the list of industry analysts and trade publications that I can confidently rely on for information is rapidly dwindling. After the project I am working on is over, I'm going to make a point of working with our CIO to re-visit the funds we allocate to various subscriptions, especially to analyst firms, and make some recommendations.

Enterprise Standard Open Source Software

Between meetings being held in preparation for a week of on-site vendor demos, I caught up on some blog reading. James McGovern replied to my earlier post which triggered another thought. We have evaluated over 2 dozen vendors, did a first round of literature evaluation against our requirements, did a second round of RFIs against our requirements and have arrived at the short-list for demos, next week. I did work with the main technical stakeholder to determine if there are any open source products that could fill all or part of the solution set. Regrettably, there aren't but, at least we did the investigation. The software suites we are investigating will be used as a company-wide standard and will retire several redundant systems which have all outlived their usefulness.

This lead me to think about our open source software use policy and our procurement process. There are several cost-reduction projects underway and a part of each project is trying to standardize software. Naturally, there aren't perfect solutions for every case so, architecture has decided to adopt a preferred choice and second choice ranking. It occurred to me that one more option was missing. If there happened to be 2 commercial options, there should also be an open-source option, too. I modified the asset catalog to look something like this:

Software Domain	Preferred Commercial	Preferred Open-Source	Alternate Commercial	Alternate Open-Source
Application Server	N/A	Tomcat	WebLogic	JBoss

Changing the asset catalog to this format allows both an open-source option to be considered and an open-source option to be the only option for preferred/alternate, if appropriate. Now, if only the federal government would modify the TRM in the FEAF, we taxpayers might be spared some of the tax burden by forcing agencies to consider open-source options.

Industry Analysis We Really Need

The kind of industry analyst the IT industry is in dire need of is something like Underwriter's Laboratories or Consumer Reports. People or an organization that do more than a comparative literature review (I can hire interns to do that!) and actually try out/beat up products in a lab. The analyst would have to be vendor-independent so, in other words, can't receive revenue from a vendor for performing a study or doing an evaluation. Software and hardware would be provided to the analyst on an extended-loan period, determined through negotiation between a vendor and the analyst. If the analyst chooses to receive payments for advertising from vendors, that income must be reported publicly and in an obvious location by a dis-interested third-party. Perhaps the analyst might even be able to work out a strategy with it's clientele to provide temporarily-assigned staff dedicated to performing evaluations?

One-Horse Show vs. A 3-Ring Circus

Either Justin or Stuart blogged about my previous post where I mentioned the need for speed from dynamic languages. I know that for 9/10 web applications, this is true. However, my employer happens to be in that 1/10 category. Regarding my performance requirements, not only do I have to be concerned with throughput and latency, I also need to be concerned with real-time performance. Auctions, markets, exchanges and utilities are all real-time e-commerce business models, some of which deal with perishables. If I was talking about hundreds of requests/second, I could host our apps on PDAs, not blades.

That's why us enterprisey types need to see the landscape a little differently based on the business requirements of our employers. It's a matter of scale. For example, we lose 6-7 figures of gross revenue for every 30 seconds of added latency delivered to the browser. The net of that 30 seconds pays 7 developers' salaries for a year. That kind of money would keep a 2-horse consultancy running for several years, I suspect. In my previous job where I was concerned with the speed of code delivery, a 1 million dollar contract meant I could employ a team of 8 developers for a year. When the scale changes from millions of dollars per year to millions of dollars per minute, that changes the priority of technical requirements. Now, I'm concerned with the speed that code can deliver. At a certain level of deployment for dynamic languages, the efficiency of the VM becomes far more important than the efficiency of the language. Dynamic languages certainly have their place in the enterprise (we use most of them), just not for the majority of our customer-facing applications. Drastically improve the efficiency of the underlying VMs and that picture will change but, not before then.

Why I Can't Take Smalltalk Seriously

Please notice that I wrote can't, not won't! I'm on the technical advisory board for a startup and they are intent on doing everything the right way. When we started to talk about web frameworks, everything was on the whiteboard for discussion: .Net, JSF, Tapestry, PHP, Ruby/Rails, Django, etc. I also mentioned WebObjects and Seaside. That caused a mix of puzzled looks and laughter. On the upside, the architecture we are proposing will allow them to consider Seaside but, this is the exception to the rule.

Meanwhile, back at my day job, I couldn't consider Seaside. We have billions of dollars worth of data and information stored in SQL Server, Oracle and DB2. That's a big, brick wall to hit. I need tools like JDBC, ODBC, JPA, Hibernate, iBatis, multi-threaded connection pools, drivers for each RDBMS (plus MySQL and Postgres would be nice) etc. Yes, I know there's GLORP but please ...

I also need scalability to tens of thousands of simultaneous users. That's also one of the reasons we can't use Ruby/Rails, either. When we need hundreds of servers to run a single application supporting thousands of users, cost of manageability becomes a very important factor. At this level, programmer productivity really counts for nothing. I'm far more interested in lowest cost of operation rather than cost of development. If it takes a dev a month or two longer to code something robust and manageable in Java or .Net, and the application is going to be in production for years, guess what wins? Just add more hardware is no longer a viable strategy when datacenters have been maxed out for both space and power consumption.

If I'm wrong about some points here, please let me know. Although, I did put some fair effort into researching how Smalltalk could meet some of these requirements but, I guess I was using the wrong keywords. Perhaps the Smalltalk community can help me get Smalltalk into at least one enterprise.

One Reason Why Enterprises Don't Like Dynamic Languages

I believe one of the major reasons object-oriented dynamic languages like Smalltalk, Python, Ruby aren't widely used in enterprises is really well outlined on page 3 of this article in e-Week:

"But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java," Kelley said.

"We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy," he said.

Once again, a combination of laziness and CYA win out over the imperative to deliver real business value such as:

... all kinds of productivity and cost benefits, including lower cost of maintenance, better ability to integrate with modern architectures, and the ability to add components and enhancements more easily than with the mainframe, Kelley said.

There is also a great quote about line-coders vs. problem solvers, but I'll leave it up to readers to find that gem. I also have to add that from personal experience, it's a whole lot easier to teach a bunch of mainframe and COBOL programmers Python than it is Java or C#. In fact, it was really just a matter of pointing them in the direction of Python, asking them to use pyUnit and let them run wild. On the other hand, teaching them Java drained tens of thousands of dollars from my operating budget!