Reality disrupting SOA sales effort

I’ve had conversations about the practicalities of SOA with various people over the past couple of years, and the gulf between what we expressed in relatively private forums and the public pronouncements was striking. It was apparent to most of us that the pre-requisites for successful SOA were significant, and unlikely to be present in any organisation we had ever encountered. It was also clear that there were huge challenges in delivering adequate quality of service from SOA-based systems.

For whatever reason, people seemed reluctant to express these concerns in public. Perhaps they didn’t want to kill the goose that might lay the golden eggs, or perhaps they just didn’t want to be seen to be out of step with the rest of the industry. Something seems to have changed, and the first items of dissent are appearing. The lead article in “Information Age”, March 2007 issue (not yet online - I’ll edit and insert the link when available), is called “Structural Hazard - The Pitfalls of Service Oriented Architecture” . The article discusses the difficulties of governance, infrastructure and culture, as well as the potential SOA has to make the organisation’s IT even more complicated, rather than simpler. Steve Jones, in his Service Architecture blog, points out the implications SOA has for availability, and also notes the potential for complexity. There are other examples - Googling for “SOA pitfalls” gives 691000 hits.

I don’t know what has prompted the new realism (perhaps people realised that the goose didn’t appear to be laying any golden eggs), but it can only be a good thing and will likely lead to a healthier relationship between the IT industry and its customers.

What's wrong with process?

Ivar Jacobsen makes some interesting comments about the value of process in a recent article on the Dr. Dobbs site. He is obviously setting himself up to introduce his new ‘Essential Unified Process‘ as the answer to the issues he raises in the next article in the series, but many of his points are nonetheless valid.

Of course, process blindly applied is unlikely to be useful, and process without underlying understanding of engineering good practice is of equally dubious value. Which is why my three priorities for my teams’ learning and development this year are:

• RUP - as a process framework, backed up by practitioners who understand how to use RMC to produce a process and a set of guidance that is sensible for the project


• UML - as a common language that allows communication between elements of the team with the minimum possible ambiguity and maximum clarity


• Construction - good practice as embodied in Code Complete, Steve McConnell’s seminal book on the skills, tactics and techniques needed to build quality software

All three elements, applied with intelligence and with the benefit of experience, need to be present to deliver a successful project. Oh, and a bit of luck too.

Hardware and Productivity

Developers working with modern IDEs like Eclipse, Team Studio or Netbeans need all the screen space that they can get. Martin Fowler points out the value of larger screens in his ‘Big Screen’ blog article, and states that his $700 investment in a pair of Samsung 204Bs could easily be cost justified.

In fact it gets easier by the day as Pricerunner tells me that today he would only need to pay just over $600. Unfortunately this translates to £600 in the UK :-(, but the Samsungs are high-end kit so if you were prepared to slip your standards a bit a 20″, 1650×1050 widescreen TFT could be yours for less than £150. You know it makes sense.

While I’m on the subject of hardware, when I began my IT career a gigabyte of disk storage cost about 10 times the annual salary of a junior programmer (as I was then). Today, the cost of a gigabyte of disk is roughly a minute of a junior programmer’s salary, leading to the conclusion that the storage for our 50MB Outlook Inbox is worth three seconds of their time. Perhaps it is time to revisit the cost/benefit assessment for that particular limitation…

Open Source Quality

It has always been said that the openness of open source led to higher quality code, because there were more pairs of eyes looking over the code, and because if they found a problem they could fix it rather than having a depressing conversation with first line support.

As far as I know, there has not been much actual research to prove this point, it has been more like an article of faith for the Open Source community. But the Register reports that Fortify Software (which uses Fortify SCA tools and Findbugs to look for defects in software – as a service) are finding some very low defect rates in popular OSS applications. You can see the results at the Open Review pages.

The relevance for us as developers, apart from confirmation that using OSS does not necessarily represent a technical risk, is that the principles espoused in Builder.com’s 10 Commandments of Ego-lesss Programming really do lead to higher quality. For what is OSS if it isn’t a comprehensive implementation of those commandments?