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
<<image001.jpg>>
<<image002.jpg>>
