By Ronald Schmelzer
In a previous ZapFlash, ZapThink opined that Open Source Software could play an important
role in your Service-Oriented Architecture (SOA) Infrastructure. Certainly, there were no architectural reasons why it couldn’t.As we explained in that article, the primary biases against OSS (if there are any) are from the people in the organization who have fear, uncertainty, or doubt about the risks or benefits of OSS.
But of course, that article spoke at a fairly general level. Individual implementations or products might be better than others, or more suited for specific problems than others. This is where Enterprise Architects should spend their time focused – on the specific solutions to specific problems, rather than engaging in religious battles about the merits of entire classes of solutions.
Unfortunately, in addition to the biases against OSS, many companies have developed aversions to solutions from startup companies. Yet, in an environment where we are left with just a handful of incumbent companies remaining in the SOA infrastructure landscape, and these vendors have confusing collections of often conflicting and competitive infrastructure products, it might be a good time to revisit utilizing solutions from niche, best-of-breed, and often startup, solutions in your SOA environment.
However, how do you do so without incurring substantial real or perceived risk? After all, it is the nature of a startup company to change, be acquired, or die. In this environment, EAs need to become wholeheartedly selfish: meet the requirements of the business in an agile manner by reducing the penalty for failure. In such an environment, startup solutions are not only feasible, but very appropriate.
Best of breed in an increasingly suite world
Through a combination of consolidation, maturation, and the pressures of a tough economic environment, the landscape of enterprise IT software players has dwindled to a handful of companies that control the infrastructure for a vast majority of companies.
Just like the auto industry experienced a period of rapid growth and diversity in the early part of the 20thcentury, only to consolidate down to the “Big three” in the United States and a similar number in countries around the world, we are now faced with the reality of a “Big Five” set of vendors in the enterprise IT marketplace, especially in the area of SOA infrastructure.
Agility is a key benefit of SOA, which means that properly designed architectures should not only be implementation-neutral, they should be fairly immune to infrastructural change.
However, consolidation is not always a friend of innovation. Many have argued that the consolidation of the auto industry in the US by the late 1970s resulted in products that were unable to compete with offerings from overseas.
Indeed, it’s in the period after the consolidation that the US manufacturers saw its most precipitous decline in worldwide share of automobiles. Why is this? Is it because large companies can’t innovate? Or is it that the large portfolio or products and services are confusing not only to customers but even to internal managers?
When one company owns Pontiac, Buick, Oldsmobile, Chevrolet, and a myriad of other brands, how can anyone really tell when one product is best suited for a problem or another? These brands compete for dollars not only among customers, but among their own budgets. Much hay has been made of Microsoft’s internal competition and struggles that have hindered its own ability to compete. Why should it be any different for the enterprise IT software companies that have grown primarily through acquisition?
Innovation is incredibly important in an area of continued maturation such as SOA. More importantly, agility is a key benefit of SOA, which means that properly designed architectures should not only be implementation-neutral, they should be fairly immune to infrastructural change.
In this light, vendor selection is less a matter of making sure your infrastructure works and more a matter of picking the right vendor for the job while balancing risk and economic factors. In this light, startup and niche companies offer just as much opportunity, if not more, to advance your architectural efforts than those of large vendors. The only things that differentiate the startups from the large vendors are three core issues: the scope of their offerings, the potential risk of company failure, and the ability to negotiate price to your benefit.
Mitigating the startup risk:
Enterprise software and cloud/SaaS concerns
The biggest risk that many cite in working with startup companies is the risk that they might simply no longer exist. This fear is especially pronounced for companies that must spend a considerable amount of time and money implementing the solutions.
If an enterprise is involved in a multi-year effort to implement a large-scale, highly visible, and important solution for the company, then in many cases startup solutions are ruled out very early in the vendor evaluation process. This is even if the startup company offers a better, more appropriate, and more innovative solution. The real issue here is whether the risk of company failure, real or perceived, should outweigh the loss of solution appropriateness and innovation. Or in other words, does it make sense for companies to implement less-optimal solutions based on what they know today because they fear an unknown event in the future?
Rather than rule out startup solutions out of hand, companies should mitigate vendor failure by incorporating such contingencies in their enterprise architecture. We would argue such vendor mitigation plans should be made for well-established vendors as well, since internal political or budgetary battles might result in the disappearance of even decades-old products.
Companies should require an escrow provision similar to what is provided by licensed enterprise software vendors.
There are two major areas of mitigation for enterprise IT vendor products: products that companies install, manage, and own in their own infrastructure (traditional enterprise software products sold by the license), and those solutions that are run and managed on the vendor’s infrastructure (such as Cloud or Software-as-a-Service [SaaS] offerings).
In the case of licensed enterprise software, it has long been a practice of end-user companies to require that the vendor’s software code be held in escrow such that if the vendor goes out of business, it is transferred to the ownership of the end-user customer. While this is a far from optimal solution (after all, the company has no knowledge or ability to do much with the code), it provides some level of comfort to the buyers that the code at the very least won’t disappear.
More complicated is a mitigation plan for Cloud/SaaS offerings. If a SaaS vendor disappears, what happens to the code? If a Cloud vendor goes under, what happens to the infrastructure? More importantly, what happens to your data? It’s not enough to simply require that the vendor hand over the code for their SaaS implementation; in the event of their failure, you have to also implement all the infrastructure that makes the Cloud work or keeps the SaaS solutions running.
This is because the economic benefit of Cloud computing and SaaS solutions is that you’re not paying the full cost of owning and managing the solution. It is easy to mitigate the data component of the Cloud/SaaS default risk – simply make sure that you maintain a “local” copy of all relevant data.
However, in order to mitigate the loss of application functionality and infrastructure, a company needs to have a backup plan. Enterprise architects need to discover or implement comparable Services run internally or on another Cloud/SaaS service. Or, companies should require an escrow provision similar to what is provided by licensed enterprise software vendors – if the SaaS / Cloud vendor goes belly up, they have to hand over not only the code and data that makes the application work, but also configured infrastructure on which to run it. While the hope is that these escrow provisions will never have to be enacted, they provide the security blanket necessary to give one at least a psychological sense of security.
Negotiation leverage:
It’s on your side with startups
Mitigation and product functionality issues aside, there is another good reason to work with startup vendors: it’s much easier to get your way with smaller companies hungry for your business. Smaller vendors have less layers of corporate infrastructure, and many times you are in direct communication with the individuals responsible for the functionality of your implementation. In this way, it’s easier to get your voice heard on features or bug fixes. Don’t like the way something works or want a new feature? Pick up the phone and talk directly to the product or development managers, or even the CTO. Perhaps you’ll get a fix the same day or within a very short timeframe. Try that with one of the super-vendors.
Smaller companies are more eager to negotiate, especially if you are a large enterprise that could be a marquee name for them.
It’s also easier to negotiate on price. While large vendors might be able to discount or cut the price on one of their offerings so they can make another one sweeter, the realities of large sales forces and commission structures requires them to keep their products at a certain (increasingly higher) price point. Smaller companies are more eager to negotiate, especially if you are a large enterprise that could be a marquee name for them.
Finally, it’s easier to get help with your specific implementation from startup companies. Many enterprise software startup companies know that their products are not plug-and-play and require some additional effort and expense to set them up. As a result, many startups have professional services arms whose goals are not to drive revenue for the company, but rather to support the products in customer installations.
Unless the startup vendor charges for this additional service (and we regularly counsel them not to), you should consider this to be free consulting and professional services help. Use as much of this as possible, and even negotiate more into your contract. It is in yours and the startup’s best interests to make sure you get the value you require from your investment.
The ZapThink take
As you can see from the past few ZapFlashes, ZapThink is very concerned that the rapid consolidation and maturation of the enterprise IT landscape will have a negative outcome on innovation in the marketplace. We believe that the consolidation is resulting in mammoth conglomerates of vendors that will be harder, more confusing, and more expensive to work with. We believe that there is just as much uncertainty around the future of the large vendor’s offerings as there are with startup offerings. In this light, we don’t believe that there’s anything more inherently risky about a startup solution than an established, incumbent vendor solution.
The only thing that has us concerned about the startup landscape is the shortage of new startups. We’ve seen a significant drop-off in new enterprise software venture creation. We are not entirely sure why this is. Is there simply less demand for new enterprise software solutions? Is there less opportunity for new enterprise software startups?
Has the venture capital and finance community lost interest with enterprise software? Or has the area of innovation moved away from enterprise software? We hope none of these things are true. The enterprise still has leagues to go to get closer to the vision of loosely-coupled, agile, heterogeneous systems that can meet the ever-changing needs of business with high governance and low risk. There’s plenty of opportunity here. Startups: do your part innovating in this space. Enterprises: do your part and implement startup companies’ offerings so that innovation does not come screeching to a halt.
This guest post comes courtesy of Ronald Schmelzer, senior analyst at Zapthink.
SPECIAL PARTNER OFFER
SOA and EA Training, Certification,
and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
You may also be interested in:
This comment has been removed by the author.
ReplyDelete