Editor's Note: If you're interested in how SOA affects your security architecture, be sure to check out ebizQ's upcoming webinar.
Much is often made of the benefits of SaaS or on-premise software or open source or other technologies considered as groups, but the reality for many companies and ISVs is an architecture that includes a mish mash of different types of software, or a hybrid architecture. I recently joined Dominic Sartorio, president of the Open Solutions Alliance and senior director of product management for Spikesource, to talk about what hybrid architectures mean. Listen to the podcast below, or read the transcript.
KD: Hi, I'm Krissi Danielson. Although we talk a lot about software philosophies and choices in the technology press, the truth for most companies is that they're just trying to get stuff done rather than strictly adhering to any particular software methodology whether that's Software as a Service, Open Source, on-premise software or what have you. As a result, many companies and ISPs have a hybrid architecture that combines numerous different tools and this leads to both benefits and challenges. I recently spoke with Dominic Sartorio, President of the Open Solutions Alliance about what a hybrid architecture means and how companies can work with it.
The first question I have for you today is, "Could you talk a little bit about what it means to have a hybrid architecture including technologies like software as a service, open source, proprietary software, etc. Are most companies more hybrid in nature or do they tend to stick to a one software philosophy.
DS: That's a great question and a question a lot of ITs ask as they build out their products and go to market. We can think of it in two ways. First, what technologies an ISV decided to build their product in, whether it's open source or proprietary and then how do they choose to package and deliver that software. Do they choose to deliver it as an on-premise install through virtualization or in a hosted environment as software as a service. And those are really two orthogonal (?????) questions. You can be open source, in fact you can be proprietary and SAS and so forth.
My experience is most ISVs are mixed and the decision-tree they go through in order to determine what technology to use is determined primarily by the requirements of the application itself, such as whether it's a web app or what its use cases are or how highly available or performative it needs to be and that determines the technology choice. And a secondary determinant might be what technologies their developers happen to be familiar with. So, if you developers with a lot of Open Source familiarity, that could tend to skew it in that direction. But, my experience has been that most ISVs are mixed and with all the ISVs SpikeSource over the years, many hundreds of ISVs, we've found that the number of ISVs who are mixed are at least 10 times those who are purely Open Source. Even commercial Open Source ISVs who's own business might be Open, they may have a mix of proprietary and open source underneath, and vice versa. The proprietary ISVs, their own bits may be closed, may leverage a lot of Open Source. So, in that regard, most ISVs are hybrid and when they go to market, they choose a form factor that they feel lends itself to what their customers expect and the degree of customization, integration their customers need to do so we've seen a lot of ISVs go toward SAS, software as a service, because they figure that's the easiest way to reach their small to medium sized business customers and others choose to go on-premise because may have large enterprise customers that need to a lot of customization or integration or they may have regulatory reasons like HIPAA or SOX for keeping and managing data in-house so, and even there, a lot of ISVs are mixed - they may have on-premise for their enterprise customers and SAS for their small to medium customers. It's very rare that an ISV is choosing just one exclusively and not doing the others.
We don't see companies choosing one software philosophy. I mean, ISVs tend to be pretty pragmatic; it's very rare that I've seen an ISV that's religious about Open Source and they go only Open Source or only proprietary, for that matter.
KD: OK. So, would you say there are strengths to having a hybrid architecture as opposed to a homogenous one, such as, like, the idea that having all of your corporate technology from one vendor could be risky and give that vendor too much power in the company?
DS: Yeah, I think there's some truth to that. I don't know many ISVs who say they want to be strictly an Oracle shop or an IBM shop or any other vendor shop, for that matter with the rare exception that the ISV's business model is strictly dependent on that bigger vendor's eco system. You see that sometimes but it's very rare. Most ISVs they want to deliver a solution, a business solution, they want to be heterogeneous because they know their customers may have a variety of technologies. As I mentioned earlier, their developers make this technology decisions based primarily on the requirements of the applications they're building and they want to have the freedom to choose the technologies that implement those requirements best and so they may find, for example, they'll pick an Open Source web server and a proprietary database or vice versa. But you're right, very rarely will an ISV choose all of their technology from one vendor unless it's part of their strategy to be very closely aligned to that one vendor and that's very rare.
KD: OK. So, would you say there are any drawbacks to having a hybrid architecture such as challenges with integration or other issues?
DS: Yeah, that's actually the biggest challenge actually where if you're pulling technologies from different vendors and from different sources, then you're pretty much on the hook yourself for making sure that they integrate well when they install them, they install together well with minimum pain for the customer and so that does create an additional burden on the ISV but that burden is usually offset by the fact that the developers chose what they felt was the best technologies for the job and not feeling locked into a particular vendor. So, but fortunately, there's been a lot of work in the industry to make that interoperability pain easier. Certainly there are a lot of open standards in the industry, the emergence and maturity of service oriented architectures is making the challenge easier, web services interfaces and so forth and also there are consortia out there that make it easier and the consortium, the president of the Open Solutions Alliance has been focusing on interoperability between various technologies in a given stack as well as interop between solutions that ISVs may ship and so we've delivered a lot of best practices and reference implementations that ISVs can pattern match basically, you know, we've done it once and learned some lessons that we've shared with the rest of the industry in that regard. So, in summary, yes, there is interoperability pain you experience but the good news is that there are consortia and standards out there that make that pain easier for the average ISV.
KD: That's great. So, to close, do you have any recommendations for companies that might be researching like how to address the drawbacks or the pros and cons of having a hybrid architecture?
DS: Sure. So, I'll give a two part answer. The first is when mixing and matching Open Source and proprietary components, be aware of the interoperability issues and be aware of the work that's been done. The Open Solutions Alliance has done some good work. Microsoft, to their credit, has done a lot of good work in insuring good interoperability and portability of Open Source on the Microsoft platform, for example, and also the standards bodies, so service oriented architectures emerged and there's the web services standards have also emerged. So, take a look at that.
And the second part which is how do you want to distribute your product. Take a look first and foremost at who your target customers are. Are they small to medium businesses who don't have the time and energy to deal with on-premise software so SAS is a good alternative for them. Or are they mostly large enterprises that may have a high degree of customization or regulatory reasons for why they want to have on-premise software and once you understand what your customers want, you decide how to go to market. The good news is that SAS is becoming more mature, you don't have to host your own product, you don't necessarily have to go multi-tenant even. There are companies out there like Amazon that provide hosting services, Google is getting into this game as well. So there are options out there for small companies that you can research. What's very interesting, if I can get this final word in, is that a lot of commercial Open Source companies are using SAS as a primary channel. We actually published the results of a survey we took today that found that 72% of all commercial Open Source companies go through software as a service as a key part of their go-to-market strategy so there's definitely a lot of adoption out there of SAS which is lending a lot of credibility to that as a viable way of reaching the market.
So, know your customers and do some homework of what the options are and there's a lot of small ISVs that have already enjoyed success going to market through the SAS route.
KD: You've been listening to a Podcast with Dominic Sartorio, President of the Open Solutions Alliance and Senior Director of Product Management at SpikeSource. Thanks for listening and have a great day.
Leave a comment