ZapFlash

Including Startups in your SOA Infrastructure: A Guide for Enterprise Architects

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 20th century, 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.

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.

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.

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.

Discussion

3 comments for “Including Startups in your SOA Infrastructure: A Guide for Enterprise Architects”

  1. Ron:

    As the CEO of a start up, and as a C level former IT exec, who was responsible for major technology aquisisions, espeshially in the SOA infrastructure realm, I applaud this post.

    I want to give other start up sales and product executives my insight from both sides of that fence.
    As an IT buyer:
    The risk of using a start up is great, especially if the buyer is a large enterprise.

    I always entertained start ups, and I told them this on the first call:

    1: Be prepared for a long sales cycle. We are cautious and slow.

    2: You have to offer me a significant business or functional advantage over the large vendor, in order for me to embrace you. I will go with the large vendor unless the advantage that your innovation offers means (pick your metric)% better then the large vendor. I used to say you have to allow us to eliminate $3 MM of cost, or bring at least 10 MM to our top line with your solution, or it is not worth it to us to think about using you. This metric of course assumed a decent roll out across big enterprises for the start up’s product.

    As a start up CEO:
    I see it as my job to convince my customers, that our solution gives them a significant functional advantage that the current solutions can not give them.

    I see it as my job to excite the customer with their ability to drive our road map and our ability to quickly respond to their needs.

    I see it as my job to help the architects, engineers, and product managers on our team, to translate the customers problems into generic problems so we don’t get into the one off business.

    I see it as my job to understand what our core focus and mission is and ensure we tell the customer what that mission is, so that we only solve the problems we are supposed to solve and not the problems we should not be solving.

    We want the customer to be our product managers, which means the customer must be in tune with our mission so they take us in the right direction and ask us to solve the problems that drive us and them where we are trying to go together.

    The fact that we continue to build our tools with a flexible achitecture

    The fact that our core methodology, and even project managment style is built on top of SCRUM allows us to respond quickly.

    The fact that we have been the customer for so long

    The fact that we have a team of engineers who know our domain cold, and have worked on major legacy solutions allows us to understand these problems like no other solution in our space.

    We are like other start ups, in this regard.

    Again, Thanks Ron for this post.

    Posted by skip snow | March 25, 2010, 11:03 am
  2. This is an interesting take on the value of startup vs large IT consolidated companies in the EA. I think they missed a very important part of risk mitigation for utilizing startup company offerings- standards based products. The more a vendor’s solution is based on standards the easier it should be to swap in replacement component based on the same standards. This may be a bit of a ‘Pollyanna’ perspective, but as vendor product architectures move towards standards based services it should become more of a reality.

    Posted by Ken Adee | March 25, 2010, 8:34 pm
    • Ken

      I am 100% with you on that. Where the interfaces can be standards based they must be standards based.

      Also, in the composition of a product, where the product solves ancillary problems, because it has to in a primitive environment, the ability to plug in another solution to it’s architecture, in a more sophisticated environment is a key variable as well.

      Posted by skip snow | March 25, 2010, 8:50 pm

Post a comment

FREE POSTERS

NEW VERSION! ZapThink's Vision for Enterprise IT in 2020
With all new content including Dev/Ops, Hypermedia-Oriented Architecture, Big Data Visualization, and more!
Click here to download for FREE
10-pack of prints for only the cost of shipping!

SOA Implementation Roadmap
Over 100,000 downloaded!
Click here to download for FREE
10-pack of prints for only the cost of shipping!