My first iPhone application finally went live. Bodhtree Consulting and Bob Alonzi were my partners in crime.
See the application on ITunes at
itms://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=315331924&mt=8&s=143441
iPhone Stretching Application
In my last posting, I put out a thought that SOA is the foundation to the success of Web 2.0 and SaaS. Let’s talk more about that.
SOA provides for the loose coupling of business functionality and access to this functionality over the wire. Actually the real value behind SOA is how Web 2.0 / SaaS services are simple, easy to “mash” ,ease to use and consume. The concept is that of Service Composition where composite applications are built using tens and hundreds of smallers services to deliver business value. This is well served by the technologies and products in the Web 2.0 and SaaS spaces.
Thus the fundamental principles behind SOA, combined with the innovations around Web 2.0 and SaaS offerings, lead to a SOA approach that targets the millions of internet consumers. Web 2.0 allows the thousands of internet services to be orchestrated together to form new services for the internet consumer.
In Enterprise SOA initiatives, or rather in an Enterprise, you end up needing a tighter wiring of the Services and typically have fewer of these Services, which then begs you to question the value of SOA in that environment. Additionaly E-SOA is typically behind the company’s firewall – and each Service has 1-5 consumers. This agains begs you to ask the question, do you really need a “Service” or some other form of integration between that data or business functions.
As someone said, SOA is dead in 2009. If you start agreeing with this line of reasoning, you will probably say something like “SOA will be re-born in 2009, 2010″.
SaaS and Web 2.0 are the new mantras, and once we recover from the financial crisis, these technology concepts will see a new birth. The hundreds of startups, service providers and hosting providers that are aggresively innovating new products and services will finally see the customer base they would have hoped for, if the economic issues had not put pretty much a stop on spending.
Web 2.0 is all about the free exchange of content. The content can be simple one line message (Twitter) to videos of all sizes (home videos on YouTube, targeted content at Break.com and Crackle, legal video on demand at Netflix and even the illegal video and music sharing sites like ….. ). However, is Web 2.0 just that?
It is also about the ability to take this content and create new content from it in new and innovative ways. Guess what, there is another word for that – “Mashups”. Thank GOD – not another TLA. Google Maps is probably the most used Web 2.0 concept that is exploited in mashups.
This multi-user, multi-device, ubiquitious way of information sharing is quickly becoming the next generation of the Internet.
SaaS is way of offering software over the web. Instead of making huge purchases of software and dealing with infrastructure and support issues, SaaS is a way to offer that over the Web. This is obviously putting it very simply! Guess what – that leads to yet another concept called Cloud Computing! We’ll talk about that in a later blog posting.
SaaS can be seen in various forms. The example most often cited is probably SalesForce.com. However, you can see SaaS offerings in almost every technology area – CRM, ERP, Identity Management/Security, Audit/Complaince, Content Management and even SaaS for custom business application – aka Compute and Storage Clouds like Amazon and Google. SaaS is also combined with Web 2.0 for content sharing like Google Docs and Microsoft Live.
Ok… so what happened to SOA. The real question to ask is would Web 2.0 and SaaS have existed without SOA?
I have to agree with the SOA skeptics in most cases. SOA as an enterprise architectural pattern has had mixed success. Any technologist will probably argue that the failure of SOA was not due to the fact that the technology architecture, tools/products to support SOA etc where wrong or not up to par. They went through their maturity cycles, and are now prime time ready.
However, the failure of SOA can be probably be attributed to the lack of a solid process understanding of how to implement SOA in an Enterprise. I have written enough about this…. (see my publications)
I would argue that the software architectural principles that existed since the inception of Computer Science, but highlighted using SOA as the buzz word, form the foundation that enabled the innovation around Web 2.0 and SaaS. Let’s chew on that……. thoughts… arguments……? I will do another post soon with some more thoughts beyond this bold (or not so bold) statement.
By now you have surely read a lot of stuff about SOA being declared dead as of Jan 1st, 2009. Hmm.. what does that mean?
Does it mean all SOA projects have come to a stand still?
Does it mean that the principles that SOA preached are no longer viable?
Does it mean that technologists will stop working on SOA enabling products and solutions?
Does it mean standards organizations will not create more standards around Web Services, ESB, etc?
Does it mean that ESB is dead?
This and a hundred other questions come to mind when someone makes a statement like “SOA is dead”.
My 2 cents for those who might care – SOA in its traditional form is dead – and by that I mean that the large multi million dollar SOA projects are dead. The concept and architectural principles preached by SOA are only becoming more and more relevant. 2009 and 2010 should see the emergence of true SOA architects and business analysts who know how to implement SOA in less time and money.
I have always preached that any “SOA” project with a price tag of over 250,000 is a failed SOA project. If you just use a quarter million dollars as a threshold, you are forced to scope projects that have to quickly demonstrate ROI and are 6-9 months in duration.
The key mistake around SOA has been projects that have implemented a millions dollars of technology with 5-7 services sitting on top of it. Of course, SOA would be considered DEAD if that were to continue into 2009.
SOA is not dead – people who understand SOA are getting smarter about implementing it – or should get smarter about implementing it.
I can agree that the acronym SOA is now tainted, and someone should give us another TLA (three letter acronym) that represents the fundamentals of SOA.
Let’s talk about when to use an ESB and in what cases a ESB might be an overkill. Review my blog posting from a few days ago about ESB Myths as a pre-cursor to this.
As you probably already know, all SOA vendors and consulting firms will try to sell you an ESB or some equivalent product. Here is a simple rule of thumb that I apply whenever I guide someone on ESB’s. – If this is your first SOA project or some sort of SOA pilot – do not even think about an ESB. Focus on other key SOA issues first – primarily Service Design. This to me is the key to success – getting your Service Design wrong can be the end of SOA or your organization. Help you Architects and Business Analysts drive the culture of Services and how to get their business users think in terms of data, services and re-use.
Often and ESB is an overkill, if -
1. All Services are simple, Request-Response type messages – or rather all messges in your SOA use a single communication paradigm.
2. You have fewer then X services (you can define X for yourself – I use 25 or 50).
3. End points are pretty static; or really there is only 1 type of service for each business function. For example if you have a Product Master system and there is only 1 Service to get information from that system. This would be unlike a typical weather or stock service where if 1 is down, you can select from 10 others. In a scenario where an end-point is static, routing and navigation can be achieved without a directory, or a ESB as easily as if you had one.
4. Most of your Serivces are internal facing – which means the producers and consumers of the Service are pretty static.
5. The actual development teams know each other and can talk as easily across a room or bldg or whatever. Basically this applies to inter-organization services where communication about the interfaces, business fucntions etc are happening between the functional and technical teams. Services are just used as a means to make integration easier.
So, when do you really need an ESB -?
1. Your Services are truly dynamic – the consumers are unknown or they are evolving fast.
2. Elements of your Services are constantly or frequently changing as new customers of the Services come aboard
3. You have a lot of Services
4. Services are integrating legacy business applications with new applications or packaged solutions. More over you need a mix of technologies and communication channels – request/response, pub/sub, reliable delivery, queuing and so on.
5. Basic transformation of messages is required – either to support new customers and/or service versioning
6. Back-end systems are evolving or being replaced – example a business process today has a touchpoint to a legacy mainframe app that is scheduled for retirement as the new system is built
7. Business processes are evolving and changing due to market pressures, M&A activity etc.
Again, the important thing to remember is that you will probably answer yes to 4 or 5 of the above – and that is fine. An ESB does have a role in an SOA, but just not in the initial SOA. Think always about your overall SOA maturity in terms of technology, infrastructure, governance, business maturity, culture and budget. Once you are at some relatively mature state (using any SOA maturity model you choose) – an ESB can add a lot of value.
My key recommendation is to avoid the 100-500K investment (typical of any medium size ESB implementation) till you have already proven the value of your SOA to the dudes with the purse strings.