The first part of this two-part series revealed Progress Software’s background as well as its product line-up. Progress’s mission and goals—to provide its clients with “software products and services... that dramatically improve development, deployment, integration, and management of quality applications worldwide”—clearly includes the practice of partnering, to the benefit of both sides. Here, Technology Evaluation Centers (TEC) interviews Progress Software to elicit the vendor’s opinions regarding current software trends, and how its product line meets changing market demands.
TEC: Service-oriented architecture (SOA) stack approaches (wars): are they all converging to virtually the same thing, or might there still be some differentiation?
Progress Software: The stacks are starting to look very much the same, as they all tend to have the same components and cover roughly the same requirements. To find differentiation, you have to look at something other than technology coverage and features. There are, in our opinion, two perspectives that customers can look to for differentiation between vendors.
The first perspective is the philosophy, history, or attitude that a company brings to the elements of their SOA stack. Software companies tend to bring similar design patterns to all products they produce. Microsoft, for example, tends to think and design from the desktop. Oracle thinks and produces from the perspective of a large information technology (IT) department. So customers should understand the needs and preferences of their own organization before choosing a SOA stack or any element thereof. Software companies don’t change their basic values and beliefs just because they adopt SOA.
So what would be the equivalent beliefs—or starting points—for Progress SOA products? Technology projects at Progress Software tend to always center on the reliability, efficiency, and scalability of the core runtime capabilities of our products. We believe that SOA puts additional requirements on an IT environment for distributed scalability and reliability. We design our products to ensure that those elements are architected and implemented correctly to avoid such problems.
The second perspective that the customer should examine goes to the very nature of SOA itself. By definition, SOA should impose as few component interdependencies as necessary. This is true at both the application and the infrastructure level. In theory, there should be no “SOA stack.” Customers should be able to select whatever components they want from whatever vendors they choose to work with. All vendors support a set of standards that loosely define SOA, but too many vendors are all too willing to compromise the ideas of SOA to promote their own interests in selling the whole stack. The idea behind SOA is that the customer is in control of application and technology choices—not the vendor. The “stack” approach to SOA runs counter to that choice.
TEC: Any comment regarding pro-et-contras for both the platform choice and rationalization (“lock-in,” and constantly waiting for the moving parts to be in sync)?
PS: There’s a constant tension in the industry between the vendor’s desire for lock-in and the customer’s desire for interoperability. This tension has increased as technology vendors have added applications to their portfolio and vice versa.
Think back to earlier days of computing: Customers bought everything—hardware through to applications—from a single vendor. DEC, Burroughs, IBM, and Sperry all sold business applications. This was the ultimate stack, with all of the inherent compromises fully realized. In general, the business applications were not very good. This led to the “break-up” of the stack to where today there are choices in hardware, operating systems (OSs), infrastructure, and applications.
But recently, technology companies have been working to re-establish the stack. Oracle, Microsoft, SAP are all combining application and infrastructure pieces. As before, there will be compromises and their will be a loss of control for the customer. And, as before, we believe that ultimately the customer’s requirements will win out and the stacks will start to break up again. Regulatory judgments, like the European Union’s (EU’s) recent pronouncement against Microsoft’s bundling practices in Europe, are also further supporting customers’ freedom of choice.
In every industry, the consumer is the ultimate arbitrator of how they will buy a product and from whom. Today, in software, the complications and headaches of getting different components to work together often leads customers to select a single vendor and live with the consequences of compromise and lock-in. Over time, however, we believe that efforts needed to achieve and maintain interoperability will decrease to the point where most customers will assert their power to assemble the infrastructure and application components that best fit their unique business requirements. After all, that’s a big part of the reason that SOA has caught on.
TEC: What are your views regarding the “wrap-around versus rewrite” dilemma? Will any products in your family be completely rewritten in managed code?
PS: Look inside almost any application in actual production today, and you see the equivalent of an archeological dig. As you sort through the source code, you will find evidence of almost every technology and architectural trend that occurred after the application was originally designed. SOA doesn’t change this; it simply provides the next step in the evolution. So a certain amount of “wrap-around” is inevitable.
The technology industry tends to look at this as two choices: “wrap and leave” or “re-invent.” There will be times when each is appropriate, but we believe that the right answer in most cases lies between the two extremes. With a little planning and the right tools, most applications can be evolved forward from current state to desired state with surprisingly little disruption. SOA is, itself, an evolution forward from earlier “componentized” approaches.
If the answer is always “re-invent,” then we are doing something wrong as an industry. It is our responsibility as software providers to not just provide new state-of-the-art products, but to also provide a reasonable path for moving existing applications and technologies forward in that direction. Look at this question from the view of the customer. Customers are looking for functionality, flexibility, and interoperability. They are not willing to keep re-investing in new products over and over just because the technology industry introduces some new direction. So we need to only “wrap” existing applications, we need to evolve them forward to better provide for that flexibility and interoperability customers expect.
TEC: Vendors often de-emphasize major upgrades, turning rather to vertically oriented and optional value or service packs. Anything on that matter on your side—that is, what will be the "quantum leap" versions of your products?
PS: This question illustrates the depth of the “upgrade” problem for both customers and vendors. As vendors reach farther for larger market shares, it becomes almost impossible for them to create monolithic product upgrades that are applicable to their increasingly wide range of customers. From the customer’s perspective, the desire to take on large upgrades is simply not there. Every IT environment has so many moving parts, all of which must be coordinated and often upgraded simultaneously, that most chief information officers (CIOs) shudder at just the idea.
As SOA becomes more the norm, the problem of large upgrades will likely increase. Most vendors will respond by going to smaller “service packs” and similar [products], reserving major upgrades for major shifts in architecture, technology, or functionality.
As an infrastructure provider, Progress must be concerned with accommodating software upgrades and changes easily. In particular, our business application platforms must be structured such that our customers can evolve their environments and applications forward at their own speed, with as few functionality restrictions as possible. Our SOA infrastructure products must work across multiple technologies and versions and accommodate differences when integrating together multiple applications and multiple data sources. For example, our DataXtend Semantic Integrator product includes utilities to easily find and document dependencies and problems when upgrading data definitions for a given application.
TEC: Microsoft Desktop supremacy—solo, Duet, or can many still play at this game?
PS: With Duet, Microsoft is further expressing its belief that there is a single tool for all jobs. To say that every application is best served with a Microsoft Office-like user interface (UI) just doesn’t make sense. We believe that customers, over time, will continue to explore alternative user interfaces. This isn’t a direct threat to Microsoft’s desktop dominance, but it is [recognized] that not every user requires the same desktop with the same user interface for every application.
It will be interesting to see how customers and application vendors react when SOA makes it that much easier to “re-skin” business applications with new (or even multiple) user interfaces. There are plenty of alternative approaches on the market, but most applications today are not well structured to easily take advantage of things like AJAX and Adobe Flex.
TEC: Incidentally, what about partners—independent software vendors (ISVs) and value-added resellers (VARs)? Anything similar (or more impressive) on your side, with regard to the above?
PS: Progress has always been a big believer in the power of ISVs and VARs. We built a company with the belief that regional and industry specialists were the best people for understanding and fulfilling individual customer needs, particularly in the mid-market. Recently, that view has come under attack from large software vendors looking to increase market share with a “one-size-fits-all” approach. ISVs and VARs have been reduced, in many cases, to extended installation and support teams. While that does serve some purpose, it falls far short of what customers expect and what ISVs and VARs need to stay in business.
It’s our belief that ISVs and VARs will play an even more important role as SOA becomes predominant. To get the agility and flexibility promised, businesses will need partners that specialize in everything from custom service development to SOA configuration and management. And with the gradual demise of the monolithic application, domain specialists will play an even more important role in constructing the correct solution set for a given vertical specialty of specific customer.
TEC: Going mid-market versus defending it: what, to your mind, will the key success factors (KSFs) be in this market, and what have you additionally been doing there?
PS: It has been amusing to watch enterprise software fail repeatedly in trying to move to the mid-market. With each attempt, they learn just a little bit more about what is a very complex market. With enough time, they might actually figure out what software companies specializing in mid-market have known for years. There are many traps to fall into when addressing the mid-market, but the most common is that somehow mid-market customers need less functionality. An acquaintance of ours with Epicor Software nailed it when he noted that the difference between enterprise and mid-market was that in enterprise, there were five people all doing one job, where in mid-market there was one person doing five jobs. But all the same jobs still exist.
With that as a starting point, mid-market also places some unique requirements on software and software providers that are not well suited to large enterprise providers. First, mid-market customers need all the same technologies and applications, but they need them better packaged, more automated, and more specifically focused on their industry or marketplace. Mid-market customers don’t have and will not tolerate armies of consultants or integrators to make a system work in their environment. Second, mid-market customers cannot afford to be “guinea pigs” for technologies or applications that are not quite ready for prime time. They have small staffs and limited resources, and things have to go right the first time. As a journalist once put it, with a mid-market customer, you have one chance—get it right or go home. Maybe that’s why Progress has always been successful in the mid-market.
But the biggest key to understanding the mid-market is to understand that it isn’t “a market” at all. At some level, all enterprise customers look that same. But the mid-market is actually thousands of smaller markets, often made up of just a few hundred target accounts. This is the biggest barrier for the large enterprise vendors, and the biggest opportunity for software vendors willing to take the time to build and support ISV and VAR channels. The mid-market looks very attractive when an enterprise vendor just looks at the big numbers, but it loses its luster quickly when vendors realize the effort needed to tune their products, messages, and go-to-market plans for those thousands of subgroups that make up the mid-market.
TEC: SureStep, QuickStep, and Accelerate: breakthrough implementation methodologies, or just "baby steps” in that regard? Are we missing something earth-shattering in your offering there?
PS: The realization that mid-market companies have all of the operational, regulatory, and supply chain complexities of larger customers is encouraging. Hopefully it means that software companies are finally starting to “get” the mid-market. But the current offerings from SAP, Lawson Software, and Microsoft Dynamics, to name some, seem more like a thin veneer than a true solution to the problems of software implementations. There are only two things that seem to truly address the problem. The first is software that is specifically designed for a given industry and the mid-market players in that industry. Vertical capability is something that is designed into software, not layered on. The second is a software company that provides deep industry expertise in all of their personnel—sales, support, services, and development. These resources provide expertise and experience that templates and pre-configuration schemes simply can’t match.
Perhaps, in the future, we’ll all figure out how to truly make sophisticated software easy to install, configure, and implement. But right now, these seem like baby steps.
TEC: At the end of the day, which vendor do you think is in a better position to ultimately win in the market? Or maybe no one, and everyone will simply remain at the current equidistant positions?
PS: At Progress, we don’t believe that any one single vendor will “win.” And that’s a good thing. As customers, businesses should be able to choose the vendors, the infrastructure, and the applications that best fit their requirements. If one vendor “wins,” then customers will all lose.
The idea that companies of all size and type, in all industries, can somehow all be equally well served by one vendor is illogical in concept and reality. This industry, like most, goes through cycles of innovation and consolidation.
Progress Software’s Parting Comments
SOA, by design, should promote choice. That choice should be in the hands of the customers, not the vendors. Current efforts by various vendors to use SOA to drive consolidation just don’t make much sense. Sure, every vendor wants to capture as much market share as possible, but they should do that with the strength of their ideas and the quality of their products—not with the dreaded “vendor lock-in” strategies currently on display.