Good point on the SOA viewed as technology from both you and Steve. I agree.
Regarding the reducing complexity item, I'm not sure I agree there. My opinion is that, even if some applications are eliminated, there will be more moving parts, not fewer. Let's assume that a typical app may have 3-5 major capabilities (I just pulled that out of the air). If we have 5 applications, that's 15-25 major capabilities that are service candidates. Eliminate 1 or even 2 apps, we will still have 9- 20 services to manage independently vs. 5 appliations. Perhaps there may be a reduction in interfaces. We all know a given application is likely to have many, many one-off, purpose-built interfaces. Will the SO approach reduce the number of interfaces to be managed? Probably. Anyone have concrete info on either of these aspects? Or a differing view? -Rob --- In [email protected], "Anne Thomas Manes" <atma...@...> wrote: > > SOA failures result from many things, but the primary culprits are: > > 1. The perception that "SOA" is a middleware technology rather than > an architectural style. If you use SOA technologies (e.g., WS-*, > ESB, HTTP, etc) the same way as you've always used MOM, CORBA, DCE, > etc, then you'll get similar results. (This one is also known as > SOA = Integration or SOA = ESB.) Complexity is what impedes > agility. If you want to make systems more agile, you must reduce > the complexity of the applications architecture. Building new > connections between existing applications increases complexity. The > way to reduce complexity is to reduce system redundancy. Start with > application rationalization. > > 2. The inability to demonstrate value to the business (see point 1) > and thereby gain buy-in from the people that hold the purse strings. > If the business units don't buy-in, they won't be willing to > relinquish their "I'm special" attitude, and they won't be willing to > adopt the shared services mentality. > > Anne > > On Sun, Jan 11, 2009 at 3:31 PM, Rob Eamon <rea...@...> wrote: > > 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.steveg@> wrote: > >> > >> 2009/1/9 Rob Eamon <reamon@>: > >> > --- 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 > >> > > >> > > >> > > > > >
