+1 Nonsense to say that the product spend is a huge part of it. Most projects its around 10 to 1 or greater over a long programme and at least 4 or 5 to 1 on short engagements. Anyone who is spending more on licenses than implementation in SOA is a muppet.
The exception to this is package vendors where the more vanilla the better. My depression comes from seeing old school EAI products continually miss sold as ESBs and groaning at yet another MOM architecture calling itself SOA. Steve 2009/10/30 David Chappell <[email protected]> > > > 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* > > >
