Look at most large enterprise application portfolios. They typically have >500 applications, often >1000. There's a lot of redundancy. And it's this redundancy that makes systems complex and impedes agility. Why does a company need a different billing application for each product that it sells?
Step one in a SOA initiative should be an application rationalization effort. Anne On 1/14/09, Udi Dahan <[email protected]> wrote: > Rob, > > > >> the assumption in the example was that applications were replaced with > services some how, some way > >> [.] > >> The assumption being that each application would be replaced by multiple > services > > > > In my view of business services, applications are NOT necessarily replaced, > but are a part of a business service. > > > > Some applications are problematic in that they contain functionality under > the responsibility of multiple business services. Applications like "the > portal", or "the database", or "the ERP" often fall under that category. > That isn't necessarily terrible, provided they aren't monolithic beasts > which, when if you try to take some functionality out of them and move it > elsewhere, will fight you tooth and nail. > > > > While the refactoring effort may prove to be difficult, the applications > still continue to exist afterwards. > > > >> I contend, however, that typically an SO approach will generally result > >> in more components, and will thus be more complex > > > > Let's take a closer look at what complexity is. On the one hand, we have > these apps which are likely to be monolithic big piles of mud with very high > internal complexity. After performing the SO approach, we may have more > moving parts, yet each is better defined with much lower internal complexity > than before. > > > > If we were to look at the average complexity of the before and after, we see > that it goes down substantially. There are many metrics that can be used to > prove that (cyclomatic complexity, for one), but the KPI we see improving is > the time it takes to make a change or add functionality to the ecosystem. > > > >> But generally we still have more independent components, correct? > > > > Yes. That actually means that more people can work on more parts at the same > time rolling out more business functionality faster. In short, that's a good > thing. > > > > -- > > Udi Dahan - The Software Simplist > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Rob > Eamon > Sent: 13 January 2009 18:49 > To: [email protected] > Subject: [service-orientated-architecture] Re: IBM's Carter on Selling SOA > to the CEO > > > > --- In [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com> , "Udi Dahan" > <thesoftwaresimpl...@...> wrote: >> >> > Anyone have [.] a differing view? >> >> >> >> Well, since you asked :-) > > The exchange of ideas and opinions is the value of these boards! > >> >> > 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. > > The example proposed wasn't intended to promote any particular > service identification approach. Rather, given Anne's thought about > the need for application portfolio reduction or application > rationalizations, the assumption in the example was that applications > were replaced with services some how, some way. And the number of > services listed was simply estimated from the number of applications > being rationalized. The assumption being that each application would > be replaced by multiple services. It was not intended as a commentary > on how the rationalization would occur. > >> In some previous threads (like >> http://tech.groups.yahoo.com/group/service-orientated- > architecture/message/12037) 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. > > "Where possible" makes sense. I contend, however, that typically an > SO approach will generally result in more components, and will thus > be more complex than than the environment it is replacing. It will be > true that particular capabilities are unlikely to exist in multiple > places since one of the usual goals is eliminating redundancy. So > that's good. But generally we still have more independent components, > correct? > > -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: 13/01/2009 > 08:17 > >
