Archive for the ‘IT Architecture’ Category

SOA is just a tool

Wednesday, May 16th, 2007

Since my last post has clearly ruffled some feathers, I wanted to clarify my position.

I am pro-SOA.  I think it has great possibilities in delivering a more agile enterprise.  But at the end of the day it’s just a tool and one means of getting there.


Farcical SOA Targets

Monday, May 14th, 2007

I am indebted to Joe McKendrick for alerting me to this story providing exciting news that the SOA Consortium is targeting that 75% of the global 1,000 businesses will have made a “successful” SOA implementation by 2010.

It’s this sort of complete nonsense that gives SOA, and IT people in general a bad name.


Rogue IT Survey – can you help?

Monday, May 14th, 2007

If you work in enterprise IT can you help me by completing a short survey?

Click here to go to the survey

A frequent theme on my blog is the ongoing fallout between IT and The Business.  This is often exacerbated by business staff trying to implement their own technology solutions despite IT.

Allan, commenting on my IT vs the business post suggested that the business views IT as “not so much irrelevant as an active hindrance for most (large) organisations”.

Is this driving the rise in so called “Rogue IT” solutions being implemented by business staff?  I want to capture the views from an IT perspective.

Please have your say.  If you want to leave your contact details at the end of the survey (optional) I will send you a copy of the results.  I will also publish them on this blog.

SOA The Economics of Agility

Friday, May 11th, 2007

Marc Rix alerted me to a paper he had written on Bottom Line SOA: The Economics of Agility

I am a big fan of SOA and Marc’s writings and he makes a compelling case for the positive business cost/benefits of SOA over P2P architecture.  However, I feel compelled to make a few points to balance the argument slightly.


SOA – A Good Idea Badly Implemented?

Monday, May 7th, 2007

The second on my short series of posts reflecting on a recent discussion with Clive Longbottom of Quocirca.

We discussed the success (or otherwise) of SOA implementations.  Now, I must be honest, I am not aware of a single shining example of SOA excellence in the enterprise, but I had presumed the reason was the limited range of industries I come across.  For example, most banks, telecoms, utilities, retailers and the like are so monolithic, the cost of embarking on an enterprise wide SOA initiative wouldn’t get past even the most naiive of capital expenditure committees.  So I have read vendors’ press releases about successful SOA implementations and taken them at face value.

Clive’s view, however, stopped me in my tracks.  He reckoned most SOA “experiments” were nothing more than web services connected together in a point to point architecture!  Picture my face with a look of incredulity on it – no I am more incredulous than that!  I may be dumb but isn’t loose coupling the whole point of SOA?


It’s The Enterprise, Stupid!

Tuesday, April 24th, 2007

Once again I find myself in total agreement with Bill Barr in that businesses want Agile Enterprise Architecture, not Agile Enterprise Architecture.  In other words, what the business cares about is having an agile enterprise, not whether you used an agile process to deliver.

That is not to say that agile processes have no merit.  It’s a bit like using PRINCE2*, for example as a project methodology.  It may help the project team, but looking back, no business cares about the how.  They are only interested in what you deliver.


How old is a “Legacy” application?

Monday, April 16th, 2007

What do we mean when we use the term “legacy” application?

Jason Stamper talks about ageing technologies and speculates that even old Java applications could often be considered legacy.

I think we should take a business focussed view of this and I suggest we should ask the following question.

If we re-evaluated, today, would we buy/build this application again?  If the answer is no, then it’s a legacy application.

I have more than a sneaky suspicion that asking the business this direct question would yield some uncomfortable answers.  In fact I would go so far as to suggest that by this definition, many business reps would consider a large number of applications to be “legacy” before they are even live.


Ship Ahoy!

Monday, April 9th, 2007

I’ve only recently discovered Bill Barr’s blog (and added it to my blogroll) and found some really interesting views that I felt compelled to post about.

Firstly at Ivory Tower or Crow’s nest? Bill argues for the need for IT architects to take a high level view without retreating into an ivory tower.  I am pretty convinced that the role of an IT architect is to see the bigger (business) picture and always be looking ahead to prepare the matching and necessary infrastructure.

I am equally convinced that “if we could only convince businesses of the value of having a lookout place high enough to see beyond the next quarter ….” then the job of the IT architect would be much simpler.


Are GUIs Really So Bad?

Monday, April 9th, 2007

Allan Engelhardt is a guy I have worked with and respect a lot.  His knowledge of enterprise IT architecture is way beyond mine and he seems to successfully bridge the gap between IT purity and business need – in other words he is a pragmatist whose focus remains on delivering the end result.

So I found my thoughts provoked by his recent post on The Post GUI Era based on discussion from O’Reilly’s 2007 Emerging Technologies conference.

Now, I wasn’t at the conference but I do think that Allan has barely scratched the surface in this debate.  The theory goes that man wasn’t born understanding GUIs, and more natural interfaces such as speech, for example, are potentially better ways of managing the interface between human beings and technology.


Let’s Legitimise Rogue Behaviour.

Wednesday, March 28th, 2007

In my short time in the blogosphere I’ve noticed a common theme around CIOs, IT Architects and others in the IT community concerned with “Rogue” behaviour.

I say rogue behaviour because some posts refer to rogue users, others to rogue solutions, rogue IT etc.

The common point is that if the IT function does not serve the business with what it needs, then you can absolutely guarantee that some rogue behaviour will emanate from the business.  Usually the IT function doesn’t even know about it, until the rogue solution falls over and the business calls in the IT guys who are suddenly landed with a mission critical “system” to mend and support.

So how do we square the circle here?