So I have this development box at home that I use from time to time to try out new concepts. Several weeks ago I installed Windows Sharepoint Services (WSS) on it to play with the latest in Webpart technologies (blog entry for another day). Well tonight I wanted to tryout this idea that I've been having around distribution groups that are stored in AD/AM and managed by individual users via a website. So in order to make this work, I needed to develop a new ASP.NET website. Of course I planned to use Visual Studio.NET 2003 to make this happen, but I ran into something very weird.
As normal, I opened up VS to create a new project. When I tried to do so, I got the following error:
Unable to create Web project 'TestOne'. The file path 'c:\Inetpub\wwwroot\TestOne' does not correspond to the URL 'http://magno/TestOne'. The two need to map to the same server location. HTTP Error 404:
This post moved to: http://agramont.net/blogs/conrad/archive/2004/01/14/14.aspx
For those interested, this seems to be a fair list of the ISV’s that are providing Automation Services to Service Providers:
This is also an interesting read:
I've been working in the provisioning space for about 4+ years now and its pretty interesting to see how the provisioning space and its vendors have managed to always take the same approach. With such a history, you think they would take a different approach or at least a different business model. I won't name any company out, but it seems that provisioning/automation companies take one of two approaches as a design.
High-end Platform - This approach basically means that they create a very complex system with many different customization points. Not only will it provision your services (actually create objects, set security, etc.), but it will also track the state and relationship of the items that it provisions and relates that to an organization and/or a user. This approach is some flexible and complex, that it normally requires the ISV's personal consultant team to implement it for you. Now to build this, the ISV would have had to spend a lot of money in development and testing to make such a product/framework. So by the time they are ready to ship, they are in desperate need for a customer, thus their license model is complex and expensive.
Appliance Application - This approach is normally a web based application that has a fixed set of functionality. In order to make the application easy to use and provide a basic “out of the box” to production experience, the application is "fixed" in the functionality is exposed. While this is great for customers that just want to drop something in and go to production, it also prevents the customer from extending the functionality of the system. The license model for these applications are normally fixed and are bound to how many of that applications that you install within your environment. Some of them also take the same model as the High-end Platform solutions, but the value in it doesn't make it conducive to such a license.
Now I've seen many companies take both approaches or combine the approaches, but they never really seem to take off. Why not? That's kind of hard to tell. I personally think its because of two reasons. First, companies that create these products see a big problem for Service Providers and Enterprises that really seem to have this problem. So they focus on subset of the target market and try to satisfy the perceived requirements of the customer. Now, as a company that built some software to solve customers problems, you might think that your software is pretty hot stuff and that people wouldn't mind paying some cash to solve that problem. Right? Well this is what leads to the second issue. Although Service Providers and IT has issues with provisioning services to their customers and end users, its not something that they need. Let's face it, can enable services today without that software. Now it may be a pain, but it can be done. Trying to prove how much money they will save by purchasing provisioning and automation software is a tough sell, because most shops don't track how much they spend in provisioning today as it relates to user down time (poorly enabled services, calls to the call center, etc.), admin time (the amount of time an IT person must spend fixing issues for services that were not provisioned properly), and customer satisfaction based on provisioning issues. Without IT shops recognizing those issues and measure how much it costs them in time, money, and customer/end user satisfaction, they won't see the real value in spending money to solve that problem.
So what about the approaches? Which one is better?
Well, I think that's an even harder one to answer. It really comes down to what people really need from their provisioning system. When I think of what a complete provisioning system, I think of a system that has a collection of components.
- User Interface - A Web Based User Interface that provides a Data Center administrator to manage their services and customers in all aspects that are managed through the provisioning system
- Execution Engine - The Execution engine is not tied or dependant on the UI, but it provides the central execution of all provisioning actions.
- Audit Datastore - A centralized store of all the historic data that was executed by the Execution Engine
- Workflow Engine - A engine that provides a long running and complex workflows to execute. Some workflow engines will also have an Execution Engine built into its own infrastructure. Other systems will make calls into a separate engine to perform the actual execution of an action.
- Service Relationship Manager - This component provides context to an action and relates any specialized action to be associated with a give organization and/or user.
- Service Extensibility - This feature provides the ability to add in additional services into the base system. This is what allows the IT shop to add the ability to provision against internal application or other 3rd party applications that didn't ship with the Provisioning System.
Now there a lot of finer detail that goes into each item above, but I think this paints a picture that describe the ability to be "Drop In for Production" and also flexible enough for customers to leverage the system for future services without the need to wait for the vendor to supply a new module, upgrade the entire codebase, etc.
Now as I'm also an MPS Evangelist, i have to say that MPS can enable all of the above except for the UI component (I'm looking into it now though) and the Service Relationship Manager. The SRM is something that we've had in the way of a different Service Plan methods, but nothing that provided a platform for managing a number of services. They have been one off items thus far. The latest is to manage plans for different levels for Hosted Exchange 2003 service plans.
In order for many of these provisioning and automation ISV's to make money is to leverage existing technologies as much as possible, like MPS and Biztalk 2004, to further reduce their development, test, and support costs. I realize that it does put the burden to sale another technology, but there are ways to work around that. You could think of it more as an embedded component. Also, it would be great if they start to go for a more low-cost and high-volume approach. That approach would require more spending in the sales and marketing area in order to get the product visible enough to be able to get that high-volume business going (this is where it's nice to leverage an existing brand), but it doesn't seem that the high cost/few customers approach works very well. I think thus far this has been the normal approach for many provisioning/automation companies.
Visit the MPS Community: http://groups.msn.com/MSProvisioningSystem
Hey, that's my 2 cents.
Before I take my vacation to Playa Del Carmen, Mexico (oh yes I can almost feel the warmth!!), I updated the MPS Community site with a bunch of new Articles that covers a number of different topics. Hopefully this will give people something to read and talk about until I return.
Check out the articles list: http://groups.msn.com/MSProvisioningSystem/articles.msnw
I'll clean up the site a bit more after I return so that you can see a Reading List for new users of MPS or something on the front page. I'm still looking for people to send me some suggestions on articles they would like created. Send your suggestions to firstname.lastname@example.org. I'll be out all next week, so don't expect a reply until I return.
I just spent about an hour writing this up, so I hope those of you interested in MPS will find this, well...uh..., interesting.
It's interesting to see that some authors from the Windows .NET Magazine actually took the time to review the Web Admin Tool. Here's a link to the Web Admin Tool Community site where I posted a set of links to the articles.