Martin Fowler once posted a great piece about Service Oriented Ambiguity.
I find that the most common challenge for introducing Service Oriented Architecture (SOA) into an organization is not about the technologies used (although there are challenges there to be sure).
No, the real challenges are people-related: existing culture, power fiefdoms, resistance-to-change, squeezing necessary training into work schedules, ensuring a common vocabulary is established and adopted, achieving the broad dissemination of the conceptual understanding of the core principles of a services based architecture (the benefits as well as the costs), vendor sales teams that over-promise and all too often under-deliver, media pundits that over-hype the concept of SOA, Architecture Astronauts, resource staffing constraints, the reality of urgent business priorities that frequently require the reallocation of team members, maintaining executive sponsorship commitment over the long period necessary to build momentum and achieve demonstratable ROI, and managing expectations (no, SOA will probably not be faster than your hard-coded legacy application).
Some of these are manifestations of funding constraints, but most of this is simply the pain of introducing change into an organization.
So what can you do?
Hitch Your Wagon to the Value Train: Focus on delivering business benefits that have a demonstrated ROI - and that can be performed in iterations that are time-boxed (say 1-3 months, but no more than 4-6 months).
Fail Fast, Learn Early: Mitigate high-level risks as soon as possible. Identify potential performance issues before you have spent any signficant portion of your budget on hardware and vendor software. Get your people to put their hands on the technology you'll be using sooner - and find out what works, what doesn't, and where you need additional training.
1 comment:
'deliver business benefits that have a demonstrated ROI', I'd say mashups are a great start.
Post a Comment