I gotta say I agree 100%. One of our customers, a large bank (yes, one which is still standing straight!), entered into one of these big vendor enterprise agreements and found that their software was, um, bloated junk. They're using WSO2's software because its (a) fit for purpose, (b) let them get the problem solved without having to go thru miles of software layering and (c) showed them results early and fast.
SOAs need to be developed bottom up and one service at a time. Trying to rearchitect the enterprise around SOA is a losing strategy that will not deliver results. In fact, that's true not only about SOA but about any technology deployment strategy. I can't believe that we still live in waterfall style development model which has created so much of IT failure. The problem of course is that vendors benefit from this model as they sell you junk that you don't need. I will always advocate true open source SOA middleware- the main value being the ability to realize real value before having to pay (if you want support). In the traditional model you have to believe the vendor and buy based on marketing pitches. With us, you pay us after you've seen real value delivered .. not before. So that eliminates the vendor push model and instead it makes it a customer pull model for technology purchases. Sanjiva. Gervas Douglas wrote: > The following article was sent to me as an e-mail from David Linthicum. > > Gervas > > SOA in Danger of Over Hype, Over Spending, and Bad Practices > > David S. Linthicum > > In a recent Burton Group event, the analysts stressed what I’ve been > beating to death for years now, that too many companies are over > spending in the SOA space, too early, and are not thinking through the > core issues. Thus, many initial SOA project are in danger of hitting a > wall before the core value of SOA is understood. > > The Burton analysts stressed that you don't need to chase after some > Enterprise Service Bus (ESB) with every possible option, or try to > support the latest chic Web services standards to achieve service > orientation. Indeed, they are describing what SOA really is--an > architecture style--and thus something you do, not something you buy. > However, don’t tell the vendors that. > > The hype in the SOA space is raging right now, largely due to the amount > of marketing money that’s being spent in order to both create and > capture the demand. You just don’t feel like you’re a true enterprise > unless you have an ESB and governance tool, no matter that you’ve not > figured out how to use them yet. > > Indeed the big “SOA stack” players are in the market early with > enterprise license agreements that lock in their customer into an > all-you-can eat SOA technology buffet that will supposedly provide them > with solutions to all of their SOA needs. The truth is much more > complex and less exciting. > > In actuality, each enterprise is like a snowflake, and the problem > patterns present vary greatly from problem domain to problem domain, > enterprise to enterprise, as I’m finding both in my consulting practice > and data points with a number of SOA practitioners out there. Thus, > selecting technology before you understand your unique issues, puts your > first SOA project at risk and will cost you dearly, considering that > this is the mother of all mistakes that you can make here. > > There is much homework to be done before you can begin shelling out the > big dollars for the big SOA technology, and more often than not you’ll > find the technology that’s a fit is not the technology you had first > thought. Case in point are the number of projects I’m finding where > ESBs are not the correct solution, but their early purchase means it’s a > “force fit” which means the project is at risk, and at the very least, > the solution is not optimal. Not that ESBs are bad; they are not. > However, like any technology, ESBs do not fit within all SOAs. Same > can be said about SOA governance tools, SOA security solutions, service > development tools, etc.. You can define your architecture around > technology, and the reverse is also true. > > The fact of the matter is that you need to go through some iterative > steps before you can even begin to define your technology requirements, > and look for products that fit them. > > First, you need to understand your data at the semantic, metadata, and > abstraction levels. This means a clear definition of what’s there, > what’s needed, and how it should be modeled and implemented as a part of > your SOA. Data is the foundation, services are the externalization, > and processes are the solution. Keep that in mind. > > Second, you need to identify all candidate services, or potential > services in your domain. This means going on a service mining > expedition, looking at mainframes, and other enterprise applications for > core business processes that need to be externalized as services for the > architecture. This means working back from screens, APIs, and > transactions, and the creation of a solution for recasting them as > services. > > Third, you need to figure out the meta-processes that are a part of the > domain. This will become the foundation for your orchestration and/or > choreography layers, in essence, defining how the services interact and > providing a platform for driving them together into solutions. > > Beyond all that you need to figure out performance, security, service > tracking, service level agreements, policy management, design time, run > time, and any special needs that your project/domain may have, and there > is always something that’s unique. Then, and only then, do you figure > out your technology requirement. > > Those who jump right into the SOA hype pool full of SOA technology are > finding a few things out. They are not solving their problem, they are > not using best practices, and worst of all, they are putting their > projects at risk and spending too much money in doing so. I’m not sure > if this is one of those “let the kid touch the hot stove” issues, where > a few painful failures will teach the masses that this is the wrong > approach, or if I need to keep jumping on my soapbox and preaching the > very unpopular notion that SOA is complex, hard, and if you’re going to > make it work, it’s going to take some work. Sorry to be the buzz-kill, > but somebody has to speak up. > > Happy to listen to other options here. > > -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ ------------------------------------ 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/
