Robert on Software Development

I’ve been giving a lot of thought to Microsoft Dynamics lately. Microsoft Dynamics encompasses Microsoft’s enterprise software for customer relationship management (CRM) and enterprise resource planning (ERP). Microsoft developed CRM in-house, and bought the ERP applications from various companies so it could compete in the enterprise applications spaces held by companies such as Oracle (which owns Siebel and PeopleSoft) and SAP.

Microsoft Dynamics is made up of five different products: CRM for CRM; AX, GP, NAV, and SL for ERP. Figuring out how the four ERP products differ, and which one to choose, is not immediately clear. Because the products all come from different originating vendors, there’s even some overlap. For example, AX offers a CRM module that overlaps with Dynamics CRM. GP has a ledger built in, but so does AX and SL. And with all these initializations (which stand for the companies that originally developed the apps, such as “SL” for “Solomon”), it’s easy to get the products all confused.

The ERP products are also developed in different programming languages and don’t always fit cohesively into the Microsoft family of products. This makes it quite tough for custom developers like myself to walk into a shop that says they’re using Microsoft Dynamics for ERP. Which product? What customization has already occured? What modules are installed?

While it might sound like I’m being harsh on Microsoft, I’m actually not. I know Microsoft has been working on improving the Dynamics experience the past few years. CRM, for example, is a very polished product and the new version, coming out later this year, runs on SharePoint. I’ve also heard that the Dynamics team is working on new versions of the various products that will be built on .NET, with better Office integration and a lower barrier of entry for developers. As an enterprise IT guy, this pleases me. Microsoft will probably rename the applications once their focus shifts from supporting existing customers to acquiring new ones, so it becomes easier to figure out which application covers supply chain management, for example.

I think the Microsoft Dynamics tools can be expanded beyond their original domain, too. Take CRM, for example. When people talk about CRM, they’re almost always talking about it within the context of sales. A CRM solution tracks and organizes a company’s contacts with its current and prospective customers. But can Dynamics CRM be applied to domains where sales aren’t the objective?

That’s the topic for part II of this series.

I am not privy to the details of SharePoint 2010. But like an upcoming blockbuster movie or expansion to an MMORPG, it’s fun to dream about what might come.

Now I shall look into my broken crystal ball and share you with my prognostications of SharePoint 2010 and beyond.

STSADM becomes a web application
I don’t know how many holy wars this one will cause, but I expect there will be much rejoicing, especially among those who are new to SharePoint development and administration. STSADM is a powerful (and extensible) tool that requires some, well, getting used to, but once you wield its power, you can do anything.

A web-based version of STSADM would make some of the more basic operations a bit easier, such as restoring a content database or provisioning a site. Silverlight would be pretty great for this. A WPF STSADM would be gorgeous.

SharePoint Central Administration is an ASP.NET 4.0 AJAX application
Let’s admit it: SPCA is clunky. The workflow of setting up a server and applications inside it is, well, clunky. A modern, Web 2.0 version of Central Administration would be a wonderful thing. It’d also be nice if CA could recover from my mistakes, but that means I would have to upgrade.

SharePoint sites are containers
Someday, everything SharePoint hosts for you will exist as a container, a self-contained bit that can be easily copied (or moved) from one SharePoint farm to another. Each of these containers will be object-oriented, extensible via code. Yeah, I can dream. And I dream BIG.

Visual Studio supports SharePoint projects
We sort of have this already, but the way it’s implemented is not de facto from Microsoft and you have to get separate implementations for, say, Web Parts versus SPJobDefinitions. Visual Studio will support a fluent interface for SharePoint application development, and support SharePoint interactive debugging natively. It will be a day of much rejoicing.

I’ll add SharePoint Designer integration into Visual Studio (and thus Team Foundation Server) here as well.

Documentation is plentiful and meaningful
This isn’t meant to make a dig at Microsoft, but let’s be honest: SharePoint developer doco is quite anemic. As new versions of SharePoint are released, the documentation will drastically improve and will serve as a starting point for SharePoint developers. Quick Starts will be included as well.

SharePoint will have a brand new .NET 4.0 object model
This is wishful thinking (due to compatibility) but someday we’ll get an entirely new SharePoint object model built on .NET, possibly 4.0 or later. It’d be awesome to have something like LINQ to SharePoint, or even represent SharePoint functionality in the Entities Framework.

ASP.NET MVC will be available for SharePoint
Someday SharePoint will natively support ASP.NET MVC out of the box. You can do this now, to an extent, but I’d like to see SharePoint make its data available in the model (like lists), and give us a way to build web parts as views, and perhaps expose its object model in an MVC-fluent way.

These are just a few of the things I’d love to see SharePoint offer in future versions. I acknowledge that I’ve barely scratched the surface, but my crystal ball can only do so much!

In a future post, I’ll take a look at some of the more technical aspects of SharePoint development and what I’d like to see in the future.

Version control has been around long enough that even people who don’t work in IT are accustomed to it. A few weeks ago I was talking to a friend about “source control” and she asked what that meant. I explained how it works, and she said, “Oh, like SharePoint document libraries.” That made me happy.

While we IT developers have been using source code control for what feels like eons, some of us don’t think about using it at home. For a lot of the folks coming from the world of Visual SourceSafe, source control’s primary benefit is sharing files among team members; ditto for the document library check-out function that my SharePoint-using friend pointed out.

But as homegrown software projects grow more and more complex, it becomes even more important to have a source control solution for those projects. Such began my search for a source code management (SCM) tool. I knew up front what my basic features are:

• Version control
• Merging
• Branching
• Visual Studio integration
• Scalability (needs to support more users someday)

That’s not too much to ask, right? A quick Google search for “free version control” turned up Git, Mercurial, and Subversion. (There were other choices, but they were free only for open source projects.) At work, we use SourceGear Fortress, and I’ve been a user of Visual Studio Team Foundation Server for many years, but those products have costs, and for my simple projects at home, I wanted to minimize my cash outlay.

What I found with Git, Mercurial, and Subversion is that they are excellent tools but are way more complicated than what I need. I really want something with the relative simplicity of Visual SourceSafe but the power of something more like Subversion; this product does not exist without a cost. I really like Vault, but man, $249 for a single license?

I have a license for Visual Studio TFS, but it’s way overkill for just one user. I’d need to run it in a Virtual Server environment and that’s a lot more than I need.

Right after I decided to bite the bullet and use Subversion, I went to close the tab containing SourceGear’s website and something caught my eye:

A full-featured 30-day evaluation is available at no charge — and Vault is always free for single users.

Free for single users? Why didn’t I see that sooner?

Thus ends my quest for a SCM tool that is a) free b) easy to use and c) scalable. If I’m someday able to add another developer to my home project, then I can surely shell out the 249 bucks for an extra license. The Visual Studio integration is tight and I’m very used to it from my day job.

Please note: I’m not trying to slam SVN, Git, or Mercurial. Those are awesome SCM tools. But for the single user like myself, they’re overkill.

What personal SCM tool do you use? What do you use it for?