Is it me or is it that companies consider SOA done well to be a significant strategic advantage rather than just a technology delivery.
Steve 2009/1/12 Anne Thomas Manes <[email protected]>: > I also have stories that I am not at libery to share. > > Anne > > On Mon, Jan 12, 2009 at 2:15 PM, Steve Jones <[email protected]> wrote: >> 2009/1/12 Rob Eamon <[email protected]>: >> >>> 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. >> >> Capability != service, a service should manage multiple capabilities. >> >> But yes it could be more complex. Worst presentation I ever saw was >> from a major package vendor who boldly said that they would be >> replacing their current 8 modules in the company with "over 3,000 >> services" and didn't quite understand why the CIO nearly exploded with >> concern. >>> >>> 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? >> >> Yes and I'm talking with the client at the moment to try and get them >> to go public, never easy when someone forgot to agree that at the >> start of the project. >> >> Steve >> >>> >>> -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 >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>> >>> >> >> >
