Joe McKendrick's blog makes a case for starting small in order to learn how to monitor benefits. This way you can see your business becoming more flexible and adaptable. Doing smaller projects that directly target specific business problems may be the best way to go in order to build the case for SOA across the enterprise.
This approach makes sense for a number of reasons. Smaller projects cost less and may fit better within constrained IT budgets. They usually have more achievable goals that can be reached faster. It won't take three years to deploy an empty system that delivers potential but has no data yet to realize that potential. You can work out implementation kinks and business process issues on a much smaller scale. And the lessons you learn will be much less painful than bigger projects if you don't succeed. It should be easier to understand where you went wrong. Big projects have a tendency to evolve in bad ways rather than simply having a single, major obvious mistake.
As Joe points out, the really good news about this approach is that it is win-win: small-scale technologies to fix a business problem while providing scalable, secure and resilient platforms that can form the basis of a tranformation.
One could almost assume that this is intuitively obvious. But I can see where companies could get sucked into the concept of fixing it all at one time.
http://blogs.zdnet.com/service-oriented/?p=903
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment