mateus.info

I hope I’m not violating any copyrights, but this one is so true that deserves to be posted here.

Next Tuesday, 18th December I will be going to Brazil. Keen to see all the friends and family.

MOSS is a great product. But if you have been developing a custom application using MOSS as the platform, there’s a chance that you not only have a different opinion about MOSS but also may be using some very strong adjectives to describe it.

The main question about using MOSS, as happens with any other technology or tool is: Is this going to save you time?

By using MOSS in your projects, are you actually saving development effort?

Before deciding if MOSS is going to be or not part of your solution, this question must be explored and answered. I’ve seen several times people with wrong expectations about what MOSS will deliver and this is the most common cause of the lack of satisfaction around MOSS.

In order to answer this question, we need to understand the profile of our project.

If you can answer yes to any of the following questions, the MOSS is very likely to be your solution:

·         Do you need content management features, allowing non-technical users to maintain site content? (site content not tied to any specific business rule or intelligence)

·         Do you need document storage features, including versioning, keyword searching, or associating document types with specific visual lists, approval workflows, by not having to write code?

·         Do you need keyword search across data from different sources, such as documents, databases and web services?

·         Do you have Excel spreadsheets and you would like to publish them online and provide a way of allowing users to see and update the data from the web?

·         Do you have isolated database tables where all you want is a simple, online data entry user interface without any special business rules?

·         Do you need users to be able to create their own sites with content, blogs, wikis or other common content management features?

Well, if you answered yes to one or more of these questions, MOSS is probably your friend. You will be pleased with the great features and advantages of using MOSS for your needs.

But let’s say you are answering yes to some of the following questions:

·         You are developing a commercial app, and instead of developing web pages to manage the CRUD operations on tables, you want to use MOSS lists, so you won’t have to develop anything?

·         Your application needs to store documents but doesn’t need searching, versioning or workflows, so you want to use MOSS just for document storage?

·         Most of your application will be custom developed in ASP.Net and C#, but as you need “MOSS Integration” you are looking for developing web parts for every single list or form of your application so it can be hosted on MOSS?

·         Some of the entities of your application will be managed by custom code and others will be managed by MOSS itself?

·         You want MOSS because you need workflow features only

Well, if you answered yes to any of these, be worried, be very worried.

If you believe that instead of creating the common web pages with CRUD features you can just create lists on MOSS and have them working exactly the same way, keep in mind that there will be always business rules and exceptions to this. So then you will decide to use MOSS lists for the simple CRUD tables and custom dev for more complex user interfaces. Everything will be nice and easy until you realize that you need to link your real world tables to your fiction “entities” managed by SharePoint. You can’t access MOSS databases directly, so you can’t create reports using something like Crystal Reports that easily.

Also, you can’t have referential integrity between the MOSS lists and your real tables, or even between two MOSS lists. If you ask a MOSS specialist, he would probably say: “Of course you can! You can create some triggers and code the integrity yourself!”

Yes, that’s true. The problem is that if this becomes the solution for your referential integrity, the amount of code and time you will spend here will bring you to my first question: How much development time you are actually saving here?

You could always replicate your MOSS list data to specific tables on your database, but again, you will be spending time on something that was supposed to save you time. Also, you could use BDC to bring your custom database tables information to MOSS, but what for? To support keyword search on these tables? Is this a requirement for your project? Or a couple of ad-hoc reports could manage all the data information your users would need to obtain?

And you always need to keep in mind that by using MOSS you will need:  A good server, more configuration steps to support things like debugging, automated deployment and source code control. So keep that in your equation when deciding if it will save you time.

So what’s the point?

I’m not telling you to run away of MOSS and never look back. I’m just saying that in the today’s world, where MOSS specialists are being chased as little rabbits in a lion’s jungle, we need to stop for a moment and understand where MOSS and WSS are as technologies and what the benefits that they can bring to you are.

I trust MOSS will evolve and solve most of the considerations I’m making today, becoming a real application server. But today MOSS is NOT an application server, and from the architectural point of view, if you are developing a custom app, you should see MOSS as a collection of services that you may or may not use individually from your application.

Don’t use the technology just for the technology. Use good sense and always look at the big picture from the architecture point of view.