> Anyone have [.] a differing view?
Well, since you asked :-) > Eliminate 1 or even 2 apps, we will still have 9-20 services to manage independently vs. 5 applications. I would strongly argue against this process for identifying services. It also sounds like it would require rewriting those applications - a big up-front cost without any immediate return. In some previous threads (like http://tech.groups.yahoo.com/group/service-orientated-architecture/message/1 2037) I gave examples of coarse business services which interact with each other using business events. You'd likely find multiple applications and even people working within those services. This style of service granularity and interaction does in fact reduce complexity where possible, compartmentalizing it when necessary. Applications are more of an implementation detail for these kinds of services. Comments? -- Udi Dahan - The Software Simplist From: [email protected] [mailto:[email protected]] On Behalf Of Rob Eamon Sent: 12 January 2009 18:00 To: [email protected] Subject: [service-orientated-architecture] Re: IBM's Carter on Selling SOA to the CEO 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] <mailto:service-orientated-architecture%40yahoogroups.com> , "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] <mailto:service-orientated-architecture%40yahoogroups.com> , "Steve Jones" > > <jones.steveg@> wrote: > >> > >> 2009/1/9 Rob Eamon <reamon@>: > >> > --- In [email protected] <mailto:service-orientated-architecture%40yahoogroups.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. > >> > >> 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 > >> > > >> > > >> > > > > > No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.5/1886 - Release Date: 12/01/2009 07:04
<<image003.jpg>>
<<image004.jpg>>
