SharePoint integration in Visual Studio 10 (and my thoughts around their implied concepts)

Visual Studio General Manager, Jason Zander’s, revealed some very interesting announcements around the expected capabilities of Visual Studio 2010 and MOSS at TechEd EMEA 2008. I think this is very much in alignment to an implicit approach Microsoft is shifting to: enabling software development at an architecture and enterprise level, both in more general “tradition” areas but also specifically in SharePoint.

Microsoft launched the Patterns & Practices group for quite a while ago and this group is doing an excellent job enabling architects to develop repeatable-successful solutions using the Microsoft.NET Framework. The group provides reusable artifacts such as the application blocks and design patterns to leverage collective knowledge in order to enable predictable outcomes. In my opinion, this is essential when dealing with enterprise-level applications.

Relying on this managed knowledge means that architects can adhere to successful patterns when handling the overarching concerns of the solutions: we get answers on how to plan for a solution, what products to use, how to provide a build-cycle and what not. And, and this is most important, we are used to this richness of information. We depend on it.

However, when we leave the world of “traditional” technology, RIA, Web Site, Rich Client, Service, etc and we enter the world of Knowledge Management through SharePoint, we suddenly lose out trusty partner. We no longer use application blocks for developing web parts, we do not know how to make our solution testable, and we have to create our own methodology. In essence, we no longer leverage the collective knowledge. Now, you might argue that we have many reusable web parts and heaps of self-proclaimed “best practices” books but almost all of them deal with the technicality of SharePoint solutions, not the bigger picture of solution architecture.

Or at least that was the case in the past. Not so long ago the P&P group released the SharePoint Guidance presumably to bridge that gap, and that’s a good starting. Though I see there are many gaps and holes, especially when you try to bind it with the current Architecture Guide, I think this demonstrates a shift in the approach Microsoft is taking for SharePoint, an approach whose goal is to enable software development at an architecture and enterprise level, especially for SharePoint.

So, going back to the announcements Jason did – I think that these new capabilities in Visual Studio 10 is just another such effort from Microsoft to enable a full software development lifecycle and the VS tool aims to cover the development aspects of it e.g. these capabilities enable multi-members teams working on the same SharePoint solution.

Using CCF to integrate LOB applications

Here’s some news for the architects out there: check out CCF. CCF, which stands for Customer Care Framework, is an integration framework from Microsoft targeted for customer care environments (“call centers”). I was introduced to this framework on my last project in which I assisted in the architecture of an integration project for a customer care department.

The interesting thing about CCF is that the integration of LOB applications is done in the front-end layer, not in the middle tier. This is a great money saver for the business since it maintains the existing business logic and does not require re-development (as is the case in most SOA projects).

In a nutshell, CCF gives you the following:

1. Non-disruptive integration layer: the integration of existing systems is done on the call agent’s desktop by hosting the applications. The hosted application is not modified (its source code shouldn’t be touched) so the business logic and the data validation of the application is honored. CCF can automate the UI of the hosted applications based on the customer’s context (the customer being handled by the call agent).
2. Configurable business scenarios: CCF supports “workflows” to assist the call agents in using various integrated systems to perform a single business operation. For example, the scenario “create customer” might include updating the accounting systems and the product systems. Using CCF workflow the admin can deploy a “Create Customer” business scenario that redirects the call agent to the relevant systems (and if automation is implemented, CCF can further assist by automating the manipulation of fields in those relevant systems).
   Note: the term “workflow” is not the best ever, a guided wizard would be more accurate (and that’s why I’ll never be a salesman).
3. Customer-context driven development: one of the key aspects in CCF is the Context which contains the fields associated with a customer. CCF can then use the context in order to automate hosted systems (so the CRM will automatically perform a customer search when the context is loaded to the CCF) and it can also forward the context to other agents (so if you’re redirecting between call agents, your session is always maintained).

It is important to notice that CCF is not a solution, but rather it is a framework. You won’t be able to “install and go”, you’ll have to learn the tools and concepts and develop your solution accordingly. Once learned, CCF can really add value to customer care related integration projects.