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

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

Reply via email to