Windows Communication Foundation - An Overview

Posted by Sambeet Patra under .NET Software Development, Service Oriented Architecture (SOA), Software Architecture, Software Development Platforms, Web Services, Workflow Systems

Windows® Communication Foundation (WCF) is the unified communication programming model in the .Net framework for building service-oriented applications. In this article I will explain the facets of WCF. I will also build a simple WCF service to demonstrate the concepts.

Why WCF?

WCF is the part of the .NET Framework. It unifies the various communications programming models existing in the Microsoft platform into a single model.

For the past few years, Microsoft distributed solutions have mostly been composed of ASP.NET Web Services / Web Service Enhancements (WSE) extensions / Microsoft Message Queue (MSMQ) and .NET Remoting. Each of these technologies has its own benefits and drawbacks. WCF does not attempt to replace these, nor does it provide a solution that tries to compete with these technologies. WCF is merely a framework that

• provides a base to develop and expose functionalities through any of the above technologies
• empowers the developer to write code that deals with business logic only and “configure” [instead of write code any more] WCF to host the code using one of the one of these distributed frameworks.

Further, it is important to understand that there is a learning phase associated with WCF unlike some of the other .Net technologies [ASP.Net / Web Services etc]. But there is a good enough reason for this. Most of the distributed technologies discussed earlier provide inbuilt features that help developers write code to support specific scenarios. But WCF goes a step further; it mandates standards that need to be followed to write services. Also, since it provides support for most of the existing distributed technologies, the developer needs to understand how these technologies have been conceived to co-exist. Simply put, while other technologies provided “features” and “libraries” and let developers dictate the end result, WCF enforces some well thought out best practices, thereby reducing possible mistakes during conceptualization / development of distributed applications.

WCF Architecture

The following image shows the basic architectural layout for WCF.

• Service Contracts: We will explore this in detail later on. Contracts define the details of the functionalities that are exposed in a service.
• Application Implementation: This is the implementation code for the contracts. This is written by developers.

Note that once you have defined the contracts and written the implementation of the contracts, all other aspects of hosting the service can be configured using the WCF framework. For most of the standard requirements for hosting services, WCF can be configured to provide the right solution without a single line of coding. We will explore the components of the WCF framework in detail. Here is a very high level description of what WCF provides.

• Runtime: As the name suggests, WCF framework provides extensive runtime support for various hosting scenarios. These include requirements like Transaction / Remote Invokation / Life Cycle Management / Exception handling etc.
• Messaging: This layer consists of channels that process the incoming / outgoing messages one by one. This layer is responsible for implementing the WS standards / encoding / support for protocols like HTTP and TCP. Developers familiar with the WSE (Web Service Enhancements) tool will find that this is really the next improved version of the WSE functionalities.
• A service is a program; like other programs, it needs to be hosted either as an independent executable or using a hosting service. The activation features deal with this aspect. WCF Services can also be hosted, or run in an executable managed by an external agent, such as IIS or Windows Activation Service (WAS). A WCF service can also be run automatically as a Windows service.

Service Contracts

Services publish contracts that provide the constituents of the intended functionalities. A contract, in WCF is nothing but an improvisation of interfaces. In fact a contract is an interface with a specific attribute so that the WCF framework recognizes it. The following code snippet demonstrates how a contract is declared. 

 

Once contracts are established, the developers will write the implementation of the contract. This is no different from implementing the interfaces that form the contracts. This is a significant value-add as we are now writing code without any idea about how it is going to be hosted / exposed to the consumers. This will allow the developers to focus on the business logic completely.

In the following sections, we will explore how the implementation can be exposed using WCF.

End Points

WCF exposes services to the outside world via an endpoint. The end points define the characteristics of the WCF hosted service.

The ABC of End Point:

• Has an Address. This is a uri that specifies the location of the endpoint.
• Has a Binding associated. A binding specifies what protocols are used to access the service. WCF includes predefined bindings for common communication standards such as SOAP over HTTP, SOAP over TCP etc.
• Is linked to a Contract. The end point makes this contract available to the service consumers.

When a client wants to access the service via an endpoint, it not only needs to know the Contract, but it also has to adhere to the binding specified by the endpoint. Thus, both client and server must have compatible endpoints. Keep in mind that it is possible to define end points that make the service compatible with consumers of the traditional ASP.Net web services.

Understanding Bindings

As I mentioned earlier, WCF provides a framework to write distributed services and it provides a platform for the developers to focus on business functionality without worrying about the underlying technology. So how does WCF provide the platform features? The key here is “Binding”. A binding consists of one or more binding elements. Each binding element handles a specific non-functional aspect of a service, such as whether it supports transactions, the kind of security the service incorporates, the standards for data transport etc. Binding elements are grouped together to create a binding that is required for the service we are developing.

So how does binding add value?

• WCF provides several out of the box implementations of bindings which represent some of the commonly used techniques. Think of all the previous distributed technologies in the Microsoft world. WCF will have one or more binding implementations representing the strength of the each of these technologies.
• Use of bindings does not require any coding unless you want to write your own specific binding implementation.
• Interoperability is one of the key requirements for services. Chosing the right binding will make the service interoperable without writing any code.

Now, let us look at some of the standard bindings provided by WCF:

• BasicHttpBinding: This binding is based on the WS-I Basic Profile 1.1. It uses the HTTP / HTTPS transport protocols. Use this binding to maintain compatibility with client applications previously developed to access ASMX-based Web services.
• WSHttpBinding: This binding implements the WS-* specifications to implement transactions and secure, reliable sessions. It supports HTTP / HTTPS protocols. Messages can be encoded as XML or by using the Message Transmission Optimization Mechanism (MTOM). MTOM is a preferrable mechanism for messages that contain binary data.
• WSDualHttpBinding: This is similar to WSHttpBinding, however it is suitable for bi-directional communication between the client and server without synchronizing the individual messages [as opposed to a typical request-response model].
• NetTcpBinding: This TCP transport protocol and messages are encoded using binary encoding. While is has better performance compared to HTTP protocol, it is not as interoperable as HTTP based protocols. It supports transactions and secure communications.
• NetMsmqBinding: This binding uses Microsoft Message Queue (MSMQ) as the underlying messaging platform. This handles scenarios where messages are delivered asynchronously [in other words, messages are queued]. Hence, the server need not be running all the time for the protocol to function.

An Example

We still need to discuss a few other aspects of WCF framework. But let us build a sample application with whatever we have discussed so far. We will create a WCF service for the tax service contract we had created earlier.

I have presented the steps to create the service below. I assume that you are familiar with Visual Studio .Net and have Visual Studio 2005 with .Net 3.0 add on or Visual Studio .net 2008 installed in your computer. 

• Create a new project of type “WCF Service Library”.

    

• Once the projected is created, add the following classes. This represents the sample contract we had created earlier:

     

    

    

 

Compile the project once and make sure that it compiles properly. Till now we have defined a contract and implemented it. Now, we will write the necessary configuration to implement the service. For our example, we will host the service in IIS and expose it as a basic HTTP web service. [I will explain hosting later on].

• Open IIS administration console and create a virtual mapped to the folder where you have the project. Add web.config file to the project. Note that this may sound a bit confusing and you may wonder why we did not create a web service project in the first place! I am just trying to make a simple point here. WCF DOES NOT HAVE to be hosted in IIS. It is just one of the options available.

• Now, add a file named TaxService.svc to the project. The content of the file should be as shown below.

• The svc file stores the details of which assembly and class implement the contract. In this case I have mentioned the TaxServiceImpl class in the mytaxservice assembly [which is the output of my project]. This way, we completely detach the contracts from the implementation and we also abstract it from the outside world. If we ever come up with a different implementation for the same contract, we just need to update the svc file.
• Since the service is being hosted in IIS, make sure you reconfigure the project property to define the output under the bin\ folder as opposed to bin\Debug. Also make sure that you configure the virtual to use the right version of  ASP.Net.

    

• Now it is time to define the end point for the service. We will just be adding a few items in the config file to define the end point and then expose the service to the consumers. Here is the content of the web.config file.

Let us now try to explore the configuration details. Let us ignore the <behavior> tag for a moment. We will get to it in the next section.

• The <serviceModel> represents the configuration details for WCF Web service.
• <services> includes the details of all the services offered by the deployment. The name attribute indicates the namespace and the class that implements the service.
• A service can be exposed in different manners. This is achieved by including a number of endpoints that expose the service with specific bindings.
• The address attribute in the <endpoint> tag is kept empty as we want to keep the address relative to the address of the virtual for now. The contract attribute is self explanatory as it mentions the contract that the endpoint exposes. The binding element indicates the binding of the contract. Here we are using basic HTTP, which is one of the many readily avaiable bindings in the WCF framework. In other words, merely choosing this binding sets up the service as a simple web service we used to develop using the ASP.Net asmx files. Once you get into the finer details of WCF, you will realize that changing the behavior of the service is all about coming up with the right configuration.

The Behavior Tag

Behaviors modify or extend the functionality of a service. In the example, the serviceMetadata tag indicated that the Service publishes metadata. Also, the security behavior controls impersonation and authorization, while the transactions behavior controls enlisting in and auto-completing transactions.

In the example we used the serviceMetadata tag to ensure that httpGetEnabled is set to true. This enables us to view the published metadata for the service. To understand what this means, browse to http://localhost/mytaxservice/TaxService.svc and view the metadata for the Tax Service. Now set the value of httpGetEnabled to false and revisit the above url. You will notice that a message comes up stating that the service metadata is not available.  

The Client?

Note that we did not write a sample client while implementing the sample application. So, what is different for a WCF client? Does it need to be aware of the fact that the service is hosted in WCF? Well, in stead of answering this question with a Yes or No, let me reiterate two distinct goals of WCF:

• It provides a framework to write service oriented application. Per definition, services are supposed to be interoperable and hence the client does not need to know the implementation technology of the service. WCF has conformed to this behavior and writing a client for a service created by WCF is no different from writing the client for a service written by any other technology.
• WCF also brings in all the strengths of various Microsoft technologies. Certain technologies are not necessarily interoperable. In such cases the clients needs to know at least the endpoint details of the service. In other words, you will need to write WCF-aware clients that have end points defined to communicate with the service. Needless to say, the binding of the client endpoint has to match the service endpoint.

Hosting of WCF

A host application has to perform a number of tasks. Some common requirements include

• Starting and stopping the service
• Listening for requests from a client application and directing them to the service
• Sending any responses from the service back to the client applications
• Providing diagnostics features

You can use the following options to host WCF services.

• IIS: We already saw this in the sample application. The IIS provides a number of readymade features. It provides automatic activation, diagnostics, on demand compilation and the ability to change application while it is live.
• Create a custom .Net application that the user runs to start and stop the service. While this gives you ultimate control you have to write all the code to provide the functionalities for hosting.
• Host the WCF service in a Windows service so that the WCF service is available as long as Windows is running. Also this is a favorite for administrators as they are well versed with Windows services.
• Use Windows Activation Services, or WAS if you are using IIS 7.0

Conclusion

In this article I presented a high level overview of WCF. WCF offers many configurable and extensible features for developers and support personnel to customize every aspect of service deployment. Even though it takes a while to understand the various components of WCF, the knowledge pays rich dividends as it empowers you to host production ready applications with the least amount of effort.

Useful References

http://msdn.microsoft.com/en-us/netframework/aa663324.aspx
http://netfx3.com/content/WCFHome.aspx

 

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus and has led several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

A Comparative Analysis of SQL Server Reporting Services and Crystal Reports

Posted by Sambeet Patra under .NET Software Development, Software Architecture, Software Development Platforms, e-Business Software Solutions

The objective of this post is to present differences between SQL Server Reporting Services (known as SSRS) and the Crystal Reports suite. Since it is impractical to identify the “better product” without the context of a specific deployment scenario, I will focus on laying out the high level differences and let the readers draw their own conclusions.

(A) Product Maturity

Crystal Reports has 11 major releases and it is currently at the XI version. Since the early conception, the product has been focused on end to end reporting needs and has matured comprehensively over the last few years. There is a general misconception about the common issues with Crystal Reports especially in the .Net community. Many people do not realize that the embedded crystal reporting features in Visual Studio .Net 2003 was a limited edition of Crystal Reports 9 which has been out of date for a number of years now. The newer versions have matured significantly and provide features to seamlessly integrate with .Net applications.

SSRS, on the other hand is only 2 versions old. The first version was released in 2004 as an Add-On to SQL Server 2000. However, there are significant feature expansions in the next release [SSRS 2005]. While this product is relatively new, Microsoft had the advantage of analyzing the existing reporting solutions in the market and implementing the most sought after features in SSRS.

(B) The Product Suite

Crystal Reports suite has 3 main components. The designer interface allows users to design report layout. The server is the hosting environment for the reports and it helps manage / schedule reports. The suite provides extensive library to integrate with the various development platform.

SSRS, in contrast, is a .Net based reporting system. If you do not want to work on .Net platform, SSRS is not the right solution for you. SSRS has a design interface integrated into Visual Studio .Net. The Report Server hosts reports and the report manager is used to manage / schedule reports and the related data sources.

(C) Licensing

Crystal Reports provides various editions for designing reports. There is embedded edition available with Visual Studio .Net at no extra cost. This edition helps developers design reports in the Visual Studio .Net environment. There are stand alone design suites available to design reports without the need of Visual Studio .net environment. This package is sold as a per user license. The crystal server license is sold separately.

SSRS is slightly confusing in terms of licensing costs involved. It is available for free when you buy SQL server license. However in large enterprises you would like to separate out the reporting infrastructure. The reason being, SSRS is extremely resource intensive and tends to take up a lot of RAM / CPU, thereby reducing the bandwidth available to the SQL server itself. This forces organizations to buy additional licenses of SQL Server just so that they can install SSRS in an isolated environment.

(D) Report File Format

Crystal Reports are stored in binary format. The crystal reports object model can be used to programmatically access and manipulate the report components.

The reports created using SSRS are stored as plain XML text. This can be opened in a text editor and changes can be made without opening the Visual Studio .Net report designer. You may tend to assume that this is a convenient option to make changes to the report; But keep in mind that the report XML can get extremely complex and it takes a lot of effort to accurately understand and parse the XML. You are much better off using the Visual Studio .Net designer interface. The XML based format allows vendors to conveniently write third party tools for SSRS. Also, Visual Studio .Net 2005 has an inbuilt feature to design client reports that do not require an SSRS back end to be hosted. This report format is derived from the existing xml format.

(E) Data Binding

Data binding is the process of obtaining data from an underlying source and attach it to an interface. This is an important aspect in report development [in fact, display of data is what reports are all about!!]. Crystal Report allows a single data source per report. If data is to be obtained from multiple database tables, then you have to join the tables to get a single resultset. To display multiple content sets in the reports coming from multiple data sources you will have to design and include multiple sub reports in the main report.

SSRS is flexible in this regard as it allows any number of datasources per report. It is easy to design reports with unrelated sections displaying data from different data sources.

(F) Report Design Features

There are endless debates on differences in the design capabilities between Crystal Reports and SSRS. While it is impossible to provide a complete and detailed list, I will compare some of the common features:

WYSIWYG Capability: Since Crystal Reports has matured over a number of major releases, the designer interface helps articulate the exact look and feel for the intended report. SSRS however has minor issues which will probably be resolved in forthcoming versions.

Report Structure: Crystal Reports takes a Section based approach. There are predefined sections in a specific order [i.e. page header / page footer / group header / footer / body etc] and the designers customize each section to achieve the desired look and feel. SSRS takes a different approach. it is possible to drag / drop and customize report elements onto the report deign interface. This provides better flexibility in defining the structure of the report.

Formula / Calculations: Crystal Reports provides a wide range of predefined formulas that can be readily used in the reports. SSRS provides all the basic functions, but it does not match up to Crystal Reports in terms of the extent of predefined functions provided.

Extensibility: SSRS provides options to write custom code or make calls to external .net assemblies from the report.

Managing Data Flow / Sections: Crystal Report provides better features to manage page breaks / section breaks / spacing paragraphs etc. SSRS does not do an equally impressive job. These features are highly desirable in generating reports for finance / insurance / banking.

Summary

Both tools provide extensive features to build reports in your application. While Crystal Reports takes credit for being in the field for so many years, SSRS provides exciting features in the .Net platform. Before deciding on the product that is right for you, make sure you identify your primary report requirements and then evaluate the products to decide on the most appropriate one.

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

Considerations and Best Practices for CRM Implementation

Posted by Sambeet Patra under Customer Relationship Management (CRM), e-Business Software Solutions

Customer Relationship Management is commonly touted as an electronic business solution that brings people, process and technology together to provide seamless customer-related functions. Since CRM has been a proven strategy, companies, over the past few years have made substantial investments in deploying CRM solutions.

However it has been observed that more than half of these CRM implementations fail as the stakeholders of the deployment report negative ROIs. In this article, we provide best practices from our experience in planning  and deployment of CRM systems.

(A) Identify the Nature of Application

One of the primary but often ignored considerations for planning a CRM deployment is identifying the business scope. A CRM system can be looked at as an effective contact management tool, a platform for business process integration, a collaboration management solution providing easy to use features for communication and data handling. While it is nice to have a system that does all this, it is much more practical and economical to correctly categorize the proposed system. Although organizations have disparate requirements, a typical CRM deployment may be categorized as the followings:

CRM as a Contact Management Tool: The system is primarily conceived to maintain client and prospect information. This is typically used by Sales force to maintain list of contacts and the history of communication. The system may not provide complex business processes. However, the users want rich / easy to use interfaces and are likely to maintain huge amount of data. The system is expected to be used for bulk messaging / campaign activities.

CRM as a Collaboration Management System: In this scenario the CRM system is seen as a tool for internal / external communication. It is used as a one stop solution to track and manage customer communications and intra-organization activities involving customers. Users expect features like e-mail integration / information sharing / notification etc.

CRM as a Business Process Integration Platform: The system is expected to automate in house business processes for sales / service / order fulfillment / customer management etc. This is a solution that helps execute process flows across disparate groups in the organization. Such systems are seen as the backbone of the organization that uses it.

It is imperative that we identify the nature of the system before making decisions on the deployment.

• This impacts all the key decisions for planning, design and implementation of the CRM system.
• It helps identify the correct product in the market [if products are being evaluated]
• Provides guidance to the deployment team about management expectations.

(B) Product or Project?

Once the vision is identified, people tend to evaluate the options available in the market. There are CRM products available for all business sizes. These products may be distinguished in regards to hosting and may be grouped in two categories.

• Hosted solutions: Web / Web Service based solutions usually with a rich client layer. The data is hosted by 3rd party.
• Desktop / LAN based applications: Data / Software hosted by the organization itself.

In a happy-day scenario, we would probably find a product that meets the primary vision of the conceived CRM system. Unfortunately this will not be the case in most of the implementations. We need to consider the driving factors and their impacts on each option.

Cost considerations: The option of purchasing and deploying products has a predictable cost associated with it. The product prices are standardized and during the discovery phase it is usually easy to identify the deployment cost. For a custom development project, the management may not have good visibility for the cost involved. Developing custom applications require a detailed plan in place and the right group of resources needs to be identified to execute the project.  There are greater risks involved in regards to completing the project within schedule and within budgeted cost.

In the other hand, most of the leading CRM products available in market are highly extensible and provide framework for deployments to customize the functionality. While such capabilities are highly desirable, one needs to consider the overhead of the deployment cost associated. Decision makers are often misguided looking at the base cost of the products and they do not consider the cost associated with customization and support.

In summary, while products are generally preferred from a cost predictability standpoint, it is critical that we try to identify the customization, deployment and support cost.

Managing Change: A well planned implementation should be flexible enough to accommodate changes. A change may be related to a new business process,  change in the type of users intended for the application, change in functional requirement or a change in organization policies on software deployment. Most of these changes require the existing application to be modified.

Flexibility in accommodating changes plays a major role when deciding between product and custom development for the CRM deployment. Keep in mind that while it is almost impossible to predict the extent of changes, asking some of these questions to the involved business teams helps the deployment team gain valuable information

• How big and diverse is the user base?
• Has the sales process changed over the years?
• What kind of service / product do we provide to the customers? Which of these are tracked in CRM? Is there a well documented history behind these products / service offerings?
• What is the growth strategy for the company?

While products, by definition may seem to have an obvious disadvantage in accommodating changes, a closer look at the extensibility features provides a better understanding of the strengths of the product in consideration.

Integration Requirements: As discussed in the previous section, the CRM system may be conceived as a bridge between disparate business functions. In such situations, the ability for the solution to integrate seamlessly with other systems may be more critical than the ability to provide CRM specific features. Choosing a CRM product [especially a product that is designed as a standalone CRM application] may have limitations on integration capabilities.

(C) Focus on Business Process first…

Often, a CRM system is seen as an intelligent technology that defines and automates the Customer Relationship functions. During the initial discovery phase, people consider it as a one stop solution that can replace various stand alone legacy systems used by different groups in an organization. While there is no argument with the expectation, it is a better practice to consider the proposed CRM application as a system that merely “facilitates” the business processes. Once this expectation is set, the deployment team should focus on identifying “What exactly are the processes” in stead of jumping to “How we can implement the process”. To drive this argument further, let us consider the typical approach to understand and stabilize the business process

• Identify the subject matter experts who can explain the intended business process.
• Analyze and suggest changes to the process without considering the CRM system.
• Once the stake holders approve the suggestions, implement the process across groups without thinking about the CRM application yet. This way we ensure that all the business rules, roles, responsibilities have been adequately defined. This will greatly reduce the unknown issues and possible rework when actually implementing the solution.

(D) Manual Policies Vs System Rules

It is ideal to implement a CRM system that will completely automate the business process. There are issues achieving complete automation because

• Rules can change over time
• Management can change and new policies may be put in place. This affects the already implemented system.

So how do we design a system that can survive such changes? A simple approach is, “Not all rules need to be implemented in the system”. Keep in mind that CRM should “facilitate” processes and integration. The implementation team needs to identify the areas and policies that are likely to change over time and should make an attempt to implement these policies as working instructions for the users. The following example will clarify this:

The sales team often uses CRM to create and manage product offerings and customer quotes. Usually there are rules on pricing / discounting options for the product offerings. It is a common practice in the Sales department to change the rules around discount / pricing.

A short sighted implementation will translate all these rules in to the system implemented. This will then force the deployment team to make changes every time the sales department comes up with new policies.

A better approach is to explore the possibility to allow the sales team to adhere to these rules through proper working instructions. Further, to ensure the conformance to the rules, the team managers may be appointed to review the quotes before it goes out to customers. This way, the system is merely used to track and manage the work done whereas some of the dynamic rules can still be performed manually by the users.

(E) The Driving Committee

If you have managed a deployment project at the client’s location, you would have interacted with the management that gave you directions, discussed status and approved the work done for the project.

CRM projects are usually stakeholder-driven. It is their vision and interests that determine the course of the projects. But who are the stakeholders? People often interact with the senior management to understand the requirements. The senior management may have better visibility on high level goals such as revenue, but there are some obvious shortcomings if you deal only with senior management.

• Detailed requirements are not easily captured. The senior management may not be able to provide correct and accurate input when it comes to finer details.
• At the end of the project, when you are ready to formally obtain user acceptance, it is difficult to get Senior Management to accurately provide feedback.
• Project plan is likely to suffer as sometimes the deployment team needs timely advice and guidance from the Management.

You need some representation from end users. It is a much better practice to form a “driving committee” that comprises of various types of users. In a typical organization structure, you would look for the following people in the team that identify requirements, approve project plan, approve changes, etc:

• Representation from Senior Management
• Supervisors that manage team of users in support / implementation and other user groups using CRM. They create a bridge between management and end users and are the best people to provide detailed inputs / review work done.
• System Administrators as they will play a vital role in providing inputs on corporate strategy for software deployment / security / infrastructure.

(F) First Thing’s First

Often, CRM projects are driven with a top down approach. Management wants visibility through sales reports, revenue projection and sales forecast. They want to achieve this through the system being deployed. What they do not realize is that such analysis is done only if complete and qualified data is entered and maintained in the system. This approach then requires the low end users to put additional effort in entering all the data required. This results in lack of interest on the user’s part to adopt the new system. Also, users tend to get away with entering minimum possible data to get their job done.

An alternative approach is to understand the requirements of the management and at the same time pay attention to the low end users. During the initial phases, focus on building a system that is acceptable to the low end users. Once they adopt the system and realize the potential, you should make gradual attempts to build in additional features requested by the Management.

The success of a CRM system usually depends on the end users who access the system frequently. It is imperative that you gain their support and acceptance for a successful deployment.

(G) Iterative Approach

If you are planning to achieve all functionalities in a single iteration of the deployment, you are brewing recipe for disaster.

CRM deployment is a learning experience for all people involved. While the management may think that they have all the requirements in sight, they start discovering rules and patterns as things progress. As the representative of the deployment team, you need to help the business “learn and apply the learning”. Plan the deployment in small phases and make it a point to achieve few critical goals through every iteration. Obtain timely user feedbacks and do not be afraid of rework. Keep in mind that the business is used to identify the right approach only when they see something tangible. Instead of creating and reviewing huge requirements document, it is relatively simpler to keep adding functionalities gradually and make changes per user feedback.

Summary

There has been an increased focus on maximizing customer satisfaction. CRM is projected as the answer to issues concerning customer satisfaction. But improper implementation just adds to the already existing worries the organization has to deal with.

Detailed planning, setting long term visions and effective participation of end users will help ensure a successful deployment thereby achieving greater degree of customer satisfaction.

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.