This is where the time isn't spent to get a clear business service architecture and get the business bought into the approach and where IT doesn't have the confidence, or maybe the ability, to effectively negotiate with the business.
Effect
The effect is that the service definitions are changed on a regular basis, sometimes its just about a data field, sometimes a new capability and occasionally a complete re-writing of the service interfaces. Every meeting that happens results in changes at the interface and service level and the leads to a fracturing of the overall architecture around business silos. Eventually the whole SOA programme is canned because its become too complex to maintain and isn't delivering any benefits.
Cause
The Cause here is IT going it alone and defining a strawman and, unlike IT2B, not having the knowledge or confidence to enforce or structurally modify it. In IT2B the issue is the IT department thinking it knows best, here the issue is the IT department thinking it knows nothing and therefore must always say yes. Often this is driven by a lack of good communicators in IT and through a view from the business of IT as purely an "order taker" rather than a partner.
Resolution
Organisations that have this problem need to drive SOA as a cross-boundary business programme with IT providing support. IT need to invest in highly skilled communicators who can work with the business as partners and help bring together the differing perspectives. At the heart of this issue is one of confidence, communication and ownership, the solution is to make the business the owner and invest in the communication and confidence side of IT.
Technorati Tags: SOA, Service Architecture
No comments:
Post a Comment