Why Choose Microsoft for your Portal?

    Whether you're a business or technical decision maker, it's important to think about what's important to your organization when making a software decision. For most companies, software is an enabler of business. That is to say, your company is probably not in the business of making/developing software, but rather using software to run your business.

Since I'm most familiar with the Portal space, my remarks are specific to Portal software. Nevertheless, many of the same suggestions and concepts apply to other areas of enterprise software as well.

As a part of the Portal PMG at Microsoft, I very frequently get asked, either directly or indirectly, Why Microsoft vs. another vendor. You will be surprised to learn that this doesn't just come up professionally, but many times socially, when I'm with friends who work for companies in the process of making software related decisions.

Before I respond, I'd like to make a few comments to all decision makers in organizations looking at purchasing software:

1. RFI responses, while they are a decent filter, cannot be the only criteria for choosing software. At best, they are analagous to standardized tests as they put all the vendors on the same playing field. In reality, however, you cannot use an RFI as the decision maker since each vendor will, almost always, say "YES" to everything. The reason for this is straight-forward: you can make almost any software package do what you want given enough development, time and money.
My suggestion to you: ask the vendors for a Proof of Concept (POC) after the RFI process; give them a fixed time period, same hardware and base OS; let them build it from scratch in a fixed time period.

2. Demos are an excellent way to see the technology in action and how the software can meet your needs. However, keep in mind that they are demonstrations - not enterprise deployed software. Demos are highly customized solutions and can be very deceiving if you take them at face value. Demos *always* make a good impression on decision makers, but that's all they are, demonstrations. Customers need to really understand what is OOB and what is not when they see a demonstration. Vendors with strong services arms and niche vendors (believe it or not) tend to spend the most time on their demonstrations.

3. This is possibly the most important point: Partner expertise. If you are working with a partner, chances are, they are going to be biased. They will prefer a specific vendor based on their expertise and relationship with the vendor. While it is important to make sure your partner has the experience, you cannot choose software solely based on your partner's expertise. You need to think about the total TCO and time to deployment. This may mean re-evaluating the partner for a specific project; this could also mean re-evaluating the software. Needless to say, don't choose software that your partner doesn't have any experience with. You need to really think about this balance.

4. Schmoozing doesn't mean good software. If the vendor takes you out to nice dinners, golf, et cetera, don't get influenced. This is common sense, but important to point out. Also, just because you are using a particular vendors software for one project, doesn't mean you have to use it for another project. For example, if you are using one vendors ERP system, that doesn't mean you have to use their Portal software. While it may provide better integration with its own software, it may not be what you want to use for your Portal platform.

5. In house expertise. This is similar to point 3 - what are your developers, IT Pros and end-users used to? Is it working for you? You really need to think through this. Sometimes it's important to make a strategic change (look at #6) that forces in-house change. A good example is making a move off of legacy software. Folks in your organization might be used to it from a maintenance, development and end-user perspective, but if it doesn't do what you want, it's time to re-think the platform and understand that this will also require training.

6. What is YOUR Portal vision? This is -extremely- important to think about. A very common customer question to a vendor is "what is your portal roadmap?" That's a great question, but equally great is the question right back at the customer "What is YOUR roadmap?" i.e. what is the customer portal roadmap. You MUST know what your vision is so you can develop a strategy for it. You should not ask an open ended "what is your roadmap" without knowing yours. There are some companies that are VERY good at this... I've met them and they are superb. Most, however, don't have a roadmap but are very keen on learning about the vendor roadmap. Know your portal vision. Lack of vision typically implies lack of strategy that has an impact throughout your organization at every level. For example, let's say your developer is about to develop a Web Part/Portlet that integrates with a back-end system. If your vision/strategy doesn't explicitly state single-sign on, the developer might use his own mechanism to login to the backend system; possibly even hardcode (yes, don't be surprised) a username and password. Have a vision. Have a strategy. Make sure the software vendor has a complementary strategy.

Ok. Now that I have given *some of* my unsolicited advice, here is my response to the question: Why Choose Microsoft for your Portal? As I stated above, the reasons I mention below have nothing to do with specific features... rather larger issues that companies must really think about. Most software has a similar set of features, so organizations should look at the bigger picture. In no particular order of importance, here are a few of the reasons (and things to think about) why you should choose Microsoft for your enterprise Portal:

1. Integration with Office
Microsoft has a strong focus on Information Workers. Information Workers play a very important role in every organization. In the context of portals, if Information Workers can easily find content, create and share content with others in an organization, this greatly improves their individual productivity -especially- if they can use the tools they are most familiar with. In this particular examples, that's office. This means less training and more use of the Portal as it's integrated in their environment. How does this translate to hard ROI - let's say that you save a conservative 2 hours a week for each IW worker. That translates to a 5% of cost savings for your IW workforce.

2. Lowest Total Cost of Ownership (TCO)
It is a common practice for organizations to make software decisions based on cost. It's also understandable. The reality is that organizations typically have a particular budget for a project that they must stick to. But, total cost is not equal to the cost of the software. As obvious as that sounds, most decision makers are confined to their budget; this budget is typically part of their fiscal budget. What this means is that some customers end up spending A LOT more, long term, on a particular solution with budget controls. As counter intuitive as this sounds, it's rather straightforward.

Cost is the sum of software licences, services, maintenance and training. Service cost spans over  many months, if not years, and services is always a good portion of the cost. Depending on the software, the ratio could be 4:1 for services:software costs. In fact, some vendors, especially niche vendors or vendors with a large services organization, will reduce their cost of software. Why? They want the services contract. So why do organizations fall for this trap? Assume you are a decision maker with a hypothetical budget of 50k. Let's say one vendor charges 80K and the other charges 40K. Even if the vendor who charges 80K will lead to lower TCO (less services, maintenance, et cetera), you are compelled to choose the 40k because that's what you have today... and next year, you can pay for the services.

Microsoft is a software company. Its goal is to develop software. While Microsoft does have a strong services sector, MCS, its primary purpose is to help partners and customers architect the right solution. Microsoft relies on its partners to develop and deploy solutions. What this means is that we don't play the game of reducing software costs so we can make more money on services. We want to provide the best software and out-of-the-box experience (less customization).

You *really* need to think about cost. Cost doesn't just include software, services and maintenance, but also training. Will your business users be able to use the software? How about your developers and IT Pros? Is there a good community for your users? Choosing a niche player can result in having a lack of community which means a higher training/maintenance cost long term.

Something I almost forgot to mention is the choice of operating system. Many, many people will argue that Linux is cheaper than Windows. Again, the cost of the software - maybe. The long term costs to get the same value that Windows provides + maintenance/supportability, a lot more. Choosing Linux over Windows, depending on your expertise and goals, can be a penny wise, pound foolish decision. Think about what this means long term - not just the one-time cost of the actual software.

3. Most Secure, Scalable and Agile Platform
I have heard people argue about whether .NET or J2EE will win in the future. The reality is, based on analyst reports, the world will consist of .NET AND J2EE. So if you are trying to choose the winner/market leader, that's really the wrong approach. The correct approach is choosing the technology that is right for you.

So why should you use .NET vs J2EE for your portal? Here are some of the things to take into consideration:

1. Great developer community. Over 8+ Million Microsoft developers, dozens of community sites and countless samples, books, articles.

2. The best, bar none, development IDE. Visual Studio.NET 2003 (and wait until the next version!) is unparalleled. Even when I used to develop J2EE applications back in the day before the .NET Framework was released, I used VS.NET. VS.NET allows developers to rapidly develop applications whether they are web, windows or web services.

3. ASP.NET is the killer technology of the last few years. Developing a web application is like developing a VB/Windows application. It is performant, easy to develop and highly scalable. ASP.NET in combination with VS.NET is the winning formula to development. If you don't believe me, ask your Microsoft developer and Java developer to develop an application in a given amount of time. You'll see what I mean. Java does not have a standard IDE...in fact, many Java purists will use emacs or vi to develop Java applications. While that's admirable, it's rather foolish in my humble opinion. There are better ways to showcase your brilliance. Tools greatly enhance developer productivity.

4. .NET Framework and ASP.NET 2.0 are going to change the way we develop web applications. For example, Web Parts (Portlets) are part of the framework. To learn more about it, take a look at the beta of Whidbey (codename for the next version of VS.NET and the .NET Framework) today - there are also many articles on it.

5. Analyst studies show that over 50% of enterprises use .NET. You are in good company.

If you haven't looked at .NET, I encourage you to do so. Let me address some of the reservations that many companies have:

1. Most of my developers are Java developers.
   No problem - C# (or even J#) is very similar to Java. With VS.NET intellisence, you can learn as you go... many of the concepts are similar to Java.

2. Most of our apps are Java apps.
   As I mentioned earlier, we live in a world and will live in a world of .NET and J2EE. I encourage you to use .NET for your portal applications - you will see the developer productivity enhancements immediately.

3. I heard Java apps perform better than .NET apps.
   That's a myth. In fact, you can find studies that show the contrary. The truth is that how well an application performs depends on how well an application is developed. Since VS.NET is a killer IDE, development and testing times are much less allowing developers to write good code quickly.

Ok. Now let's talk about Windows. Most decision makers, because of their personal experiences with the Windows client (blue screen), are under the impression that Windows is not Enterprise ready. Again, that's a myth and there are thousands of case studies to prove otherwise that you can look at from http://www.microsoft.com.

There are many people, many, that dislike Microsoft products and technologies for no reason whatsoever. I recently ran into someone at a social gathering who went on and on about Microsoft. When I asked him why he didn't like Microsoft, I just got a blank stare. Nothing. He then tried to make a joke out of it, "Doesn't everybody?". I don't think he knew that I worked for Microsoft.

One of the things that people frequently talk about is how Microsoft Windows is not secure. In the past, especially before the Internet *really* took off, Microsoft tried to make the customer's life easy by turning most things "on" in the Operating System. This basically meant it was -easy- to do different things - set up/receive/send email, share files, et cetera. However, this did create some security holes. So now, Microsoft turns most of these services "off" by default. Also, Microsoft has made a tremendous investment in Microsoft Security Update technology which means you will have the latest and greatest security patches at all time - you cannot say the same for other operating systems.

4. Leveraging Existing Investments
I wrote a rather lengthy blog entry a couple months ago about integrating SharePoint Products and Technologies with other technologies. I encourage you to read it at http://weblogs.asp.net/arpans/archive/2004/10/12/241573.aspx. It covers a lot of content on how you can integrate WSS/SPS with other systems.

The additional points, beyond my blog entry, that I will add:
1. Publishing and Consuming an XML Web Service with VS.NET is *easy*.
2. Host Integration Server (HIS) and BizTalk Server provide hundreds of adapter to integrate to other systems.
3. ADO.NET allows you to integrate with any DB. Several customers who have non-SQL Server databases complain "oh, I have this database, or that database, and I can't integrate to it." Wrong. You can.
4. Last point (there are many, but I'll end at this point), is that there are 100s of Web Parts for the SharePoint platform either out of the box or in the community that you can leverage. Other vendors may say they have 1000s. Well, if you count the ISV web parts as well as the data view parts you can create with FrontPage (without writing a single line of code), SharePoint Web Parts out number the others.

Irrespective, the reality is that no matter how many web parts/portlets are out there, the reality is that you will have to customize the code for yourself.

So why Microsoft? Because Web Parts are simply .NET Server Controls, you can leverage any/all the .NET samples in the community. Also, when the next version of ASP.NET releases (codename Whidbey), Web Parts will become ubiquitous - everyone will be developing them.

5. Viability and Portal Roadmap
You must think about a company's commitment to its software when you make a decision. What if, for example, the company doesn't exist 5 years from today? Also, needless to say, you need to think about how serious the company is about Portal; how much are they investing?

Microsoft is very serious about Portal. The latest release of SharePoint Products and Technologies is proof of that. We use our own technology (over 25,000+ My Sites, 60,000 team sites, SharePoint Extranets for partner collaboration, et cetera) and it has greatly improved our organization's productivity and reduced our costs dramatically. And if you still don't believe me, Steve Ballmer, who some argue is more of a credible source than me :), very recently said in a presentation that "SharePoint is the number one product at this point in the history of Microsoft... We expect $400 million revenue from that product line, faster than any other product in Microsoft's history."

So yes, SharePoint Product and Technologies are very strategic and we're investing a lot of development, R&D and $$ to make the next versions even better. With over a dozen SharePoint books in different languages, the SharePoint community seems to agree.

Wow. Back to the last few days of my vacation. :-)