Gavin Terrill's Blog

Business and IT kissing in a tree

Having IT understand what business' goals and objectives are is a very worthwhile exercise in my experience. Listen carefully, and you stand a chance of actually bringing your knowledge to bear in a valuable fashion. However, the incessant "IT must align with business" meme currently being propagated by the industry pundits (the so-called "thought leaders", highly paid consultants, and analyst firms mostly) is starting to wear thin.

Here is an interesting quote from Julian Brownes' amusing and bang on piece (via comments on InfoQ):

I can't write a strategy that dictates the direction of things that are expensive and hard to change, like tools, platforms, applications, and architecture, based on some business dude telling me that next year we're going to leverage key learnings in our core competencies and maximise customer value by augmenting synergy in the value chain.

I think a lot of what constitutes "doing IT well" is figuring out what to prioritize. There are always so many competing things to be done (every one as important as the next), and never enough resources. Listening to the business helps guide the prioritization process. But the other thing to do is to keep your backyard clean. What I mean by that is not allowing the weeds to run over, as it will invariably slow down your other initiatives. You need the ability to make sound judgment calls. If you can do it right, you can respond nimbly to the latest and greatest business direction change.

It also strikes me that this should work both ways, in a "hands across the water" kind of way. Business can help itself by understanding some of the constraints under which IT must operate, as well as keeping up with the latest creative innovations. Witness the slow adoption of collaborative tools such as Wikis, Blogs etc. in the enterprise. Business is only now waking up to how social networking and associated technologies can help them accomplish their goals, while the technical folks have been using them for years.

One last thing. For me, this reinforces the value of good communication skills. Being an effective listener, and being able to express technical ideas to business people, is sadly a skill that not many people have. If you really want to "align with business", get better at communicating. This has the added benefit of helping you in other ways - think upwards (your boss), downwards (the people who work for you) and sideways (your peers).

Lindaspaces eBook Now Available

I believe the hardcopy is now out of print, so this is pretty sweet - one of the seminal books on the ideas behind Tuplespaces by Nicholas Carriero and David Gelernter is now available online: "How to write parallel programs - a first course". The last edition was written in 1992, but this is still very relevant today.

Reference Architecture circa 2008

Archetype: High availability, scalable enterprise application supporting '000s of users; running on multi-core b0xen.

• Ajaxy ExtJS front-end.
• Client talks REST.
• Request handling via Lift REST - dispatch to business logic via Scala Event Based Actors.
• Lift JPA integration for persistence.
• Comet for push.

How to customize product colors in Shopify

I spent the weekend updating my Shopify backed site so that it now allows customers to choose their preferred flower color.

It involves a fair bit of javascript fu, utilizing cookies and JSON. Here is a write-up on how to provide product customizations for Shopify.

Does documenting your architecture make it high quality?

I just posted a piece to InfoQ on the SEI's new 87 page "Evaluating and improving architectural competence" paper. Towards the end of the report there is a section that discusses principles embodied in the models, expressing that goals should be clearly articulated. One of the examples they used made me chuckle:

Documenting the architecture is likely to lead to high-quality architectures because documentation is essential to effective communication, which is essential to effective understanding and use by the architecture’s stakeholders, which is in turn essential to providing timely and useful feedback.

Don't get me wrong - I love most every aspect of my job, but "documenting the architecture" is not one of my favorite activities by a long shot. Its right up there with filling in timesheets and doing SR&ED claims.

I think part of the problem is figuring out what to document. Most of the stuff I've read suggests spending weeks working through the various architectural views. Obvious guy (aka Heraclitus) says that since change is the only constant, you are taking on a significant maintenance burden in synchronizing the document with the evolving system. Meanwhile, the developers and other architects have filed your treatise in the tl;dr folder.

I agree that "effective communication" is "essential to effective understanding and use by the architecture’s stakeholders", but I'll take providing working code anyday.

Wide Finder, Two.Oh!

Tim Bray started a project last year that attempted to find the fastest way to do string wrangling on log files using Erlang. The idea is to see how languages (like Erlang) that work  well on multi-core machines  compare with more traditional languages; in terms of designing a solution and performance. Pretty soon, Really Smart People were contributing solutions, including those written in languages that are not concurrent savvy per se (e.g. Perl). As it turns out, a Perl implementation kicked Erlang's butt, but the project was somewhat flawed as Tim points out in "Wide Finder 2":

There were a few problems last time. First, the disk wasn’t big enough and the sample data was too small (much smaller than the computer’s memory). Second, I could never get big Java programs to run properly on that system, something locked up and went weird. Finally, when I had trouble compiling other people’s code, I eventually ran out of patience and gave up. One consequence is that no C or C++ candidates ever ran successfully.

This time, we have sample data that’s larger than main memory and we have our own computer, and I’ll be willing to give anyone who’s seriously interested their own account to get on and fine-tune their own code.

What I loved about this the first time around was the discussion around how people approached the problem and their refinement of strategies based on some serious analysis of the bottlenecks. This is kind of geeky, but this is the type of stuff I find fascinating. Tim must have spent a fair bit of time lobbying for the corporate resources needed to get round 2 off the ground, so hat's off to you Tim, and well done Sun for having the foresight to back this project.

Effective Java, Two.Oh!

Cool - just found out that a second edition of Effective Java is being released soon. If I had to recommend one book on Java, this would be it. Apparently, the updated edition is a complete overhaul and not just some tacked on chapters to cover new features since the original edition (I think Java was at version 1.4 maybe?). According to Amazon, new material covered includes "generics, enums, annotations, autoboxing, the for-each loop, varargs, concurrency utilities, and much more". Even though I don't get to code as much as I used to (or would like to), I'm definitely getting this one for the bookshelf, and a few more for the folks at work.

BAUF - Big Architecture Up Front

Bob Warfield has just written how the lead architect of Twitter has bolted, leaving behind speculation that there are deep scalability issues that need to be overcome before Twitter can achieve world domination.

I don't think you can take shortcuts when it comes to doing due diligence on your architecture choices before building a solution. I'm all for the YAGNI mindset and avoiding BDUF when building out feature, but there are some things that are simply not possible to change after the architectural foundations have been set without incurring significant renovation cost.

To make matters worse, it is extraordinarily difficult to get this right as you typically have very little information at your disposal when you are making these key decisions. Other factors such as the talent pool available to work on the project further muddy the waters. You end up making trade-offs based on educated guesses, and relying heavily on your intuition.

Some of the key decisions include:

• Framework choice - you get time to market, but the trade off is losing control of architectural decisions. In a Rails app, your CRUD operations are synchronous, so if one day you read about the CAP theorem and think to yourself this eventual consistency thing might be the way to go you are going to have a tough time.  Language choice implicitly follows your framework choice, and it is almost impossible to change that later. Imagine trying to get an MS Access based product to work in a clustered environment for example.
• Caching & Security. Two things that are expensive and extremely difficult to retrofit.
• Client platform. Will you need rich client or offline functionality? How will it communicate with your web based service? If you build it all loosely coupled and cohesive you may have a shot, but these qualities rarely fall out of a system built using an ad-hoc approach.
• Distributed API. In an SOA world, changing the protocol of an established application is pretty much out of the question. So, you are forced to think about future requirements ahead of time. For example, you can pretty much guarantee you have to deal with clients on different versions of the API. Tip: having an extensible data format helps, as well as  making sure your application protocol utilizes caching extensively.

I've also covered the "Premature Scalaculation" idea on InfoQ - some good comments there.

Jaxtr

Get jaxtr | Login

I'm a twit...

"Twitter-er" that is. I have no idea what this twitter thing is all about, but that's never stopped me from diving in at the deep end before: http://twitter.com/gterrill.

For a desktop client, I'm giving twhirl a whirl - an AIR based app that seems to work very nicely.