IT Doesn’t Support Services
August 12th, 2006 by Lou
In Is IT Scared of SOA?, regarding IT shops ‘afraid of SaaS’, Dave Linthicum discusses the fear in traditional IT ranks to SOA and SaaS. Although it correctly points to shortcomings in explaining the value proposition of SOA, this is only half the story.
The darker flip-side to this situation is that IT departments are well aware of what SOA entails, and they don’t like it. Why should IT be involved in even understanding what services are provided by their servers and data centers, when in their painful experience, they must constrain objectives to managing servers and infrastructure?
It’s not due, solely at least, to a lack of interest in the benefits, it’s due to a lack of political and organizational authority, respect and power to move beyond this position and capability, even if they knew how. These guys also understand who gets called when things break, and its not the architect that works for the business unit or vendor.
The inability to manage services not servers is a business problem thrust upon most IT organizations, not an issue easily solved by these organizations in a vacuum. They are caught in the middle.
Success in SOA implementations requires not only an understanding of the value proposition, it requires that vendors figure out how to facilitate resolution of the business, application and data center stakeholder responsibilities and objectives for SOA. It requires much higher IT service management and architectural governance capabilities than most organizations are ready to confront.
This is not surprising or new. For example, success with identity management implementations in many cases hinges on enabling organizations to grapple with the organizational issues around policy based security and authorization. For identity management, like SOA and SaaS, this is an issue that reaches way beyond the technical implementation and the vendor supplied ’solution’.
identity management, it architecture, it goverance, saas, soa
I went to this address to find out what SOA and extensible mean - although I had a good idea once I read your article: webservices.xml.com/pub/a/ws/2003/09/30/soa.html.
The first problem we had at NRC with IT regarding this issue was the very definition of IT ‘architecture.’ We managers didn’t know what it was or why it was important or why it was our job to figure it out. So, naturally, we blamed it on the IT people since they were the ones who delivered the message.
As we found out painfully, most managers don’t know what they want in an SOA because they don’t know how to describe it to the IT types. As you know, IT types are not very much into counseling non-IT managers in the art of translating ITspeak into bureaucratese. Most non-IT Managers in my experience were barely able to get past: “Show me something and I’ll tell you if I like it.” This method, which is tried and true in the Fed. government is one of the reasons why all Government IT contracts run over budget and exceed the time allotted for completion leading to the current size of the National Debt,in my opinion.