20 IT Mistakes

A good article by Chad Dickerson on common IT mistakes.

I especially like these:

19. Violating the KISS principle

Doug Pierce, technical architect at Datavantage, says that violating the KISS (keep it simple, stupid) principle is a systemic problem for IT. Pierce says he has seen “hundreds of millions” of dollars wasted on implementing, failing to implement, or supporting solutions that are too complex for the problem at hand. According to Pierce, although complex technologies such as CORBA and EJB are right for some organizations, many of the organizations using such technologies are introducing unnecessary complexity.

This violation of the KISS principle directly contributes to many instances of project failures, high IT costs, unmaintainable systems, and bloated, low-quality, or insecure software. Pierce offers a quote from Antoine de Saint-Exupery as a philosophical guide for rooting out complexity in IT systems: “You know you’ve achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.”

20. Being a slave to vendor marketing strategies

When it comes to network devices, databases, servers, and many other IT products, terms such as “enterprise” and “workgroup” are bandied about to distinguish products, but often those terms mean little when it comes to performance characteristics.

Quite often a product labeled as a “workgroup” product has more than enough capacity for enterprise use. The low cost of commodity hardware -- particularly when it comes to Intel (Profile, Products, Articles)-based servers -- means that clustering arrays of cheap, workgroup hardware into an enterprise configuration is often more redundant and scalable than buying more expensive enterprise servers, especially when it comes to Web apps.

App Servers No Longer Needed

This is a good blog post from Peter Yared on the evolution of the application server.



I'm in the .NET world where our app server is a bit more of a logical concept than in J2EE, where you might use JBOSS or WebLogic or Websphere. Still, an interesting read.

His take on things is correct I think. We don't need an application server in the middle when all we're doing is throwing XML around from one service endpoint to another. I do, however, think we probably need some sort of manager or broker in the middle to handle things like security, management, etc. This might be an ESB, it might be a SOAP control broker or the like, or something home grown which simply centralizes the services management.

The ESB--Finished Already?

Check out this article on Loosely Coupled.

Phil Wainewright makes an interesting case for why the ESB is an idea that, while new and exciting, might not last forever.

His main point is that the good points of an ESB--extreme loose coupling, standard XML support, message oriented middleware--are hurt by the reliance on yet another large software package an enterprise must install and maintain. The concept he talks about in this latest installment on his weblog is that products like the new Blue Titan Network Director RM will have longer staying power because they bring reliable message-oriented middleware using industry standard Web Services standards. The ESB products all use a proprietary (though sometimes JMS-based) message queing backbone.



Interesting point. I recently made a presentation to a potential client on this topic, and suggested that we spend a bit of time analyzing their business and the needs for a reliable message oriented backbone for their integration needs. They're a mostly-Microsoft shop, but occasionaly do use products from IBM and the like. My initial impressions had been that a good ESB concept was called for, but I was still unsure about using Microsoft's or Sonic's or IBM's products.

This new idea essentially says this--build your backbone on Web Services and the WS-ReliableMessaging standard, and use a product like Blue Titan to manage the entire SOA infrastructure.

Interesting stuff. Definitely the way things are moving, regardless of whether we call it an ESB or a WS-based message based middleware (WSMOM?).

Automating The Build

I've been working an engagement recently with a company doing some large .NET and VB6 development. This company would like to automate its build and deployment processes to relieve pressure on the developers who presently do all of these steps manually.

I can strongly recommend Visual Build.

This tool makes it easy to do all of the little but very detailed steps that take place in a large build and deployment process.



It's got full integration with all of the Microsoft tools, such as Visual Studio.NET, Visual Studio 6.0, Visual Source Safe (yikes), and third-party tools like SourceGear Vault, etc.

Check it out.

How is VSS Still Alive?

Visual SourceSafe, clearly the worst product in the Microsoft catalog and one that keeps biting me every time I run into it.

Right now, before you even take another sip of coffee even, click this link and buy SourceGear Vault. You'll thank me for it later.

On Keeping It Simple

I'm working with a client now in their performance testing of a very large web application.

This application was written in .NET with Microsoft's assistance and they're now using Compuware's QA Load product. It's a well written application and the guys working it are quite sharp.

Some random thoughts here:

1. .NET Remoting is not a good idea. It's a tightly coupled distributed architecture that works only on .NET applications. It's got a big learning curve for developers, and it's very tough to run performance testing tools on it.
2. Use Web Services or (even better) a real information bus instead. ESBs are good stuff here.
3. ASP.NET Session management is a huge performance drag on very busy sites. This site runs on a Unisys ES7000 and it's causing some issues. If you're using it, be very careful with how often you access it. And on those lines--
4. Being as stateless as possible in the web tier is the way to go. Keep it simple, keep things in an encrypted Query String and hit the database if you have to, or use the .NET caching features.
5. I think maybe (and I'm definitely not an infrastructure guy) the path of buying a bunch of cheap machines and running a load balancer in front of them is the way to go. You can do the same thing with your application server tier if you have one. It's cheap, it's very easy to expand, and most of all it makes for a simple architecture.

And The New Phone Is...

The BlackBerry 7100t from TMobile!



I'll try to snap some photos of it later, but a quick word--I love the thing. I used to have the (much larger) 6750 and this phone-sized BlackBerry makes a world of difference. The screen is perfect, the calls and speakerphone are superb, and the typical BlackBerry email quality is great so far.

Recommended.

No November Novel

Looked into it, thought about it, deciding not to do it this year. Just too busy to make it as good as it could be.

Great idea though. In general I like the idea of forced deadlines to create an impetus for doing something. I'll definitely look into it more.