Chapter 9: Opportunities for Large and Small Software Companies for Today and Tomorrow


Michael George

Automating Change

It is interesting to me that even over the last 100 years the concept of automation has existed in almost every industry: from making automobiles to building houses. You can buy a pre-fabricated home today. And the automobile industry is the greatest example of factory automation.

The one area that you think would be most driven by this type of advancement is the software industry, and it is not. We have millions of software programmers out there who take a piece of scrap paper and start to build software programs. It seems absurd. It's an area that should be the most automated, and yet it is the least automated.

Developers still change software manually, and the ripple effect introduces errors and delays that add huge costs to IT projects. Lack of automation makes change one of IT's worst enemies.

But change is inevitable, and keeping up with changing requirements poses one of the biggest challenges to IT groups today. Application software has become a liability and maintenance nightmare from the point of view of change. What you build today immediately becomes tomorrow's legacy - obsolete.

And change will continue to play a large role in IT, whether caused by new customers expanding functional requirements, companies merging and consolidating, replacing and updating legacy systems, or an increased user load forcing application redesigns. To make matter worse, companies are also dealing with other constraints, such as developers leaving or being reassigned to different projects and reduced budgets.

Change can be your enemy unless you have the tools to implement it automatically.

Until now, the software industry has not focused on enabling change, but instead, has focused on providing rapid application development (RAD) tools. RAD tools help you build your application code today, but fail to address how you change or branch your code tomorrow.

Over the past 5 years, the software industry has focused on providing service and component architecture for distributed re-use. Today's RAD tools make it relatively easy to build applications out of re-usable services and components. But this creates a big problem: RAD causes code proliferation and an inability to effectively implement change from that point on. Using RAD tools, IT groups create applications relatively quickly, but the resulting code is static and brittle.

When a component, service, schema, HTML page, or other referenced object changes, all the applications that use it must be changed manually. This introduces errors, delays, and high costs, resulting in change gridlock. What's needed are software companies that enable mass customization of the structure, functionality, and behavior of applications.

Technology Has United

Wind the clock back to 1998 when you had companies that were engineering their own applications based on their specific framework and solving their own unique problems. The customers for those products had to buy SAP to handle their supply chain and manufacturing, PeopleSoft to handle their HR systems, and Siebel for CRM. They required all of these different, disparate application sets to meet their business needs in each application area. All of those products had their own application framework. There was a tremendous amount of disparity in any sort of cross-functional requirement that may have come across any one of those application areas.

If I were a CFO, I wouldn't want to see just how we were doing in manufacturing. I would want to know the up-to-the-minute head count, cost for employees, and CR customer acquisition costs. I would like to see all of the things that might come as a compilation across all of those disparate systems.

The days of customers pouring millions of dollars into buying and customizing these "stovepipe" proprietary enterprise applications is giving way to a new environment: companies are building composite applications that provide interaction with their various backend systems to their employees, partners and customers. Technology has united to make the development of these applications possible.

Enterprise application vendors are breaking down their previously massive applications into a set of low level, standards-based components, which can be combined into customized applications that leverage data and functionality from disparate back end applications.

Much of the value of these applications comes, not only from providing centralized access to applications, but providing it in a customized, role-based manner, which creates a highly tailored experience for each user. To build these applications using traditional software would be time consuming, error prone, and difficult to maintain as the application grows or changes. Traditional software simply does not lend itself to building dynamic, role-based composite applications.

The industry is moving towards "Adaptive Software", which is the key component that makes it practical - for the first time - to build composite applications that adapt to various user roles or application contexts, allowing any aspects of the application - including the data, the processes, and the presentation - to be customized, on-demand, for individual employees, partners, and customers.

With Adaptive Software, companies with heterogeneous environments of enterprise applications, infrastructure software, and portal software can take advantage of the trend towards componentization and standardization to increase efficiencies, lower costs, and improve customer loyalty, by more fully leveraging the systems they already have in place. Software companies and enterprises alike are talking about e-business on demand and the adaptive enterprise.

A Lasting Company

Often, technology is innovative, and there is a demand for it, but unless a company's management has the ability to adapt and change its offerings, that company will not survive.

Look at companies like General Electric, General Motors, or IBM. Today, IBM is a leading technology company with a significant portion of its business in software, but they began with weighing scales, typewriters and various electro/mechanical business machines. Companies that can adapt to changes, as IBM has done, have the potential to exist 100 years from now.

Bowstreet's growth and early successes were based on understanding how companies intended to conduct business with other companies, and enabling systems to accommodate the dynamic change that would be required in such an environment. For companies to stay competitive they needed to develop application programs that allowed them to interact with third party company computer systems to obtain information and services. This was the beginning of Web services, and Bowstreet is appropriately credited as having invented this technology and created this important category.

Bowstreet was born on the premise that it could help create XML-based standards and other industry standards, so that rather than having to integrate all of those different applications, we could enable an end user to benefit from all of them as though they were in the same application framework, but without the cost of integrating them. They could spend a fraction of that and get the same amount of interoperability across those applications using Web services.

Bowstreet initially realized tremendous success in this market, and raised a record amount of venture funding to lead this category. But Web services failed to materialize once market spending was suspended in 2001 and the company focused its energy on finding new markets for its innovative technology.

Bowstreet saw a growing opportunity in the application development space. In particular, the need to rapidly build and change portal applications had a growing importance in this new economic landscape. Portals were becoming more sophisticated and were being used to connect various, disparate backend applications. As the use of portals developed, it became clear that out-of-the-box portlets would quickly fail to meet customers' needs. Developers starting looking towards customized portlets to tap into legacy data and other backend systems. But these portlets were not easy to create, and of equal importance, very difficult to change. IT groups had to look to J2EE experts, who spent long hours developing these portlets. Bowstreet saw the need for development tools that would simplify the creation of portlets with dynamic change capabilities, and significantly improve the end result.

Bowstreet introduced Bowstreet Portlet Factory in Q4 2002 as a dedicated portlet creation tool that addresses the challenges faced by application vendors that need to build portlets. Portlet Factory's ease of use and advanced development features dramatically streamline the entire portlet development process, enabling developers to deliver highly flexible, configurable portlets in a fraction of the time and at a fraction of the cost required today.

Unlike portlets created with RAD or "clipping" tools, Bowstreet-powered portlets are dynamic, robust J2EE applications that can be easily modified by customers in real-time, to meet their unique business requirements. By eliminating the need to write code that handles the various customer requirements, Bowstreet Portlet Factory simplifies the development and change management process, saving application vendors time and money, and freeing developers to focus on more important, strategic work. The importance of this innovative technology is demonstrated by the fact that IBM, as well as other industry leaders, now sells Bowstreet products on a worldwide basis.

Bowstreet has remained agile in order to thrive on change. We have been able to modify ourselves to meet the requirements of a shifting market with unique, patented software, and a basic technology that has not fundamentally changed. We have adapted this technology around a new and unique model, and adjusted the way we promote this technology to the marketplace.

If we had not adjusted, it is quite possible that we would not be around today. There are many companies that were not willing to or were unable to adapt to changing market dynamics that don't exist anymore.

Risk in the Marketplace

To be an innovative company, you have to take risks. Let me be very clear to separate putting your customer at risk versus taking risks. In order to be a lead innovator of technology, you have to experiment and invest. We are funded in a way that affords us the opportunity to look at investments in a three- to five-year cycle. We have no expectation of getting a return on the money that we invest in software for as many as three years.

We have a three-year technology investment strategy we call "seed, succeed, and standardize". In our first year, we purposely go out and seed the market as a loss leader. In the next year, we focus on customer service and concentrate on making all of our customers very successful with our product. By the third year, we expect to have set an industry standard with our technology and customer service.

When companies begin to standardize on our products, we begin to change the economic equation in our business model. Few companies are funded in a way that allows for such investments over extended periods of time. Private companies by and large are not, and we have had the good fortune of raising more money privately, than most companies raise in public offerings.

We take some risk in how we develop applications. We study potential trends in the market place, and we invest and try things that other companies might be less likely to do. Ultimately, we are active participants in XML standard bodies, as well as the new portal development standard called JSR 168. Rather than leading our customers out on a proprietary tangent, we make sure that anything that we produce is in line with industry standards. We have either helped establish those standards, or we have studied them and participated in the development of them in a way that puts us on the forefront when they do emerge.

I would say that we have a tendency to be aggressive in how we progress in the development of software, but conservative when we ultimately produce the product for our customers because our customers are generally conservative. They are large financial institutions, insurance companies, and manufacturers such as AIG, MetLife, General Motors and General Electric. These are companies that want to be early, but don't want to be first. They don't want to be, and don't need to be, on the bleeding edge of technology changes.

Since we either establish or adopt industry standards, we are probably through an 18- to 24-month cycle from the time the product was originally conceived until the commercial product is produced. That has been typical for us. We introduce point releases through out the cycle in order to provide updates. For example, we recently released version 5.6 of Bowstreet Portlet Factory. Typically we produce major new version of product every 18–24 months.

The Customer (And Therefore Customer Service) is Still King

In the business world, there is nothing more important than customer service. The best customer is not one that we never hear from, but one who, if they have a problem of some sort, will come to us. We are often the glue between lots of disparate systems. Databases change, workflows change, vendors change, and products upgrade, so eventually customers will run into a situation that requires our assistance.

We like to be, and ultimately want to be, measured on the way that we service our customers. It is our goal to make sure that all of our customers are 100 percent successful with our product. We use the term internally that they are 100 percent "referencable". Only then do we feel like we are fulfilling our end of the bargain and meeting the needs of our customers.

Public vs. Private Companies

As a private company, we are not under the scrutiny of the public market, where you can't afford to take risks and make those kinds of investments in your customers. Bowstreet probably has more money than most public companies have ever raised, but we don't have the scrutiny of having to meet short-term (quarterly) objectives. We have an opportunity to make long-term investments in our customers and, therefore, in our future.

It is more difficult for private companies starting out today. The days when a small company could raise a couple of million dollars, build something interesting, field an enterprise sales organization, and start to achieve momentum are gone.

Publicly traded software companies today are up against a very scrutinizing, very difficult market. It prevents them from investing in their customers because the financial markets will punish them for it.

Skills in Highest Demand

Only just a few years ago, there was a large market demand for developers skilled in enterprise applications such as SAP or PeopleSoft. As a result, many developers rushed to learn these enterprise products and the technologies (such as ABAP) required to customize and extend them.

Today, the tide has changed. The demand for developers skilled in proprietary application frameworks is over. This is due in part to industry consolidation and open standards. I believe that the market is going to come down to a handful of vendors. Microsoft and IBM will clearly be part of that exclusive group. If I were an individual today looking to build a career path around software development, I would try to hone my skills, not with some unique, off-brand application framework, but with technologies that are at the heart of IBM's roadmap, or meaningful in the IBM ecosystem, such as third-party software tools that compliment IBM's strategy for selective market dominance.

Bowstreet is investing heavily in expanding our developer community, since we have a rapidly growing number of application software developers who use the Bowstreet application development tools. We want them to be well trained, well educated, and to have access to the best tools and resources available.

To develop using Bowstreet tools gives a programmer a unique set of advantages working inside of the IBM model. We have a community portal for developers, and we have a dynamically growing list of people who are adopting our tools, not just because they are Bowstreet tools and Bowstreet developers are in such high demand, but because they are IBM tools as well. IBM is re-selling our tools supporting the products and the developers who use them, and companies in the new economy want skills that are IBM-based.

That is also true for Microsoft. Developers with skills specific to companies in the Microsoft ecosystem are far more attractive than off-brand products. They have, for instance, far more marketable skills than if they were the once sought after PeopleSoft programmer skills.

Developers are far better served by going out and acquiring skill sets for industry leaders such as IBM and Microsoft, and the companies in their inner circles.

No Advice - Sharing Experiences

I don't like to give advice, but I am happy to share my experiences with people, so they can learn from those experiences and apply it to their own particular circumstances.

Running a software business is a complex challenge. There are no silver bullets. You need to have a long-term view and maintain good metrics around your business. You have to make a successive series of smart decisions, and a little bit of luck doesn't hurt either.

People complain about the behemoth software companies, and that there are no more opportunities for smaller vendors. I disagree. Young software companies starting out today have some tremendous opportunities. Without the burden of needing to satisfy existing customers, young vendors are free to architect innovative, flexible solutions and technologies. Further, larger companies are typically slower to react to market needs and have difficulty being innovative. As a result, there will always be the opportunity for smaller companies to correct the deficiencies of larger companies and to fill in the 'holes' or gaps in their offerings.

The late 1990s were full of unrealistic expectations for many companies and the people who worked for them. Companies were easily intoxicated by the false successes brought on in this era, and frankly, the hangover is lasting longer than most had predicted. Rapid innovation and change is great, but remaining grounded and focused on fundamental business principles is essential to the long-term success of any company.




The CTO Handbook. The Indispensable Technology Leadership Resource for Chief Technology Officers
The CTO Handbook/Job Manual: A Wealth of Reference Material and Thought Leadership on What Every Manager Needs to Know to Lead Their Technology Team
ISBN: 1587623676
EAN: 2147483647
Year: 2003
Pages: 213

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net