Companies that Need SOA the Most Are Least Likely to Implement It

My eyes were drawn today to an ITBusinessEdge post "Companies that Need SOA the Most Are Least Likely to Implement It". How could I resist that title? (That reminds me of a previous post of mine "Naming Well, an Essential Skill of an I/T Architect" but I degress.) That post in turn drove to yet another cleverly named post

Is SOA success in the genes? by ZDNet's Joe McKendrick -- Todd Biske recently responded to my post about Microsoft's recommended approach to SOA (inch by inch, it's a cinch; mile by mile, its a trial), and ponders whether some organizations can get SOA right away, but others will never get it. How do organizations end up with their IT out of synch with business [...]

The basic premise here is worth entertaining. Companies that already have good alignment of I/T and business, already have good governance in place, already think proactively and strategically about I/T, etc. will find moving to a Service Oriented Architecture just the next incremental step in their improvement process. For the other companies out there (the vast majority?), the gap between where they are today and SOA is an insurmountable chasm that they dare not even try to cross.

I think there is an element of truth. I've seen a lot of situations where a company could benefit from new approaches but because they organize a bunch of independently funded, tactical projects no one project can fund the leap to the next level of maturity and flexibility. (See also "The Scourge of the I/T Architect's Universe".) Just a couple of weeks ago an acquanitance of mine at a major manufacturer told me he was interested in using SOA software products for their EAI-like-middleware value but he didn't think his organization was ready to embrace SOA yet. I guess this is like "flying under the radar" to wait until the political situation is more receptive to SOA.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Halloween Horror Stories for I/T

Out of the many emails I get from the various online trade rags, one jumped out at me from my inbasket the other day. The email pointed me to one article with a title inspired by the upcoming Halloween season: 25 Terrifying Information Technology Horror Stories. There's even a great video clip from an old black and white horror movie, "The Brain that Wouldn't Die".

I won't say I've read through all of the horror stories but from what I can tell, the lessons learned are worth a visit by any serious I/T Architect, project manager, CTO, CIO, and anyone else who doesn't want to be pointed out to the whole world as an example of how NOT to execute an important project.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Living on the Bleeding Edge for Fun and Profit

Check out What is Bleeding Edge? by Elana Varon

"Let’s start by acknowledging that bleeding-edge has negative connotations for a lot of people. Just think for a minute about the imagery. Bleeding edge evokes danger. ....Engage in that battle, and you might survive, but you’ll get bloodied in the process. ....But my conversation with a couple of IT executives has me thinking about an alternative vision for the bleeding edge.....until you start messing around with new stuff, you can’t answer the question about whether it might provide a competitive advantage or suggest a new business model.....The implication here is that even a company that is uncomfortable adopting a new technology until someone else works out the bugs can’t really afford to wait to check it out. The bleeding-edge might be your competitive edge. And it starts to look smart, rather than dangerous."