Thursday, July 12, 2007

Why SOA is different

I've often said that if SOA is about technology then its another minor IT improvement that won't deliver a fraction of the benefit that the hype promises.

So why do I think that SOA is different from the way most people architect IT solutions and why do I think it will have an impact?

Because simply put I think that SOA is about changing the way people think, its about making them think about Business Services and being focused on business objectives first, and technology objectives second.

OO was a shift because it changed the way people thought away from procedures (processes) towards objects which had both data and behaviour. SOA is a much bigger change than that as it works at the enterprise and business levels and represents what a business does, who they interact with and why these services interact.

SOA is different because it changes the way people think about ITs place in the Business. If it doesn't then its just another developer inspired Silver Bullet which will crash against the rocks of reality.

Simply put, if you attack problems in the same way with new technologies, be it REST or WS-*, then you are a muppet if you expect a better result.

Technorati Tags: ,

4 comments:

biske said...

You're not alone, Steve. I couldn't agree with you more, hence my last response in the SOA Yahoo group...

-Todd

PetrolHead said...

Trouble is most enterprises want you to fit all this new exciting stuff into their existing legacy thinking and systems.

i.e. All the benefit for minimum disruption.

Samisa said...

To add to changing the way people think, there also needs to be a change of mindset in terms of those who implement the architecture, meaning software engineers. They used to think OO, not you got to shift to SOA, where the thinking needs to shift from method calling to message passing.

Matt said...

Interesting - helping to architect SOA solutions for business, I find that more than half my time now advising on how to change a business "design center" to take advantage of SOA. This includes everything from team structure, reporting lines, project management style, best practice funding for SOA and support (supporting a SOA is different it appears)

Actually, that's a question Steve (I get it all the time) - how do we support a SOA?