The new King - Service Orientation - would not agree with this: "The items that will contribute to success are those in this list. Not SO, in and of itself"
Why SO is always right (like a customer)? Because SO is the core of the Business (which, BTW, is the customer of IT). I think, this is what Steve Jones means when saying that SOA is the business thing. Another story with the second part of that expression - 'not all customers are always right to you'. This may be read as not every IT is up to the business needs. Things like "Focusing on business goals, values and benefits. Collaborating and building consensus. Track and measure" will be always successful if done in service-oriented manner. With regard to "Many prior efforts at transforming a company fail but not because of the architectural approach nor the technology. I conjecture that the root cause of those failures is often these listed items" - to transform company, there should be a reason at the level of risk of the company existence. In prosper time, such reasons do not appear (acquisition is not always a disaster or destruction for the acquired company; example: Cambridge Partners was bought by Novell but who is managing Novell now? - Cambridge Partners people). Another situation exist during the crisis - disability to transform and do it quickly comes with the high probability of crash. My theory is that Service Orientation at the enterprise level is the survival receipt to the companies during the crisis. Why? I will write about it in my blog. - Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Friday, January 9, 2009 4:52:35 PM Subject: [service-orientated-architecture] Re: IBM's Carter on Selling SOA to the CEO --- In service-orientated- architecture@ yahoogroups. com, "Steve Jones" <jones.steveg@ ...> wrote: > > IMO this is just generic consultancy puff (and I'm a consultant) you > could replace SOA with a "one SAP" strategy or "Outsourcing" and the > steps would remain the same. That's one of the appeals of the list. It seems that often the message is "you've got to change everything when definining an SO architecture" or "there are many things you need to do that you've never done before." IMO, that message overstates the case. Yes, there are some different things. Segregating things in terms of services is somewhat different in most cases. And getting the right level of granularity on them can be a challenge. Beyond that, what's really different? The items that will contribute to success are those in this list. Not SO, in and of itself. Focusing on business goals, values and benefits. Collaborating and building consensus. Track and measure. Those are all necessary to be really successful with any effort. Many prior efforts at transforming a company fail but not because of the architectural approach nor the technology. I conjecture that the root cause of those failures is often these listed items. While you dismiss the list as puffery, based on your book and what you've posted here, I'd offer that these are the items you more or less follow. > Show the CEO the services, get him to tell you where the value is > and then commit to him that he will be able to manage IT in the > same way as the rest of the business. In other words, collaborate with the CEO to identify the business value and the benefits? > The ten points below (IMO) are just how you go through the > implementation once the CEO has given you the go-ahead, they aren't > the thing that gets the CEO interested. Whether the CEO gives the nod at step 0 or after steps 1, 2, 3, etc., they are good items to keep in mind, IMO. -Rob
