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 >> >> > >> >> > >> >> >> > >> > >> > >
