Robert McIllree is busy expressing his thoughts on the difficulties that practitioners of the discipline of enterprise architecture fac …...

Time rolls onward. Ruby and RoR are now in the same position as Java was. Sure, it’s pretty slick but it’s hard to get working well with Apache: (see http://duncandavidson.com/essay/2005/12/railsdeployment)
And how do I talk to CICS with it? Are you sure everything works just as the docs say? What if I have to spend a week working around a bug?

The thing is, you and McIlree are both right (even though he sounds like an arsehole). Many apps need to be out the door quickly and suit lightweight tools and an agile approach. Other apps require compliance with obscure regulations, have to talk to oddball legacy systems and still have to keep working round the clock. These are more suited to heavy tools and a beauracratic development process. Why can’t people admit that there is more than one approach?

One view, coming from the IT area, is that the ideal model for IT is SOA, providing what we call an “enterprise service bus” hosting Web Services that can be called from any client application that needs them. The model makes sense in our environment because we have many mission-critical legacy applications that don’t lend themselves to integration with contemporary development tools. The service bus also provides the “ilities” for the back-end environment, so that business-facing apps need not be as concerned with issues of scalability, performance, and security as they otherwise would. The idea is that (ideally) most business apps could be build by orchestrating service calls and providing a nice UI, with relatively little custom logic needed. All this would be funded from the base IT budget and would be cost-justified on the basis of long-term savings in operating costs – and that’s the key to the disagreement.

The business side of the house is looking for quick time-to-market of small, vertical apps to help them meet short-term market opportunities. These projects are funded directly by business units and cost-justified on immediate impact to the bottom line. They don’t see how it benefits them to contribute to the cost of building the enterprise service bus.

We can deploy an agile development team to a business unit to create a solution quickly. We could do the same if that team could orchestrate back-end services, too. But the challenge is to get the business people on board with the long-term cost savings of the SOA model.

So both camps are really seeking the same thing – a reliable way to deliver business value.

The hardest thing I ever learned is when I don’t want someone’s money.

My general guideline as a hiring manager is that if you don’t have at least one or two “non mainstream” languages on your resume and have reasonable proficiency with them, then I’m not interested. A resume of C, C++, Java, VB, etc. demonstrates a distinct lack of diversity and more likely a lack of curiosity.

Smalltalk and Lisp aren’t dead, though they’re rumored to smell funny. I don’t know about deployment within “enterprises”, but I can think of several startups using one or the other.

Using languages like Smalltalk and Lisp is a great way to attract highly skilled programmers. It’s incompatible with the way large organizations seem to run projects, but highly compatible with getting stuff done quickly.

Lloyd’s quote is the one I was going to quote as well.

Not all problems are knowable. Until you accept this perspective, you will continually pursue the perfect to the deficit of the good.

Speaking of death stars and their sympathizers, I’ve been enjoying Chris Petrilli’s meticulous deconstruction of the arguments. He takes Robert…...