2009/1/14 Anne Thomas Manes <[email protected]>: > 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.
Not to disagree, because I don't hell its the business model of what I work doing! But what we have found is that a business service approach really helps you to identify where you should be REALLY rationalising and where it should be a lower priority. As an example Billing shouldn't just be rationalised it should be switched to a utility. At the other end of the scale there are things that justify multiple systems (e.g. if you have a specific geo-modelling tool for the local specific environment that that is probably justified in Oil exploration). its the Business value of the business service that therefore drives the rationalisation. I don't normally do this but.... I've been working on an SOA driven business rationalisation approach for a while and there is some marketing material and whitepapers http://www.capgemini.com/resources/solution_material/application_portfolio_strategy/ http://www.capgemini.com/resources/thought_leadership/the_move_towards_collaborative_business__from_person_to_people_and_from_systems_to_service/ http://www.capgemini.com/resources/thought_leadership/from_systems_to_service/ http://www.capgemini.com/resources/thought_leadership/outsourcing_the_innovators_secret/ and the Business Service bit is at the heart of how we've been approaching this http://www.capgemini.com/services/outsourcing/applications/solutions/#application-outsourcing-roadmap So I completely and utterly agree with you Anne about a business SOA focused rationalisation programme and how it can work much more effectively than a systems driven one, precisely because it can target the right type of rationalisation in the right place. Steve > > 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 >> >> >
