If you want to learn and discuss about competitive strategy, my friend Marco has started a very interesting blog on the subject. As an expert manager and consultant, Marco collects is thoughts and discuss books and articles about strategic management. Sometime we need to stop, exit from day by day activities and think out of the box to evaluate whether we are following a strategic path or just following short-term tactics.
Somebody once wrote: Strategy without tactic is a dream. Tactic without strategy is a nightmare.
Showing posts with label strategy. Show all posts
Showing posts with label strategy. Show all posts
Friday, December 11, 2009
Friday, February 29, 2008
You Can't Buy SOA Governance
Customers and software vendors have now a brand new keyword: SOA Governance! That is, if you listen to vendors, about the set of practices and (mainly!) products which help the enterprise to manage complex ecosystem of technical and business services, with their related meta-data. You can have a look at this Wikipedia definition for a concise definition of SOA-Governance.
That sounds good, isn't it? But usually when I listen to both customers and software vendors I find their ideas about governance quite misleading. Few points of mine:
1. SOA governance is about a conceptual organizational and operational framework which aims to align IT governance with business analysis procedures: people first, then technicalities.
2. You can't buy SOA, you can't buy SOA Governance. It is an organizational process, if you don't change the way you operate your IT projects you cannot achieve neither SOA nor any governance;
3. You need to build a set of SOA practices together with a governance strategy, and the human factor here is more important than any possible product: there is no magical SOA-in-a-box product.
4. You can't have a SOA without governance, you can't build a SOA governance strategy without an established service-oriented analysis process (because you end having nothing to govern...)
IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word.
That sounds good, isn't it? But usually when I listen to both customers and software vendors I find their ideas about governance quite misleading. Few points of mine:
1. SOA governance is about a conceptual organizational and operational framework which aims to align IT governance with business analysis procedures: people first, then technicalities.
2. You can't buy SOA, you can't buy SOA Governance. It is an organizational process, if you don't change the way you operate your IT projects you cannot achieve neither SOA nor any governance;
3. You need to build a set of SOA practices together with a governance strategy, and the human factor here is more important than any possible product: there is no magical SOA-in-a-box product.
4. You can't have a SOA without governance, you can't build a SOA governance strategy without an established service-oriented analysis process (because you end having nothing to govern...)
IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word.
Saturday, January 6, 2007
Books: Enterprise SOA Adoption Strategies
Steve Jones, currently a CTO at Capgemini for SOA strategies, wrote this very interesting little book that fills a gap in the IT literature. The term SOA, which stands for Service Oriented Architecture, is a bit of an overused buzzword these days. SOA has to do much more with the business side of an enterprise than with the technological one, while most books focus their attention too much on technical aspects. The target of a SOA strategy, as Steve's book explain very well, is to "deliver IT to the business". This should sound very obvious, shouldn't it? In my experience many technology departments were nowadays being transformed into playgrounds for software programmers and mediocre IT managers instead. A SOA strategy must reinstate IT into its necessary form within the enterprise, which is to be business-driven.
Steve's book explain very well an analysis approach to model a SOA starting from main business functions, down to a decomposition to technical services. The key to a Service Oriented Architecture? As he wrote: "It's the Service, Stupid!". So the second important concept you will understand reading his book is another very often missed point:
SOA must be business-driven and not technology-driven
Steve's book explain very well an analysis approach to model a SOA starting from main business functions, down to a decomposition to technical services. The key to a Service Oriented Architecture? As he wrote: "It's the Service, Stupid!". So the second important concept you will understand reading his book is another very often missed point:
Subscribe to:
Posts (Atom)