Too Much SOA Technology?

I came across Steve Jones’ blog post entitled “Stop with the damn SOA technology.” Steve, you had me at “Stop.” He is commenting on this post by Joe McKendrick, “Is SOA too much for the IT department?”

From Steve’s post:

“The real problem, which is referenced but then sort of glossed over, is that IT needs to be looking well away from the technology and away from the projects and doing two things. Firstly IT should be looking to get the investment to make changes by [economizing] on those parts of the budget that they do control (i.e. support, development and infrastructure of existing systems) and Secondly IT should be looking to do the cheap things that will have the largest impact. This means [organizational] and governance changes and understanding what the business service architecture should be.”

Clearly, the issue we are dealing with is our attempt to do some great things within our firewalls, and avoiding the temptation to just toss technology at the problem. I remember back in the EAI days, when consulting with companies looking to solve their integration problems, those that were successful thought of the technology as a means to execute on a plan, and not the plan itself. The technology is much more effective if leveraged within the proper context.

Indeed, things are not healthy right now when considering most rank-and-file SOA initiatives, as I’m finding. Even the consultants from the larger firms, who should look out for their clients, are getting onboard the “technology first” bandwagon, and spending their billable hours talking about governance tools and ESBs, versus issues that are core and fundamental to the business and current instance of IT. That can’t end well.

“If you think ‘well we can’t make any changes but at least we can use SOA technologies on this project, that will help won’t it?’ then you are deluding yourself.”

I hear you brother.