Optimising SOA: the second half
The last post explained the first hurdle to optimising SOA: the disconnect between technology and the business. This post I'll build on that list.
Disconnect number 2: human resources.
Desiging a service requires a wide appreciation of:
- business process besides program flow (retain an appreciation of business need)
- information besides data (retain an appreciation of business need)
- SOA architecture and repositories
Retain an appreciation: (a) of SOA governance and (b) that the service will be part of a bigger SOA portfolio.
You may be fortunate to have the right IT management who have the mandate to keep the dual edged type of focus across both business and technology. This dual focus is a pretty rare thing for those involved in service design and development, so advocacy toward management may be what is needed in order to achieve that dual focus.
Final disconnect: SOA governance - real life versus best practice.
I've mentioned governance already but it stands out as being key to the efficiency of SOA. Services need to be designed and created with strict reference to what already exists. Otherwise we risk duplicating what is already there and losing any potential wins through efficient re-use of a module or service.
Remember, we are talking about much more than source code control here - rather, formal SOA governance looking at the who, what, why and how of service creation and use.
Get agreement on SOA governance as soon as the business need for SOA is clear.
So in summary:
• in your understanding, reconnect business and technology
• ensure the appropriate management roles are fully briefed on their responsibilities within the SOA domain
• build governance in from day 1
Ignoring these disconnects makes for a bumpy ride into SOA and worse, can risk putting your business' entire SOA strategy in jeopardy.
My challenge to you: strive tenaciously for optimal SOA.
Disconnect number 2: human resources.
Desiging a service requires a wide appreciation of:
- business process besides program flow (retain an appreciation of business need)
- information besides data (retain an appreciation of business need)
- SOA architecture and repositories
Retain an appreciation: (a) of SOA governance and (b) that the service will be part of a bigger SOA portfolio.
You may be fortunate to have the right IT management who have the mandate to keep the dual edged type of focus across both business and technology. This dual focus is a pretty rare thing for those involved in service design and development, so advocacy toward management may be what is needed in order to achieve that dual focus.
Final disconnect: SOA governance - real life versus best practice.
I've mentioned governance already but it stands out as being key to the efficiency of SOA. Services need to be designed and created with strict reference to what already exists. Otherwise we risk duplicating what is already there and losing any potential wins through efficient re-use of a module or service.
Remember, we are talking about much more than source code control here - rather, formal SOA governance looking at the who, what, why and how of service creation and use.
Get agreement on SOA governance as soon as the business need for SOA is clear.
So in summary:
• in your understanding, reconnect business and technology
• ensure the appropriate management roles are fully briefed on their responsibilities within the SOA domain
• build governance in from day 1
Ignoring these disconnects makes for a bumpy ride into SOA and worse, can risk putting your business' entire SOA strategy in jeopardy.
My challenge to you: strive tenaciously for optimal SOA.
Comments
Post a Comment