Sunday, January 29, 2006

Impressing Customers on their own ground

These days I’m back in Norway for some pre-project activities. This is really a different experience for me being in the winter time (last time it was the summer). We had some interesting ‘Skying’ sessions and as a result I have a broken knee now :D.
Alright… now back on the business… Last few days we had very interesting sessions with few of our prospective customers. It was really a challenging task to impress them on their own ground (specially as they are software companies who know their business and the technology very well). Also being a technical guy it was really difficult to just forget the technology and concentrate on the business requirements. Anyhow during this visit I have learned many tactics of how to impress customers on their own ground.
The most important thing to do is, we should make them feel that we understand their business very well. This is a challenge as all the customers were in the business for many years and they have knowledge which they think obvious (implicit knowledge) but being a third party that is not so for us. So here are few guidelines which we learned and used to capture the business domain knowledge during the few meetings we had.
  • Let them describe the business domain they are working on. This is not about their company processes but about the industry as a whole. Here we need to understand where our customer stands in the industry (E.g. Market share).

  • Take the main business process of the company and discuss it with the customer. We have to identify where in the process IT fits in to. Use of activity diagrams was very useful in our discussions. Also ask them to take few common variations of this process if any exists (This is effective if the customer is a vendor of a product which is used by several of his customers).

  • It is really important to keep a balance between automated and manual processes, as most of the companies add value to their process through manual processing (Use of human intelligence in the process). These manual processes may give them an edge in competing with other firms. So we need to be care full in proposing IT automations of the process components.
  • Discuss the importance of IT to their organization. Guide the discussion such a way it reveals lot of non functional requirements such as performance, robustness, error handling, and scalability of the proposed system.
  • Talk about the current IT infrastructure. Discuss the strengths and weaknesses of the current system.

  • Talk about the competitors. This generally led to a really interesting discussion and reveals most of the expectations of the customer. Discuss the IT infrastructure owned by the competitors, which processes they perform better and what to learn from those.

  • Discuss the income break down of the company. That is which part of the business is bringing more income to the company, which parts are weaker and how IT can help them to grow. One thing we need to remember is that, at the end of the day it is all about profit and incomes (providing cool and nice features which do not bring any profit to the company are out of the interest).
  • Most importantly discuss what make their business to grow. For an example attracting more suppliers, attracting more customers and making the internal processes efficient may be the growth factors of a business. So the proposed system needs to address those factors to make the business to grow.
Actually working with prospects is fairly different and difficult compared to a traditional requirement gathering session. To win the project we need to focus well and impress them on our capabilities and understanding of the business. Trust building is the key to win a project. Good concentration focused questions, professional answers and well thought improvement proposals helps to build this trust. Also never forget to talk about your dog and his cat to build a good personnel relationship…

[tag: 99xb ]

Thursday, January 05, 2006

War between typed datasets and custom entities

War between typed datasets and custom entities

In Eurocenter currently we are preparing for a new project-kickoff which is going to be based on the .NET platform. Among many other design decisions we are currently considering an implementation technology for our domain model. We have to decide between "typed datasets" and "custom entities". Both the methods has their own pros and cons. I have done a small research on this and I thought of sharing those information through this blog post.

Here are some major reasons where I think datasets are better in some situations.
  • Database integration of the domain objects is very simple. DataAdaptor classes take care of the most of the database operations of the dataset. Also dataset has ability to remember the original values making the dirty object identification very easy.

  • Easy serialization of data entities to XML

  • Easy binding to most of the UI components

  • Easy integration with other tools and components (E.g. Biztalk Server)

  • Very good documentation and community support
Antway saying all those plus points of datasets, there are very strong arguments why and where we should not use datasets but go with custom objects.
  • Datasets makes the system less object oriented (as business methods are separated from the domain model)

  • Too much of generated code of datasets causes code duplication and lesser maintainability.

  • Exposing datasets as SOA can make services less interoperable.

  • Custom class approach is much cleaner and clear.

  • Unit testing is pretty much easy with custom class approach as data is easily bound to the operations.

  • Use of DataReaders, SPs and Custom Entities seems to perform better in the sense of memory usage and data fetch time.

In my opinion, we need to make sure that we use right tool at the right scenario. In a complex application (lots of integrations), I would prefer going with custom entities. If the application is a data driven or when the application is a disconnected data centered desktop application I would consider using datasets.