It's good to see we seem to agree. Other than taking a services-based approach to segmenting things, what activities beyond the generic list are necessary? Might "SOA failures" be due to omitting some of the generic activities and focusing too much on the SOA-specifis aspects?
-Rob --- In [email protected], "Steve Jones" <jones.ste...@...> wrote: > > 2009/1/9 Rob Eamon <rea...@...>: > > --- In [email protected], "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. > > What I'm saying is that this list is basic consultancy skills that > everyone should have. I'm not arguing they are bad they are far from > it (its what I do), what I'm saying is that they are the generic > skills, not specifically how you sell SOA. Maybe puff is a little > harsh, but these are the things that I see people regularly list out > on a powerpoint deck and without a specific plan of action or more > importantly a specific context they tend to go a bit "beige". > > > > > 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? > > That is a very critical difference, its also the difference that with > something like SAP its about standardisation of the business towards > best practice while SOA helps to identify where that sort of approach > fits the business model. > > > > > 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. > > Again not disagreeing, its just that these aren't SOA specific they > are IT general. The business change piece is one that I tend to focus > on when I'm delivering projects. > > > > > 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. > > Puff was a little harsh I'll admit, but I'm just doing down the skills > that I have. Generic would have been more appropriate. > > > > >> 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 difference if you do it SO rather than non SO though is that you > capture it within a specific conceptual model, that is something that > CEOs tend to like. > > > > >> 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. > > They are good things to keep in mind no matter WHAT you are doing, > they are generic good things. > > Steve > > > > > -Rob > > > > >
