Wonder if he factors in the cost of supporting it over the next 5+ years....
But seriously if someone is spending $10m on middleware upfront then that person is a complete and utter idiot. I'm really struggling to think of someone who has _upfront_ spent that much on middleware, hell I'm struggling to think of somewhere that has spent that much in total outside of organisations whose total spend is way over $500m a year on IT alone. Reminds me of a review I did once in Singapore, the client (who shall remain nameless) had bought EIGHT full chasis E10Ks but only loaded them with a couple of processor boards to "give the ability to scale". In other words they'd spent MILLIONS of dollars on a couple of small Solaris boxes. This doesn't mean "they'd have been better off building it themselves" but that they'd have been better off not having the person who ordered those off the no doubt laughing all the way to the bank salesman. The bit in Jim's post that he doesn't consider is that there were idiots involved in the $10m decision.... and right now my money would be on that. Steve 2009/10/31 Javier Castañón <[email protected]>: > > Jim Webber rebuttal to Dave Chappell: > > http://jim.webber.name/2009/10/30/617410fc-7ec9-489f-a937-f50cf090bf48.aspx > > Javier > > David Chappell wrote: >> >> >> My employer (Oracle) would be quite happy if $250M for every SOA project >> in a large company went towards our middleware. However that's just not >> the case. The cost of the middleware is just a small fraction of the >> total project spend regardless of the size and scope. The argument >> being put forth here has no basis because its based on an incorrect >> assumption. >> >> The greater cost of any project, whether SOA or otherwise, is the people >> time. I would argue that trying to do a project based on SOA principles >> without middleware is just wasting more time reinventing wheels that get >> built into proprietary frameworks that have to be maintained over time, >> or worse just left behind by the "Guerrilla" consultants. >> Dave >> >> ------------------------------------------------------------------------ >> *From:* Gervas Douglas [mailto:[email protected]] >> *Sent:* Thursday, October 29, 2009 11:02 AM >> *To:* [email protected] >> *Subject:* [service-orientated-architecture] Moe on Guerilla SOA >> >> >> >> <<About 15 years ago I came across ‘/The Guerrilla Marketing >> Handbook/’ by Jay Conrad Levinson. The concept was to create >> branding and lead generation through unconventional and small scale >> activities and events that could have as much impact as a large >> seven figure advertising campaign. Unfortunately, a lot of people >> took this as an excuse to commission irritating and humourless >> “viral” internet campaigns churned out by clueless marketing >> agencies. However, the concept of getting maximum results from >> minimum resources has stuck with me. >> >> More recently, Jim Webber coined the phrase ‘/Guerrilla SOA/’ to >> describe lightweight approach to SOA that does not rely on big >> middleware products. Jason Bloomberg at Zapthink has also championed >> a ‘zero’ middleware approach to implementing SOA. >> >> It is unfortunate, but not surprising, that the elegant and >> relatively simple view of SOA has become bloated with a bewildering >> array of methodologies and products, leading to confusion and >> bafflement by many of its proponents and potential converts. It >> doesn’t help when the industry analysts solemnly state that the cost >> of setting up an SOA infrastructure in a large company is about $250M. >> >> Into this discussion have waded a number of alternative gurus >> offering to make SOA once more a simple, affordable option – which I >> will group into this Guerrilla SOA discussion, but also seek to >> differentiate the approaches to allow you to find a way forward that >> may best suit your circumstances. >> >> *WS-everything* >> This is a sizable clan of developers for whom SOA has always been >> both synonymous with Web Services, almost to the exclusion of any >> other architectural considerations. For them, SOA is all about >> creating the best WS-* compliant code, in Java or .NET, in the >> knowledge that each web service can call or be called using the WS >> standards evolving on the Web. They have no need for ESBs, Service >> Repositories, or any other fancy technology solutions. They may >> grudgingly agree to use a standard Portal product, but knowing deep >> down that they could write a better one themselves. >> >> *Agile* >> Since software writing began there have been rapid application >> development (RAD) methodologies and approaches to help speed up the >> software development life cycle. In the Eighties I helped to develop >> RAD, JAD (Joint Application Design) and plain BAD (Bugger All >> Delivered) methods, which have since evolved through Dynamic Systems >> Development Model (DSDM) to the current mess of Agile, Scrum, Lean >> Development (LD), etc. These approaches apply iterative phases to >> the meeting of user expectations and typically use whatever rapid >> development tool or language they can get their hands on. Or failing >> that, Visual Basic. Agile can be applied to SOA to cut development >> times, but care must be taken to apply the approach to the >> development of services, not the whole application, otherwise you >> will end up with a single application-sized service. >> >> *Service Providers* >> With Software as a Service (SaaS) becoming more mainstream, the >> service providers (i.e. vendors) behind these web-based functions >> are promoting the use of a browser plus widgets approach to >> developing applications, where you just have to mix and match the >> SaaS offerings to meet your business requirement. You can then run >> this on the cloud computing Platform as a Service (PaaS). In fact it >> is so simple that you don’t need an IT department anymore. Of >> course, not everyone is gullible enough to jump straight into this, >> but it is an interesting direction that suits the SOA principle, >> albeit unproven as yet. >> >> *Product Vendors* >> There is still an enormous and growing population of SOA product >> vendors crowding the market and fighting tooth and nail for your >> business. Many of them have ingenious software tools that can assist >> you, and they invariable have a pitch that goes something like this: >> “Buy our tool and you won’t need to buy anything else to do SOA”, or >> words to that effect. The point tool vendors are trying to pull a >> fast one here: either their tool is only part of the Service >> Oriented Infrastructure you will need, or it is so big that they >> will want the $250M I mentioned above for it. >> >> So where does this leave the search for true Guerrilla SOA? As ever, >> it is a case of mixing and matching these approaches to the type of >> business problem you are trying to address. Step back a little and >> apply some common sense to the scope and scale of the problem you >> have, and also be clear from where you are starting and the >> knowledge and ability you have to go on your journey. There will >> some problems for which each of these approaches will work for you, >> but I can guarantee that no one solution will solve all of them. SOA >> itself is still evolving, so being agile, with a small a, is >> probably the best advice I can give. Other than not to try Gorilla >> SOA...>> >> >> *You can find this article at: >> http://www.soainstitute.org/articles/article/article/guerrilla-soa.html >> >> Gervas* >> > > > > ------------------------------------ > > Yahoo! Groups Links > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
