Billion Dollar Bet

At its 2007 Financial Analyst Meeting on July 26, Microsoft announced that revenue for Microsoft Office SharePoint Server 2007 surpassed $800 M US in fiscal year 2007. This is a growth rate of over 35% from last year.

This success appears to be floating the Microsoft Business Division's bottom line, which increased its revenue by nearly $1.5 billion over the last quarter. The Q4 FY2007 earnings are detailed on Microsoft's site.

There's more information on CNN Money here.

I particularly like this quote taken from Todd Bishop's Blog, at the Seattle Post-Intelligencer website:

The company says the trend puts SharePoint on track to become a billion-dollar product, based on annual revenue.

Something worth noting is that these figures can't take account of Windows SharePoint Services 3.0 adoption, which is technically "free" on a licensed Windows Server 2003 installation. I've seen many organizations that are building solutions on top of WSS and won't count directly as generating SharePoint revenue.

However, each successful WSS project is a factor in purchasing and maintaining Office and Windows Server licenses and I feel these projects are just as key to Microsoft's SharePoint platform roadmap as fully fledged MOSS installations are.

Anecdotally, apart from VMWare, I can't ever recall seeing such a rapid take-up and so much enthusiasm for an enterprise product. I think the SharePoint numbers would be even higher, but one of the things slowing adoption is the need for many companies to address their internal business processes and infrastructure, something which they recognize might be lagging, and which a proper SharePoint implementation seems to act as a catalyst for.

Increasingly, standardizing on the SharePoint platform looks like a good bet.

The Beta 2 of Visual Studio 2008 (aka "Orcas") has been released. To download it, point your browser at http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx.

If you're using the VPC version you'll first have to download and install the base virtual hard disk, Base01.vhd. It's available here.

After extracting the VPC or DVD, you'll also have to download and run a script to prevent the beta from messing up any existing Ajax development you may be working on.

Finally, if you are using the VPC image you can log onto the box using the username "Administrator" and the password "P2ssw0rd". It will prompt you to change the password once you log in for the first time.

Scott Guthrie has been blogging about many of the cool features that are contained in Visual Studio 2008.

Some of the things that I hope to try over the next few days:

• Working with Linq, especially trying to figure out how it would work in an n-tier architecture;
• Nesting master pages;
• Trying out the enhanced CSS support;
• Using the embedded Ajax framework and enhanced JavaScript intellisense and debugging.

Happy coding!

Another day, another SharePoint learning experience for me...This time one of my SharePoint colleagues at work, Viraf, was trying to connect to an Oracle database using the BDC. I'd had some previous success using database credentials authentication to a SQL Server-backed CRM application so he and I put our heads together to get this BDC Oracle connection working.

Because we didn't have Oracle installed anywhere initially, we began by mocking up one of the client's tables in a temporary SQL Server 2005 database and using the steps in my previous post to connect to it. Since those instructions weren't using Integrated Windows Authentication and used plain old SQL command text, we figured this would be a pretty good head start. The only major change to the BDC Schema App file was the line:

<Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>

had to change to:

<Property Name="DatabaseAccessProvider" Type="System.String">Oracle</Property>

Any table names referenced in the SQL Command text in the App schema had to be prefaced with the database schema name; ex:

SELECT Field1, Field2 FROM MySchemaName.TableName

Unfortunately although all was right with the BDC schema, there was an authentication error when trying this against the client's Oracle instance. The culprit was the Single Signon database which managed the connection.

In the SQL Server test database Viraf was using, the only fields required in the Single Signon Application Schema were User Id and Password. However, Oracle requires one more field (Field 3) to complete the Connection String: "Integrated Security".

After adding this, in the “Manage Single Signon” section, we went to “Manage Account Information for enterprise application definitions” and selected the application. We needed “\Domain Users” as the group that would authenticate using SSO (in other words, every SharePoint user would use this connection). Finally, we filled out the User Id field with the Oracle username, the Password field with the account password, and the Integrated Security field with the value "no".

Although we were able to get this running internally after Viraf set up an Oracle installation to prove this would work (it did), the deployment at the client site failed with the following error in the SharePoint log files:

System.Data.OracleClient requires Oracle client software version 8.1.7 or greater.

Viraf found the following article on Roy Tore Gurskevik's blog that seems to explain it: http://dotnetjunkies.com/WebLog/rtgurskevik/archive/2005/01/19/45958.aspx . The good news is that to reach this point a connection has to be happening and SSO reports that the connection string is being retrieved. We're awaiting official confirmation but it looks like this is an environmental issue.

The Two Solitudes

For several weeks my colleague David Marsh and I have been discussing the work we do with SharePoint, what the impact of it is, and where web development trends are heading. One topic that kept being raised was the arrival of a new shared development model.

Often our work in client projects involves acting as a sort of intermediary between the Information Technology team (whatever its precise title) and the End Users - what you might call the "Two Solitudes". I don't mean to suggest that these two broad groups are in conflict with each other - simply that they have distinct perspectives that are not always reconciled.

In most companies, the IT team has long had the primary responsibility for building and maintaining software. As a result of recent web technologies and trends, end users have been handed powerful new tools that make them de facto software developers. However, they are still in the habit of turning to IT whenever there is a problem. IT for its part has difficulty tracking what end users have done and also faces increased complexity managing the runaway adoption of collaborative software for blogs, wikis, and chat.

SharePoint 2007 is a perfect example of this challenge. It is intended to reduce the burden IT has to face, and it does this very successfully. The IT team is no longer a bottleneck when an end user with "Contribute" or "Manage lists" permissions can create lists, upload content, manage group membership, and add, modify and delete web parts at will. End users can even use SharePoint Designer to modify the look and feel of their sites. However, there are still times when they run into problems - if they delete or incorrectly modify a site for example or have problems with a DataView web part. In such a case there is no history in SharePoint Designer, and IT will have a very difficult time responding.

Also, even when all goes well, there is a management issue. The ability to assign metadata and provision sites at will is fine in the abstract, but it sidesteps the valuable practice of researching and planning the business requirements - something that IT knows how to do as part of the software development life cycle. SharePoint's ease of use makes it mighty tempting to act in haste and repent at leisure.

Nobody wants to turn back the clock - and the present trend of shifting development responsibilities towards the end user (whether in SharePoint or any other recent technology stack) is only going to become more pronounced.

So it is important to identify ways IT and end users can share the development mantle. I think there are four major "virtues" required to overcome these challenges and share the development role:

1. Discipline
2. Vision
3. Communication
4. Leadership

By "Discipline" I mean the effort required to understand how the technology works, what its potential is and what limitations it has. It also describes the effort needed to adhere to the governance guidelines, any development standards that are in place, and industry and community best practices.

"Vision" provides a road map for IT and End Users to understand where they are heading collectively. Without a shared vision development is inherently tactical and aimless.

"Communication" is necessary because without it IT and end users have no realistic chance to pull in the same direction, even if they are disciplined and share the same vision. The old saying, "the left hand doesn't know what the right hand is doing" leaps to mind.

The previous three virtues are unlikely to spring up and be sustained without the fourth virtue - leadership. Leadership is necessary at all levels: Power users have to champion the use of the software and encourage their coworkers to use it. Managers need to allocate the time (and budget!) to leverage the technology most  effectively. Finally, the executives need to agree that the technology can be a multiplier of their success, and they are the ones who need to put the main impetus behind it to get buy-in from the rest of the business.

These four virtues have to be cultivated and will only become more important over time as the shared development paradigm takes hold in the business.

"Friendly brokers" will gain importance over time, too. These will be people with technical skills who can speak to the end users. They will help end users understand how the development process works, what the software life cycle stages are, how to gather and communicate business requirements to each other and to IT. Friendly brokers can help IT accept that these end user-developers are removing some of the burden from their shoulders.

The end result is a development partnership that benefits everyone.

Shaun Leisegang, K2 principal technical specialist, gave a webcast just now about how K2 blackpearl integrates with several Microsoft technologies. He showed how K2 workflows can be built and hosted in MOSS 2007, in Visual Studio, and in Visio. Some of the things I learned (in no particular order):

• Environment variables make it easy to transition workflows between environments without modifying any code;
• The updated K2 Tasks Web Part has a batch functionality allowing a user to select and approve or disapprove multiple tasks at once. The web part also has a new quick search that helps filter the lists of tasks, and exposes task actions right on the web part for redirecting (reassigning) tasks, delegating them, or performing some other action.
• The Visio integration allows a user to import existing K2 workflows into Visio...Once a workflow has been chosen from the file system, it pulls in all the workflow elements into the Visio environment. At this point those elements are "orphan activities" but a user can select an object on the Visio page, and assign one of the orphan activities to it, create a new activity, or make it the "start" activity. This process is essentially a mapping between the objects on the Visio pages and the K2 workflows.

Shaun showed how easy it was to add things like email disclaimers to workflow templates. Since K2 is built on top of Windows Workflow Foundation (WF) each of the workflow activities can have custom code.

Shaun also referred to two K2 templates for SharePoint user and document management which help with provisioning and permissions, although these weren't demonstrated. At the end of the presentation one of the questions was about these: they were described as
"the SharePoint Document Event template to handle the movement and manipulation of documents and the SharePoint Users Manager event template to handle MOSS security permissions". Both of these sound quite useful as they are frequently requested by clients.

Another attendee asked about Oracle integration. Shaun stated that templates to connect to Oracle have been developed and K2 "also supports the Microsoft BizTalk 2006...adapters which support Oracle".

I've been working a bit with one of my colleagues, Slava, developing web parts and deploying them using Features. One issue that cropped up was how to remove the custom web parts from the Web Part gallery and any websites if the feature was subsequently deactivated. This kind of feature cleanup isn't something that can be done without custom code.

The solution Microsoft has provided is to create an event receiver called a Feature Receiver class for the feature. When tiggered, custom code can do any kind of setup, cleanup, or other job that might be required.

There are four events in the Feature life-cycle that can be triggered:

1. FeatureInstalled
2. FeatureUninstalling
3. FeatureActivated
4. FeatureDeactivating

At a high level the steps needed to create a Feature Receiver are:

1. Create a strongly-named feature receiver assembly containing a class inheriting from SPFeatureReceiver
2. Add custom code to the appropriate feature receiver methods
3. Deploy the assembly to the GAC on the SharePoint server(s) where the feature is deployed
4. Add a reference to the Feature Receiver assembly and class in the Feature.xml file
5. Deploy the feature
   

The Microsoft SDK explains Features and feature receivers in detail. In the particular case that we ran into, Zac Smith has a great example explaining how to deprovision the web parts.

Windows Server 2008, Visual Studio 2008 ("Orcas") and Microsoft SQL Server 2008 will all launch on February 27, 2008! So said Microsoft Chief Operating Officer Kevin Turner at the Microsoft Worldwide Partner Conference 2007 in Denver Colorado. The press release is here. Scott Guthrie later clarified in a comment on Scott Dorman's blog that release is often several weeks or months before the official launch.

So it looks like we'll be able to start working with the new products around late January - which is good timing because I'm sure by then we'll be completely adapted to the huge changes in SQL 2005, Office 2007, .NET 3.5, WF, WCF, WPF, WWII, etc and ready to grab the next wave!

Today I was creating a workflow in Visual Studio so I could repackage it with content types and lists, rather than using SharePoint Designer where the workflow has to be applied to a specific list.

Whenever I tried to create a new SharePoint Sequential Workflow Library project, I got the error: "The project type is not supported by this installation". Turns out I had a pre-release version of the Visual Studio 2005 Extensions for .Net Framework 3.0 (Windows Workflow Foundation) - beta 1.2 to be precise. After uninstalling and reinstalling the release version, available here, I could create the workflow project.

I'm currently following Nick Swan's excellent blog postings about how to create and deploy SharePoint workflows in Visual Studio: SharePoint 2007 Workflow with Visual Studio 2005 + InfoPath 2007 (RTM VERSION!) and Deploying our SharePoint 2007 Workflow with Visual Studio 2005 + InfoPath 2007 (RTM VERSION!) .

K2 has announced a release date for blackpearl! The date will be August 6. From the press release:

K2 blackpearl gives business and technical users the ability to collaboratively design, assemble, execute, monitor and optimize dynamic business applications. K2 blackpearl includes business process management capabilities. Although blackpearl's capabilities far exceed those of K2's previous offering, K2.net
2003, existing customers can upgrade easily.

I'm not sure if pricing and licensing information is currently available somewhere or will be published on their website; as I recall for the previous version you had to inquire about it.

K2 will present information and product demos this week at the Microsoft Worldwide Partner Conference 2007 in Denver, Colorado.

You can view the full press release here.

MOSS 2007 uses "mobile views" to provide built-in support for mobile devices. To view a site in mobile mode, use the following URL: http://URL/_layouts/mobile/default.aspx . There is also a shortcut URL you can enable: http://URL/m/. To enable it, run the following command on the SharePoint server: stsadm -o activatefeature -name MobilityRedirect -URL http://url/

As you can see, mobile mode is just an HTML view without anything fancy.





To simulate how SharePoint appears in a mobile device, you can use Visual Studio 2005's Device Emulator Manager and .ActiveSync.


First, I'm assuming Visual Studio 2005 is installed on your SharePoint (development) server. It contains the Device Emulator Manager. You can find this under "Tools". Next, you need to configure a mobile device's network settings. The easy way to do this is to install ActiveSync 4.5.



Once you've installed this, connect using Device Emulator Manager in VS2005. Simply right-click the device you want to emulate and click "Connect". Then "Cradle" the device. This prompts ActiveSync to start up and connect to the device. At this point networking will work and your device will be able to view the portal in its Internet Explorer browser.

If you have Check-in/Check-out enabled and want to modify document properties, you must first check out the document in the browser before trying to edit it in the mobile device. When you first check it out, make sure you leave the option "Use Local Drafts Folder" unchecked. At this point you can modify the properties in your mobile browser window.

This week the trial license on one of my virtual servers expired. I tried to enter a valid license key, but it said: "Failure! Your license conversion operation failed. Check the error logs for details."

Now this sounded like bad news. A quick search on the web turned up two postings on how to fix this: Tony on developerfood, and Shane Young at the SharePoint Farmer's Almanac.

The solution is very simple:
1) Restart the WSS Timer service (in the Services MMC)
2) Restart IIS

Now I can log back in to the Portal without problems. As the 180-day trial MOSS licenses start to expire there will probably be more occurrences of this bug.

After Wednesday's live echo for SharePoint 2007 demonstration, I spoke with Stephen Cummins to ask him more about it. In addition to being echoTechnology's Technical Evangelist, he's a SharePoint MVP and blogs at SPSFAQ and echoTechnology Support Blog.

Question: What are the most important design considerations you follow when planning, implementing, and managing a SharePoint portal?
Stephen:Not really understanding the SharePoint architecture leads to examples like trying to recreate file shares in document libraries, creating deep navigational structures, or one giant document library with hundreds of folders.It's best to be prepared - it makes more sense to have multiple smaller document libraries, so you can have an easier time assigning access to these libraries, applying different workflows and metadata. A poorly planned architecture can make it hard to grant access, and maintaining it is a manual and time consuming process. Another important consideration is capacity planning for the size of the content that you are uploading, which affects the size of the database and the search index. When you are planning, realize that this is something that the organization needs and will use for years to come.

Question: What are the difficulties in achieving a good design?
Stephen: It's hard to make sweeping changes once you've deployed the portal...you have to live with your mistakes. Without the proper tools you can change site hierarchies and taxonomy but it becomes time- and labour-intensive.

Question: How would you describe your product?
Stephen: echo 2007 allows administrators to manage and migrate to the SharePoint 2007 platform. This means rapid changes, testing and deployments. The core focus is on migration and management. By automating change on SharePoint echo2007 enables administrators to:
a. Shorten migration from 2003 to 2007;
b. Migrate plus deploy new 2007 features simultaneously;
c. Maintain a more dynamic portal;
d. Dramatically Increase responsiveness to change requests;
e. Deploy a more powerful search by keeping control of meta tags;
f. Lower administration costs;
g. Lower the risk of changing the platform;
h. Significantly reduce consulting budgets;
i. Reduce deployment and piloting schedules;
j. Meet corporate risk mandates;
k. Redeploy resources to focus on solution development.

Question: What are the principal scenarios you see echo being used for?
Stephen: It's a tool for shortening migration path, managing the software life cycle in development, testing, and production. It's useful for batching and scheduling changes and updating the portal quickly. It helps managing Features, Content Types, and workflows, all of which are easy to deploy but difficult to change.

Question: What steps would you follow to migrate a SP2003 site to 2007 using echo?
Stephen: First install and provision your site hierarchy in SharePoint 2007. Do this based on lessons learned from 2003 - make a clean setup, remember that a lot of things from SharePoint 2003 won't apply, like Areas. Next create a 2007 template as a blueprint. Use echo to migrate the libraries, lists, and webparts over using the blueprint. Then migrate the content, being careful to map the metadata to your new taxonomy and content types. If you need to make modifications, you can rerun the migration as often as you like to migrate more web parts, lists, and libraries.

Question: Can you script and run echo functionality automatically, or on a scheduled basis?
Stephen: You can run the tool immediately, save it for later, or schedule it for a particular time.

Question: Can you use this tool for migrating changes from one environment to another?
Stephen: Definitely, it is very useful for that. We are even working on combining echo with a full bi-directional georeplication capability thanks to our partnership with Syntergy!

Question: How would someone use echo to manage changes in development and push them out to a testing and then production environment?
Stephen: We think end users will drive this need - they will ask for web parts or tasks lists or new workflows, and IT will have to have some way to rapidly and reliably deliver these items. As an example, a developer will develop in SharePoint Designer or Visual Studio, use echo to push the changes to Testing, make modifications on Dev as a result of the testing results, incrementally modify their work, and keep pushing the changes out until they are ready for production. As part of a change management strategy they can create the tasks to do this, run them automatically at say 8pm when users have gone home, and in the morning get a log result of how the deployment went.

We consider this to be a "real world product". In fact the reason I joined echoTechnology is because I like offering a solution to potentially everyone who needs a problem fixed, rather than going in to one client at a time and trying to improve the SharePoint management situation.

Question: Can you migrate SharePoint Features using echo?
Stephen: You can activate and deactivate features as tasks in echo 2007.

Question: echo can replicate Ninetex workflows - can it do this for other workflow engines or for Workflow Foundation itself?
Stephen: echo 2007 can manage any Windows Foundation (WF) workflow that is hosted in SharePoint.

Question: Is echo 2007 a tool only developers will be using, or do you envisage other groups using it?
Stephen: I envisage lots of different people using it: A Solutions Architect; the developer who works on the platform; infrastructure staff who might not let the developer near the production farm; the SharePoint Administrator. Also consultants could use it to quickly and reliably resolve issues and deploy solutions when they visit client sites.

Question: What have been the biggest technical challenges you faced in developing echo for SharePoint 2007?
Stephen: There's been so much work to do - we spent years working on this while SharePoint 2007 was being developed and released. We made tons of proof of concepts. Challenges included making sure Content Types were consistent across all environments, trying to handle incremental versioning when doing deployments....

Question: You've also released a new tool, SharePoint Spy - what can you say about that?
Stephen: It's a great tool - we actually developed it for our echo work. It lets you dig under
the hood and view all the properties of a column or list. It's partly for troubleshooting, partly for analysis, partly for educational purposes.

Question: What sort of pricing structure are you looking at?

Stephen: We're probably looking at a rising scale based on number of sites; essentially we would like to license it on a usage model because the number of people who use it in an organization might be small, but they may need it for lots of different things.

Question: When will your product be released to market?

Stephen: We are targeting end of July.

Thank you Stephen for your replies!

Yesterday evening I saw a live demo of echoTechnology's echo for SharePoint 2007 product, which is a tool for handling SharePoint migration and management. The presentation was
given by CEO Garry Smith, Technical Director Sergio Otoya, and Technical Evangelist Stephen Cummins. The company is positioning echo as the tool that "allows administrators to
effectively manage and migrate onto the SharePoint 2007 platform". The demo was an hour long and was really impressive. Following that I spoke with Stephen to get a little more
information about how they feel the product can be used. I'll be publishing that within a few days.

Last night's demo gave a clear indication of echo's design philosophy, which is to make replication and change management as easy and granular as possible. This is important
because it's actually really hard to roll changes across different SharePoint versions, sites, and environments. I've mentioned before on this blog how complicated I find it to
properly manage the customizations that I make. Echo aims to solve that.

The two core concepts or "streams" that echo specializes in handling are migration and management. Migration might include migrating content from SharePoint 2003, Domino,
Exchange, or file shares. Management includes managing workflows, features, web parts, content types or site hierarchies. By creating discrete "tasks" for each of these, echo
gives you very granular control, allowing you to do one or more tasks handling simple or complicated scenarios.

The first part of the demo was a migration from SharePoint 2003 to SharePoint 2007. Out of the box SharePoint provides options such as in-place, gradual, and content migration.
The steps required to do these, and the pros and cons of each, are well documented elsewhere on the net so I won't go in to them here.

The way echo does it is to use a fresh install of SharePoint 2007 as a clean environment in which to push the 2003 migration. You first create a template site in MOSS 2007 (they
called it the "Blueprint site") which has all the webparts, lists, and views you would like to migrate your 2003 stuff to. Next, you select the 2003 sites you would like to
migrate. The lists of migration candidate sites get added to what looks like an Excel plugin - this allows you to save the list to Excel and give it to your business users so
they can make any changes they want pre-migration. This ensures that someone can clean up metadata, illegal characters, or make any other changes before you do the site
migration. You can run the job right away, or schedule it to run automatically at a later time. You can also save it to use for other batches. Once the batch ran, we saw how the
sites from 2003 were all copied over to the 2007 portal. A log gives complete details on each step of the migration.

After the run, the web parts and lists were migrated, but not any of their content. This led to the second demo, which was about content migration or "content loading" as it is
called. Having migrated the 2003 sites over, we were shown how the Content Loader Task allowed an administrator to map existing 2003 content, including its related metadata,
over to content types created on the 2007 portal. The mechanism to do this is very granular, so content settings, fields, views, permissions, version history and the like can
all be migrated across in whatever way you want.

There is even a choice to truncate the version histories, so that if you wanted you could migrate only the last couple of versions of content to the new 2007 portal. Once again
all of this can be saved to an Excel "control file", which allows customers to modify the migration settings if they want. This allows a deep level of control over the process,
and the Excel format is very user-friendly. In fact if I understood correctly formulas could even be run over the control files to do quick formatting.

The echo team say that one of the primary goals of the Content Loader Task is to help manage content types and support a central taxonomy. They feel that this is a key
requirement to really gain value from a MOSS portal with targeted searches. They have seen that many organizations don't bother doing this in a systematic way due to the adhoc
and unstructured way SharePoint 2003 allowed metadata columns to be added. Since an out-of-the-box migration will just try to copy existing metadata columns across without any
adjustments, and since the administrators doing the migration don't have any knowledge of what metadata should be placed on the content, the tendency is just to port all of
it over to the 2007 portal without applying any lessons learned or disciplined taxonomy. By using the Excel control file, the burden of applying appropriate metadata is removed
from the shoulders of the administrators handling the migration, and placed in the hands of content authors where it belongs. The Excel format seems like a logical way and
friendly to get content authors to plan and manage their metadata before a migration.

Having demonstrated the ease with which metadata can be changed in the Excel control file, it was reloaded into the echo interface, the batch was run, and all the content
migrated over to the 2007 sites and mapped to Content Types as planned.

The next demonstration was a quick example of loading content from file shares - in this case images kept in a series of folders. What was neat here was that there were four
folders with only two duplicated images in each - basically an example of versioning as it is usually done on a file system. The content loader provided a mechanism to
"collapse" these files together so that upon import, there were only two images but they each had the complete version history of their four versions taken from the folders.

At this point we were shown the concept of batching, which facilitates scheduling and change management for SharePoint. Any number of tasks could be added and configured,
providing complete flexibility for whatever scenario was required. The batches could be saved for future use, and scheduled to run at a particular time (such as after business hours). Batching is also an effective mechanism for migrating changes between environments.

Things I found noteworthy:

• The Excel plugin approach is a very good idea. Garry suggested this was driven directly from customer feedback.
• The granular level of tasks is useful because no-one is second-guessing how you want to do a migration or management - you are free to chain the tasks together in whichever
  order or process you like.
• The ability to migrate workflows is pretty key as one of the drawbacks of using SharePoint Designer is that it links a workflow to a particular list - and echo would remove that
  problem.

I'm sure that some organizations will value this tool for the help it can give migrating from SharePoint 2003 to 2007, especially with more complicated sites. It may help such
organizations "jump the gap" if they are hesitating due to the complexity of managing the transition. I haven't had to do many upgrades and those have been straightforward
"content migrations" so this is less important to me. Personally I'm most interested in the potential it has for migrating SharePoint customizations from development to testing
to production. This is a requirement in any organization that supports SharePoint and very hard to address without such a tool, and it's an ongoing need.

Echo for SharePoint 2007 is scheduled for release at the end of July. If you're interested you can find out more information and download a trial at echoTechnology's website
(http://www.echotechnology.com/).

After K2's BlackPearl demonstration a few weeks ago, I had a few questions. I contacted Josh Swihart at K2 and he and Anthony Petro, the Technical Product Manager, replied to me:

Question: I know the BlackPearl Report Builder uses Reporting Services – can these reports be exported and even hosted on a distinct Reporting Services server or hosted in SharePoint’s integrated Report Centre? The reason I ask is that a lot of Microsoft products - MOSS, Dynamics CRM - all use Reporting Services, so from a server topology perspective it would be great to have them all publish to the same RS server and manage things a little more centrally. Josh and Anthony: Yes, when you install BlackPearl you must provide information on which Reporting Services server you want to connect to. The Report Designer will use this server when you “publish” a report to RS. Once the report is in RS, you can use standard UI in RS, or compatible apps like SharePoint RS web parts, to view these reports.

Question: I wondered if the autogeneration of InfoPath forms using that Forms Designer item that Adriaan demonstrated would be available by Release-To-Market or shortly thereafter. This would be a nice-to-have for InfoPath 2007 development in conjunction with MOSS.
Josh and Anthony: The SharePoint integration wizards can use either ASP.NET or InfoPath forms server forms. Both technologies will have default forms that are installed with BlackPearl to be used for Instantiation, Association and Task Form. Note that there is more info on this in the SharePoint whitepaper. Additionally, we have added the Forms Generation Client Event which will allow you to generate ASP.net forms automatically for Process, XML and SmartObject data in the process. Post-RTM we will expand the forms generation client even to support autogeneration of InfoPath forms.

Question: I read this in one of the K2 Black Pearl pdf documents:

“K2 “BlackPearl” process information is availableto MOSS users through
integration with the MOSS Business Data Catalog (BDC). All process information is
searchable (security is respected) and can be exposed through list columns and
BDC web parts.”

Does this mean that for any custom workflow I create in K2, a BDC application schema is automatically generated for me to upload into the BDC Catalog? Or do I still have to create a schema for this by hand? It mentions “process information” - does that mean just the time it took the workflow to execute, the name of the originator, etc, or does it also expose SmartObject data and the like so that I can pull those into SharePoint via the BDC?
Josh and Anthony: We provide the ability to surface any SmartObject data through BDC - including process and activity data configured as SmartObjects. We have created a K2 Admin tab in SharePoint Central Administration to make it easy to identify which SmartObjects, and optionally their associations, should be exposed in BDC web parts and/or search. The BDC application metadata for connecting to the SmartObjects is automatically generated and configured as result of the actions on the admin page.

Thanks Josh and Anthony for taking the time to respond!I'll also mention again that there is a new community forum called K2 Underground for exactly these kinds of queries. There is also some documentation available on K2's blackpearl site which describes some of the new features. Plus there's a beta to download and play with!

K2 Underground is here: http://k2underground.com/. K2 Blackpearl website is here: http://www.k2.net/bp. You can send an email to beta2@k2.net to get your hands on the beta 2.

SharePoint Governance is an extremely important process to help guide and control any SharePoint implementation. Many organizations start down the rabbit hole with proof-of-concepts and trial installations that quickly get out of hand. I heard one IT manager refer to it as "SharePoint under every desk" and by that he meant runaway deployments that stretched IT support resources, duplicated content, created multiple "sources of truth", and generally caused much weeping and gnashing of teeth.

A detailed governance document should be created early in the development of any SharePoint implementation. Key elements of a governance plan include coming up with an internal communications process, identifying key human and technical resources for the implementation, organizing training and support, and providing a clear hierarchy of roles and responsibilities for common SharePoint tasks such as managing documents, developing and maintaining content, provisioning sites, and providing end-user support.

Governance plans are "living documents" and are very likely to evolve over time as new objectives, business processes, user expectations and technical features arise.

There is a new area of CodePlex dedicated to SharePoint Governance. It contains a series of tools and whitepapers that will help manage successful SharePoint rollouts. The site is at http://www.codeplex.com/governance.