February 10, 2008   Sign In |  About ebizQ |  Contact Us |  Join ebizQ Gold Club
Ronan Bradley
Ronan Bradley's Roads to SOA
Technology and business perspectives on SOA theory, products and practice from industry visionary Ronan Bradley.

« SOA: One size fits all or different styles | Main | Wachovia and D.C. find success with SOA – along different paths »

July 17, 2006
Three principles for aligning your SOA strategy with business goals

One of the much touted benefits of SOA is that it aligns IT with the business – the concept of a misalignment between IT and business is one that I have always found puzzling: how much is just a cliché and when it is not, how can things have got misaligned in the first place. Clearly cliché or not, it is essential that SOA is seen to address this problem. To do this SOA must be implemented in any given company in a way that reflects the organization’s goals, structure, history and even its corporate culture.

Before telling you what my three principles are, lets go back to the perceived misalignment. As was noted by one blogger I read (unfortunately I can’t remember or find out who), how come nobody ever talks about how to align manufacturing with the business? It would be nonsensical – manufacturing can only exist if it is aligned. Similarly, it would be strange for accounting or finance to become misaligned with business. So how come IT can be misaligned? A few suggestions:

- There is a lack of credibility around IT in business – one measure of this is the number of CIOs without IT backgrounds. We need to accept that this lack of credibility is a reasonable response to a history of well-publicized overambitious and under-delivering projects.

- The IT structures in a corporation can become a power center independent of any business line – a cost center blamed for swallowing huge budgets without generating obvious business return.

- The scale of many IT challenge (particularly when it comes to integration) is often not appreciated by business people who do not understand why what appears straight forward can be hard and very expensive (what could be easier than linking a few databases!).

All of this predates SOA and as I mentioned a while back the NASCIO report made a key observation: one of the key aspects new about SOA was that it was building a justification for what has been best practice in enterprise architecture for a while: a justification targeted at business and hence at overcoming these issues.

Which brings us back to how to align your SOA strategy with business and some general principles that I have found along the way:

1. Adopt an incremental approach to rolling out SOA: Focus on achievable but worthwhile projects which can generate real and understandable benefits (such as NASCIO’s reference to collection of fines by a state agency which yielded rapid and measurable cash benefits). While SOA is all about architecture, don’t over-invest too early unless you are sure of the patience of your backers!

2. Don't attempt to use SOA to change the way the world is: Create your SOA strategy inline with the business organization as it is, not the way you wish it was - even if this makes your life more difficult. There is no point creating a single global registry with strict controls on who can add or amend items if the business is highly devolved and dynamic. Similarly, don't believe that your SOA will remove the complexity inherent within many business processes - it may remove technology complexity, but at the end of the day if the business is complex you will need a SOA that can handle that complexity.

3. The only worthwhile SOA is a pervasive SOA: The strategy has to be broad enough to allow most if not all projects to get going without excessive change-over costs or risks. Your SOA shouldn’t force major changes in infrastructure, otherwise the disruption could make the project too risky or the cost too high. Your SOA should be scalable down to the smallest projects in a meaningful way. If there are types of projects which can't be handled because they are too big or too small or too legacy focused or whatever, it will undermine the entire SOA program. All of whcih means that the technology platform(s) has to be plug-and-play to allow capabilities to be deployed where needed and stripped out for the projects which need a simpler solution.

Posted by rbradley in SOA concepts |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/498

Comments Post a comment




Remember Me?

(you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code:



Most Recent ebizQ Blog Entries
ADVERTISEMENT
RSS Subscription
Subscribe to feed
Blog Roll
This Work
Accountability:The opinions expressed in this blog are solely representative of the blog's author, and not of ebizQ

Subscribe to our Newsletters
ebizQ Weekly Gold Club Update
Live Webinar Updates
Updates from ebizQ Partners
ebizQ SOA Update
ebizQ BPM Update
ebizQ Security Update
ebizQ BI Update
ebizQ Open Source Software Update
Virtual Show Newsletter
Your E-mail Address:
BAM: The Killer App for CEP
Date: Feb 12, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Event Processing Market Pulse
Date: Feb 14, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Archived Webinars | Upcoming Webinars

Marketing Solutions | Feedback | About ebizQ | Unsubscribe | Privacy Policy | Site Map