Silicon Valley Speaker Series: How WebPutty Is Supporting Microsoft .NET And Enhancing Its Customers' Experience

JAMES BELDOCK: So good morning. So I'd like to talk today about not just WebPutty, but what we're seeing happening in the world of distributed applications, in the world of Web services and in the world of interoperable Web services built highly, highly up time-driven applications.

Now, I'll start by saying that there's a fundamental premise on which .NET, Web services, the entire .NET framework and, in fact, WebPutty's business as well, is built, and that premise is as follows: More and more today our customers find that their laptops take a long time to load their slides -- (laughter) -- there we go. More and more, today our customers find that their software is their business. There's very little distinction today between the manner in which you run your business and that which your software is designed to do.

Now, sadly, in the last few weeks I think we've had this highlighted probably much more starkly and dramatically than at any time in recent history. Business is changing at a lightning fast pace. We all know that if the software is our business and our business changes every day, our software doesn't, and that is the fundamental premise of what .NET, what Web service and frankly what WebPutty is all about. We believe firmly that if you run your business on your software and your business has to change -- just think about how American business has changed in the last three weeks, let alone the last couple of years -- if your business has to change and your software can't, you have a business problem. That's not a technology problem; that's a business problem.

So that's the premise not only that Microsoft is focusing on, but the entire agile and dynamic business software market is focused at solving.

Over the last two and a half weeks, I had the somewhat unusual experience of driving from here to Boston and back, frankly because the planes weren't flying and we had customer calls to go to. So I have 8,432 miles and 23 states worth of customers to talk to you about today. Actually, being a good Microsoft customer, let's talk about how I spent my summer vacation. That's the route I took. That's Microsoft Streets and Trips. These were where we found all of our customers. They are distributed across the country in a number of operational -- you think I'm kidding, don't you? Here we are in Nebraska. We really did make this trip. This was the only way to get the customer calls.

So today I'm going to propose to you a deal. Those of you who are not technologists in the office, every time we come to something, which is technology oriented, we will show you on the middle screen the technology release slide. And the technology release slide will be a picture from our trip with a customer. The rest of the screens will be focused on technology issues. So when you see a picture in the middle, non-technology people, you can tune out. When we get rid of the picture, you can tune back in.

Let's start with the three items that it's my goal today to translate for you and to highlight as the primary goal of .NET, Web services, dynamic applications. If our customers, we're finding, implement these three techniques, they will, in fact, deliver on the promise and the power not only of the Microsoft .NET platform, but of the scalability and robustness and nimbleness that Web services can offer, and also the ability to change their business in real time.

Premise number one: You have to have enterprise ready applications. We can no longer have C: drive, single server applications that run the risk of being disconnected, that run the risk of not functioning, that do not scale. So you need to have an enterprise ready platform. You get that with the .NET framework. You get that with the .NET platform. You get that with the .NET Servers.

Secondly, you have to be able as an enterprise application developer to connect your applications to the rest of the world. No more ivory tower applications where I have to replicate data across 16 servers, all of which is out of date. No more batch files at night. The data have to be live. If they are not live, the application is not useful. So communication and interoperability is crucial, and we all know the building blocks there. Microsoft has provided those in the guise of BizTalk Server and of their entire Web services initiative.

Third and finally, and this is where we find the most fundamental change has to take place, we need to start thinking about our application lifecycles differently. If I know that my software is my business and I know that my business is changing all the time, well my software therefore has to change all the time.

Interestingly enough, the vast majority of software change cycles in enterprise software in the country are on the order of six to 12 months per cycle. Now, there's no other part of your business which you would allow to lag 12 months behind the market. Think of what would have happened had various Silicon Valley companies not moved to contract their spending when the NASDAQ market downturn took place about a year ago. Think about what would have happened had they waited a year to make those changes. They'd be out of business. Look at the airlines now. They had to move within 10 days of what happened two and a half weeks ago. Nevertheless, we as technologists allow our software to run six to 12 months behind the times. It's not realistic, not a good way to run a business.

So the fact of the matter is that change is a fact. It's a fact of life and we need to build software that maps to that change repeatedly. Now, that doesn't mean we need specific technologies; it means that we need a new mindset. And so that's what certainly we are challenged with, what our customers are challenged with, and frankly it's a concept and a hurdle over which we think the market is going to have to leap before the massive adoption of .NET, Web services and agile applications will really come to fruition.

Actually, we're going to stop here on these three points, and if you'll look at the center screen, let's talk about what one of these rapidly changing agile applications looks like. This is a sales force management application. It happens to be running on .NET. It is running Web services. And it is a classic case of an enterprise-ready application. What does that mean? It's running on .NET framework. It's running on .NET servers. It's also up all the time. This is a scalable, repeatable environment. We can deploy this to 15 servers as soon as our demand increases.

Josh is going to scroll up and down on the screen here. You'll see that what potentially this application allows me to do is send my sales force out into the field into different locations. So I as an executive sales manager can decide who in my sales force is going to cover what accounts, how much it's going to cost for them to travel to those accounts and see if they're available.

So Josh is going to go take a look at our customer pipeline. These are the accounts that I think as a sales manager for an office supply company I'm going to close in the next month. And Josh is going to go try to set a meeting at an account that has just called us and requested that we send a sales person.

And as Josh enters the date and clicks on "get available sales reps," something very important is happening here. This is point number two if you look over at the slide over here. We've talked about availability; that was point number one. Now we're going to talk about communication and interoperability.

This application has just queried two different back-end databases and one, actually two Web services. So let's talk about the two different back-end databases. One of those back-end databases is the CRM system. The other back-end database is my HR system. The HR system knows about my sales rep. The CRM system knows about my customers.

Then WebPutty and this application went out and talked to the Web services that define two different things. First of all, it's consuming Microsoft's "HailStorm" services to access the calendars of these sales force members to figure out whether any of those sales force members is available to go to that. And then secondly it's accessing a Web service to calculate the distance between locations.

Now, in this case what we've done is something very simple. We've calculated the distance using a mapping Web service and then multiplied by 32 1/2 cents, the IRS standard for reimbursing driving time. Nobody would be dumb enough to drive from California to -- oh, so I did, but normally nobody would. And in a moment we're going to focus on how I would change this application, instead of driving to calculate the flight costs and then to calculate in also the time difference, which is involved in air travel against driving travel. All of that will be done by integrating a number of Web services, and so this application has to deliver not only on point number one, which is enterprise availability, but point number two, which is communication and interoperability with a number of different existing systems.

Point number three is probably the gating factor. We believe it's the gating factor. It means that if I need to change this application and my IT group already has a backlog, which on average is nine to 12 months in this country, then I can't change this application fast enough to get done what I need. I might as well not even try, because by the time I change the application it's nine months after I make the request and by that point the change is out of date.

So as we get on, we will talk a little bit in the next couple of slides about how we can address the problem of latency for changes, because it is change latency, which restricts application software from meeting the precise needs of your business.

Let's start however by drilling down on number one and number two; first of all, enterprise ready applications. The business reasons are pretty straightforward. If I'm going to rely on this software to run my business, I've got to have software that I can rely on. Just think about what would happen is a call center for Citibank suddenly was unable to access your credit card records. It's not acceptable. They'd go out of business pretty quickly if they could not manage all the requests that come into their system. So software you can rely on is crucial.

Secondly, any software that fits your business -- I think we are all familiar with the classic buy versus build dichotomy; do I buy my packaged application or do I build a custom application. The Gartner Group has a fascinating study on this. They say that in the first year packaged applications deliver 90 percent of their functionality out of the box and 10 percent of their functionality is customized. Three years later, the Gartner Group says those same applications in traditional enterprises have been customized to the point that 90 percent of their functionality is now custom and 10 percent of their functionality is out of the box. So in the space of three years, even if it is a packaged application, your applications have been customized in the enterprise to such a point that it is those customizations that are running your business.

So if you don't have software that fits your business, you will end up running your business in a commodity manner. Why? Packaged applications, for them to work, have to be sold to more than one person. So if more than one business buys a packaged application, then more than one business runs their software the same way their competition does. You get competitive convergence. It's not realistic. Everybody in the business community knows that. We all know that here. Therefore customizations are the key to making packaged applications work. The problem is that customizations are costly.

So that's where the third point comes in. There is a balance between customizing software and adding profit to your bottom line and revenue to your top line. And so software that adds revenue to your top line, that might be software, which nimbly allows you to enter a new market; make a change to your software, enter a new market. Software that adds value to your bottom line; how about expanding your supplier matrix so instead of buying from one supplier you buy from five. What happens when you buy from five? You can perform price arbitrage. You can drive costs down. I've reduced my operating expense. I've suddenly added to my net profit.

So those are the two sorts of changes that you would need to make to software to enable higher profitability.

Here we are. This is the CEO of Select Comfort in Minneapolis, Minnesota and we'll talk about technology while the non-technologists in the room have a look at Minnesota and our various stops.

So let's talk about technology. What do you need to do to have enterprise-ready applications? You have to have scalability. Well, you get that from the .NET platform. You absolutely have to have the ability to redistribute functionality. By that, I mean hypothetically I've merged companies. I have two different platforms. I've got a whole set of C++ code running and a whole set of Cobol code running. Common language runtime in Web services will allow me to redistribute that functionality in a logical manner within my enterprise. That's crucial.

Secondly, I can reassess the boundaries within my enterprise. What departments do what? Traditionally, enterprise software has been built for the servers on which data are physically located. Interaction and interoperability across continents, across data barriers, across firewalls is tricky. Frankly, the .NET framework makes that an awful lot easier.

Plan for redundancy. Well, we all know that that's what application center is for, the ability to deploy an application or a stack of applications in run time.

Finally, increase interoperability. There are two ways to do that. We all know about BizTalk Server. That's the best way to do it for traditional and legacy applications, and the going forward Web services are, of course, the key to building out an enterprise-ready application.

Okay, no more technical slides. There we go.

Let's talk about communicating and interoperating. First of all, communicating and interoperating from a business perspective is crucial because I have to be able to leverage the abilities and the expertise of outside organizations. I'm a manufacturing company. I make the bottles of water that we see on the table here. I am not a shipping company. I don't do logistics. But if I use FedEx and I use FedEx's Web services, I've suddenly become a shipping industry expert. Why? Because their expertise is delivered to me in a transactional manner over the Internet as a Web service and suddenly I've expanded the expertise of my business without adding personnel, without adding costs, essentially at zero marginal cost.

Secondly, I've been able to expand my business network. Again, we talked about increasing supply and demand from one set of suppliers to multiple sets of suppliers, driving down costs as a result. And then, of course, by opening up communication channels and increasing interoperability I can enter new markets. I can sell overseas. I can sell into states that I traditionally don't sell into because they're difficult to manage because of time zones.

All of those different business opportunities are opened up to you if you are, in fact, running an environment that can communicate and interoperate with other servers.

However, on the technology side of the equation -- there we go, Toledo, Ohio with a major contract manufacturing firm, back to the technology over here. Interoperable and dynamic applications are great, but there are some technology challenges and therefore some opportunities for growth as a result of those.

First of all, UDDI, WSDL and XML and SOAP are key enabling technologies and key enabling core competencies. They have to develop those. They have to develop them fast. And frankly those are the technologies that we find our customers out in the field, including these guys, focused on the most.

Secondly, and this is really a crucial point, refactoring is going to play a major role here, and this is one of the techniques that we talk about with our customers regularly. Refactoring means I need to reassess what granularity of logic, what granularity of encapsulation I expose to the public. I need to reassess essentially different types of transactions. When I'm traditionally building an enterprise application that a human is interacting with, I can, of course, maintain a dialogue with that human. They've got a mouse, got a keyboard. They can enter; I can respond. If I'm building Web services, I don't really have that capacity. I may have long latency; I may not have long latency. I may have the opportunity to talk once; I may not have the opportunity to talk once.

So the old paradigms of dialogue versus batch files are starting to erode and there's a continuum now between dialogue and batch file that Web services enable us to handle, but they present challenges to enterprise architects primarily because existing systems aren't built for them and you need to rethink your interaction paradigm. You need to rethink your data dependencies as a result.

Finally, tightly-coupled integration, which is the pre BizTalk and pre Web services approach to integration, is highly brittle and, in fact, is brittle enough that changes to existing applications tend not to be made, because those integration points are so brittle. So loosely coupled integration we are finding is a major driver for customers, a major driver for our customers, because loosely coupled integration means not only can your applications be flexible but your integration with existing applications can be equally flexible, and we saw that in the demonstration earlier.

Ah, here we are in Winnemucca, Nevada. By the way, these people have the nerve to have a south Winnemucca and an east Winnemucca; total population of three. (Laughter.) That was not where we had the customer.

Moving right along, what do we tell our customers to develop competency in? First of all, get .NET now. Don't wait. Get the framework. Learn about common language runtime. In particular, learn about C#.

So a couple of points of reference: For WebPutty, we've seen some remarkable improvements in our ability to deliver software. We've revved our server software to take advantage of the .NET framework, and we've seen a 67 percent delivery time improvement -- I'll say that again, 67 percent delivery time improvement over traditional coding mechanisms using Visual Studio 6.

Secondly, in C# we have seen a 30 to 1 speed improvement from Java to C# -- 30 to 1. And we've seen that in a number of different types of servers and we've seen that in a number of environments. So there are real, tangible and substantial benefits to using CLR, the .NET framework and C#. And if anybody is out there thinking about making the shift and not sure, come talk to us. We've done it. It works.

We also encourage our customers to look very seriously as ASP.net and ADO.net, not just because they're cool new technologies, but because they will enable types of applications you previously have been unable to deliver.

Finally, we encourage our customers to look technically at WSDL, at UDDI, at SOAP and at XML. I think these are all by now acronyms we're all familiar with, but there is a technology curve here, and the resources at the bottom are the ones we point our customers to to get up on that technology curve.

So we've talked about the first two in the troika of preliminary requirements before you can, in fact, deliver on the bottom phrase, software for the agile business. Interestingly enough, even though we all know that Web services and dynamic applications and agile applications are the future, in 8,000 miles and 23 states I ran up against CEO after CEO and CIO after CIO who had the deer caught in the headlights look, and it's not because of my driving. I saw people who knew the future of their business was Web services, who knew the future of their business was distributed applications. I saw the CEO of a Fortune 500 healthcare company tell me that they are a Web services company. I asked them how many Web services they had employed. Zero.

That means that the marketing and the positioning of Web services has been effective. All the CIOs out there know that Web services are the next big thing. None of them has the time to focus on Web services and to focus on changing their platform. They are all frightened by the fact that they spend all of their time dealing with their existing systems. Actually, the numbers are pretty frightening and we think that this is the key to unlocking Web services for your customers.

I like to call this the iceberg economics of application development. Development is traditionally what application developers in large organizations focus on. They think it's the entire problem, but it turns out to be just the tip of the iceberg. The real problem lives below the waterline. It's updates. It's changes. It's migration of those systems.

Developers don't think about that massive body of ice that sits below the visible and sits below development. And you know what, if you don't think about it, it's going to sink you. There's a large ship that went down for the same reason. And the reason it goes down, the reason this is going to sink you is because those changes are insidious. They are repeatable. People get 20 voice mails over the weekend to change things that they changed last week that broke again because somebody applied a patch or somebody applied an upgrade or a network wire went down.

Upgrades, maintenance and changes to applications are -- well, the numbers speak for themselves: 45 percent of changes take over a year to issue; 95 percent of the cost of applications is below the waterline. I see some heads nodding. This is not news. Our customers give us numbers anywhere from 70 percent to 100 percent: 100 percent we doubt a bit; 95 percent sounds about right to us. The fact of the matter is almost all of the time is spent below the waterline, and this is the gating factor to Web services and the .NET platform, and WebPutty and a number of other new technologies. The gating factor is they're spending all their time dealing with what they've already got. They're spending time -- IT shops are -- they're spending time re-implementing current technology, re-implementing features instead of developing new features.

And so that's where the real problem is. If we solve this problem, this group, our customers will deliver more quickly and our customers will move to Web services and distributed applications more efficiently and more proactively.

Incidentally, just think about what the impact of a one-year delay on a business change is. How many people know the MCI WorldCom story? Somebody from the Visual Studio team has to. Okay, MCI WorldCom in the early '90s started the world's most annoying marketing program. Anyone remember "Friends and Family?" So the deal was very simple: You gave them the names of your eight friends and in return for MCI's right to call your friends and bug the hell out of them, they would give you a reduction in your long distance rates. That was the deal. It was a fabulously successful marketing campaign. We're talking tens of billions of dollars of revenue to MCI.

Twenty days into MCI's release, AT & T made a strategic decision to follow. They said, "You know what, this is a good program. It's going to work. MCI is going to make money. We'll do the same thing." It took them another 17 months to deliver the billing software to change their back end.

So if you think about that, some figures are as high as $12 billion in lost revenue to AT & T as a result of missing that 18-month window. So if you think that a 45 percent one-year change latency is not a big deal, that's a $12 billion deal and that was a single transaction.

So let's start to get a little bit more technical. Let's talk a little bit about how this works.

We know that point one, enterprise quality, is delivered by the .NET framework, by the .NET platform and the .NET Server, SQL Server.net, et cetera, and Windows XP. It's also delivered by Host Integration Server for interoperability. It's also delivered by BizTalk Server.

Now, on the right you'll see that communication and integration is delivered by Web services primarily and, of course, by the orchestration provided by BizTalk Server, and by other back-end integration services provided by Host Integration Server. That's a bit of a gray area. You've got one and two on the left and right, but the fact of the matter is they are both delivered by both parts of the platform.

Change, this crucial point, this 95 percent under the waterline aspect of enterprise software, only comes from the humans.

So we've got business users on the left. We all know what those people are. Those are the people who use our software. We have developers on the right. We know who those people are. Those are the people who deliver the software. And the gap lies in the middle, the BDMs, the business decision-makers, the BDMs. So business decision-makers are the people who are experts in their business. They understand, for example, incentive compensations plans. They understand tax rates. They understanding marketing. They make decisions about strategy and tactics for the business.

They, in fact, change the business. They are the people at AT & T who said, "You know what, we're going to go implement the MCI WorldCom Friends and Family competitor so that we can make the money that MCI is making right now." They're the ones that change the business, but they're not the ones who change the software.

And so if they're not the ones that change the software, we have disconnect, and that's where the real problem lies. Right now, developers focus all of their time on maintaining code. They maintain software code that runs on top of the .NET platform, of course, that interoperates with BizTalk, that interoperates with Web services, and it is only the developers who have the power to effect simple changes, to effect complex changes, to effect fundamental changes in architecture. It's all the same; you still need a C++ coder or a C# coder, and the fact of the matter is that most of the business decision-makers have the capacity to use Microsoft Excel. In fact, that's why Excel has a market, because business decision-makers use it.

Oddly enough, they have the skill to make the changes to their models in Excel, but we can't yet deliver them the power to change those aspects of the software that is modeled by Excel on their running systems. There is the disconnect. And if we can deliver that capacity without diminishing the developer's ability, using traditional tools, to develop the architecture and to deliver complex functionality, then we can reduce the developers backlog.

And actually let's talk a little bit about that. Are we going to run the demo? Great. So we're going to keep that slide up here and we'll probably point to it from time to time.

Before Josh logs in and starts thinking about changing things, let's just point out a couple of things. This application has calculated the cost of travel on a driving basis. So other than me, who's really the only person I can think of that would drive from San Francisco to New York, it's probably more effective if we can calculate the flight cost.

I as an executive VP of sales want to know what it costs me to get sales people to accounts, and then I want to have an effect on my policies for what accounts can be serviced by what reps on the basis of how much it costs them to go there. When is that important? Well, everybody knows, for example, that Hewlett-Packard, our friends down the road have stopped all travel allowances? Why did they stop all travel allowances? Because they don't have a system that can do this. They do not have granular control over travel, so they've just said, blanket, don't travel. Well, that's the easiest way to cut costs, but if you want to run your business in a slightly more effective manner, you probably want to make decisions on the basis of your information and therefore you need to change the application.

Now, the sorts of changes we're making here are not very complicated. All I'm doing is saying use the airline fare instead of the driving costs. It does not require a $200,000 a year, fully burdened C++ coder to change that reference. We do it in Excel every day.

I also want to change the sales commission for anybody who's on the road. Well, that's just changing a percentage. We all know how to do that. There is no requirement for the C++ coder for that specific change.

You know what we need the C++ coder for? For the back-end integration to the applications.

So what Josh has done is he's moved and he clicked on the manage button and he's now looking at the tasks, which this specific user is enabled to perform. Developers developed the ability for this user. If you look over here on the right, if you look at number three, the developer on the right with the laptop gave this specific user the ability to use this wizard to change things.

And so the value here is, in fact, that we as developers can granularly identify within our business the types of changes that specific business decision-makers are allowed to make, and we can deliver a task-based interface, which enables them to access, for example, Web services here and grab the airline flight information service that we have already started to use as developers.

So we as developers, Josh is going to add that specific price. He's actually replacing the price field with a price, which is parameterized from that same screen by the from and destination values on the grid and he's hit "finished." And when he goes back to the application, actually you will see that when he goes back into the pipeline, instead of seeing prices for driving, he'll enter a date, he'll hit "schedule meeting" and, in fact, now you'll see prices that are based -- this is a Web service that is going out and checking airline flights. Oh, look, the prices have changed. These are the prices to fly.

So Josh is also going to change the commission rate for one of the accounts, and he's going to do that by going in and looking at our rules designer, which allows us granularly to give individual users, individual business decision-makers control over values like what's the commission rate -- 3 percent. He's going to change it to -- well, let's be nice, how about 20 percent or 5 percent.

So now I've changed the value of that commission and this didn't require any more skill than frankly I have to modify an Excel document, to modify a formula in Excel.

So if I can granularly provide this level of control to the right people in my organization, guess what, I don't have programmers tied up all day doing this. And if they're not tied up all day doing this, they can get onto more important work. If they get onto more important work, they can implement Web services, they can implement .NET, they can implement more aggressive distributed systems, because they're not spending all their time fixing this stuff.

So let's have a look at what I just did. You know, if that were just the user interface that I changed, this would be really easy. But the fact of the matter is I had to go out and get data from a Web service. I had to integrate it with data in two different database environments. I had to add some business logic. Actually, I had to modify some business logic about commission rates. And I had to present that information to the user in this case through a browser, but it could just as well be on a handheld device or a phone, for that matter.

So, in fact, what I did was not just change a few things; I changed a lot of things. Everything that just turned orange was changed in that demonstration. And that process of making those changes is a complicated process, but it is not particularly creative. It's pretty rote actually. What you're doing is adding a value either to a database or grabbing it from a Web service. You're modifying the properties of a middle tier business object and you're servicing those new properties and a calculation based on those new properties in one aspect or one field of something on the presentation layer. It's not very complicated. In fact, it's the kind of nuisance change that drives IT people nuts. And it drives them nuts because it's boring. It drives them nuts because it's error prone. And it has absolutely no real value to the enterprise; it has value to the business decision-maker, not the IT department.

So what we propose essentially is the following transition. We think .NET and Web services are going to drive the following change. Right now I have monolithic applications. They all live under IT. IT is responsible either at corporate IT or in the line of business IT for every application in my enterprise. Well, sure, I want IT to be in charge of security. I want IT to be in charge of the change queue. I definitely want IT to be in charge of my data architecture. Do I want IT in charge of my PNL? No. I don't want them in charge of my incentive compensation plan. You know what really happens is the CFO for PNL or the sales people for the incentive compensation plan bug the hell out of IT every day. There are 15 voice mails every morning to make changes. That's the problem with current enterprise application software and .NET and particularly Web services, the ability to weave in change will deliver on the ability to pull those applications, which are not IT specific, out into the rest of the enterprise.

So, for example, incentive compensation should live under sales. Similarly, both bill ability and PNL should live under operations. And we all know that pricing ought to live under marketing.

If I can do this, then I can leave -- you see how many fewer things there are for IT to do now -- that means that IT can enforce standards. It means that IT can make transitions to new platforms while the line of business takes care of the changes to the applications, which they are the only ones who know how to make anyway. And so we are reducing the overall workload, in fact not by eliminating the change, but by distributing the change to the responsible parties.

I'll give you an analogy of why this works in business. SAS Airlines, Scandinavian Airlines in the early 80s decided to become the leading business travelers airline in Europe. Jan Karlson, the CEO of the company, decided that he didn't know what would make a good business airline in Europe, so instead of deciding from on high how to change things, he said, "You know what, the people who know the answer to this are the baggage handlers, they're the flight attendants, they're the captains, because they're the ones who are on the frontlines. They get it. I don't get it. I sit in an office all day. They get it because they're there watching the business traveler." So he constructed a business in which everybody in the organization had the capacity to propose a change.

Just look, by the way, at Saturn, the car manufacturing company. They did the same thing. Line workers can go to management and say, "Hey, you know what, it would be better if we did it this way."

Interestingly enough, SAS saw a 30 percent increase in revenue in the first 18 months of their changes. Why? Because the frontline was making smart decisions and the people in the back offices were empowering them to make the decisions.

Now, that's a process that started in the airline industry. It's absolutely wildfire in manufacturing businesses. Guess what, it's time for software to do the same thing. This is called empowering the frontline. If I can empower my VP of sales to change the incentive compensation plan and I don't have to involve IT, the change is going to get made faster. It's more likely to be done correctly the first time. And guess what, my IT people are still enforcing standards and working on architecture, which is what they get paid for in the first place.

So how do you do that? On the right hand side of this slide are the traditional software development best practices that we all know and love. You absolutely, positively have to have a formal change request cycle. You absolutely have to implement source code management and coding standards. You should really concentrate on standard architectures. And you really need to follow a solid build, test and deploy cycle.

So when we went out to the field, we asked our customers, "How many of you do all of these things?" One guy said he did. I didn't believe him. The fact of the matter is people don't have time to do all of this, because they are constantly -- constantly supplanting the items on the right hand column with the immediate change request requirements from the lines of business.

You've got an option: You can either implement your new coding standard today or deal with your CEO who says he needs to change the software by tomorrow. Which one do you pick? Well, you deal with the CEO. So you drop the coding standards. And unless you have a huge budget, and these days nobody has a huge budget, the fact of the matter is you're not going to implement best practices, and as a result of not implement best practices, it gets even worse. It's a vicious cycle. Not having best practices means it's harder to change things.

So there are some easy ways for business units to empower the line of business to have control over granular features within your applications. Again, we're not talking about giving control over back-end data business. We're talking about giving report control so that line of business can change their reports and they don't bother me every morning.

What do we do? First of all, our IT people have to focus on building standardized architectures. They have to focus on what the right modularity is, what the right encapsulation is and what the right levels of granularity and back-end systems are. We have a very good tool for that from Microsoft. Microsoft VisualStudio.net Enterprise Architect edition is great for enforcing those standards.

Secondly, they have to focus on assigning resources to support the line of business, business analysts; in other words, four GL level programmers who can assist lines of business in the point and click modifications that we showed earlier.

Additionally, you have to map out internal to the enterprise what the different roles are now that you know you can democratize the software application lifecycle. Now that we're rethinking it and we're pushing control out to the front line, we have to rethink what those roles are, because we have to have control from IT of what actually happens. Essentially what we're allowing is the business user to manage the software while the IT people control the software, and that's a different paradigm than we have today.

And then finally we need to plan ahead to the fact that access devices are going to change. I just started carrying a handheld Pocket PC, so now I expect every system I talk to to work on Pocket PCs. They don't. There's going to be another one of those six weeks from now. We need to plan ahead for the fact that those things are going to change.

Now, there are a couple of ways to do this. You can either do everything in the left hand column by hand or you can do everything in the left hand column, because it's a process, automatically, and this is what WebPutty, this is what our business is built around. Your IT people on the right hand side frankly don't need a lot of help. What they do need is the reduction in their workload without a reduction in their available resources, and we do that by empowering the process on the left hand side to change from a manual process to an automatic process. That's what WebPutty Server software does. It sits on top of your existing enterprise and allows you to automate the decisions on the left hand side and therefore allows you to empower line of business people to make specific types of changes to their applications.

So let's have a look at how this scenario has changed. It really hasn't changed much. You see, this is exactly the same scenario we showed earlier. We still have .NET and enterprise servers. We still have Web services and of course we still have business users, business decision-makers and developers.

But what's different is that there are now two ways to get at the underlying code implementation. Number one is, of course, Visual Studio. That's the one that developers use. Now, I don't know about you, but I'm not particularly comfortable proposing that my VP of sales is going to learn C# next week. It's not going to happen. However, my VP of sales can use Excel. Why don't I give my VP of sales an Excel like interface to the commission formula? Then I just set her privilege that she can go change it and every time she wants to change it -- and believe me, she changes it once a week -- I don't have to respond. I don't have to return her phone call. I don't have to deal with it. I don't have to rev my application. I don't have to do a change cycle. I don't have to deal with all of the quality assurance issues of build, test, deploy cycles, none of that, because I have an automated process behind my modification cycle that will implement that change for me. That's what WebPutty Server does.

So Visual Studio integration is built into WebPutty Server because we know that developers don't like flow charts. They like code. So developers use code and the rest of us who don't like code use the visual interface to effect the specific changes that we've been granted privileges to effect by the IT group, who's using Visual Studio.

So where do we go from here? There are a couple of things we've got to do. First of all, we absolutely, positively have to get ready for enterprise application software and for enterprise readiness. That's point number one. How do we do that? Well, we tell our customers to go get the .NET platform today. Go learn. Get training. Go to PDC.

Secondly, you have to start expanding your reach. You've got to start thinking about the fact that your business is only as good as the people you can talk to. Your business is only as good as your customers. Your business is only as good as your suppliers. The weakest link between you, your suppliers and your customers is going to be the value of the overall chain. Therefore, increase your reliance on WSDL, on UDDI, on SOAP and XML and understand SOAP, XML and BizTalk Server, because those are crucial to your delivering on the ability to extend your enterprise.

And then finally start thinking about the fact that change is a fact of life, now much more so than ever. Your business changes every day. And if you plan to deliver your software and expect it to stay the same for more than a day and a half, you're kidding yourself. So we tell our customers, "Guys, supercharge your development. Get your development out faster. And then get an environment to distribute the rest of the right power to the rest of the right people." In other words, VPs of sales change commission cycles; IT people aren't necessary. IT people change database architecture; business people aren't necessary. Get the right people in charge of the right things.

And we would also propose accelerate your change. We do that. WebPutty manages that change process for you. Use your traditional tools to do important work for your architecture. Use a change management environment to do the necessary work to keep your business running.

End

Top of page