Sedna Webcast Part 3

Having watched the Sedna webcast yesterday, I was disappointed.

Firstly, I was expecting some more insight into how the development was progressing, and got very little. This was more than likely because my expectations were not met. The first line in the invite was New Capabilities in Sedna Drop 5. Not sure I saw anything I did not know before.

What the webcast (Webinar was the word they used, but I hate this word with a passion. The Americans have a lot to answer for the words that they have introduced to our vocabulary, leveraging is another word that I can not stand.) did focus on was Migration strategies, and this bored me to death.

I think the simple strategy for WAM customers is 'Don't migrate'. They kept mentioning their 'Inexpensive' off-shore professional service which would convert your WAM customisations to Smart Clients, but I can not see this working for many customers. I would rather manage this transition myself with all the heart ache and cost it would involve.

Rich Client customers - there is a point. Hopefully being able to re-use some of your VB 6 code will assist in this process, but there is still a lot to do. Pivotal showed us the Active Form to Smart Client form conversion, but the end result was hideous. I think that businesses will use this as a starting point, but I think they will have to redesign the forms significantly to make the users think they have got something from the effort they have put into upgrading.

Another point they emphasised is the difference between conversion and migration. Conversion being a re-write, migration being re-using your business logic in the new Smart Client. Both methods fill me with dread, and will be expensive, particularly in the regression testing that will be required. The tweaks they stated would be needed for a migration will be more than a simple tweak, if you don't want the end application looking hideous.

I think the 2 days migration time they quoted for a system that has had minimal customisation is a joke. For any of my customers this would be a significant project, taking months of effort to test and deploy.

Don't get me wrong, the deploy and wait for mobiles / satellites PBS is a good idea, and one that I fully support, as well as the ED migration tools and Agent explorer, but I will wait until I get my hands on it before passing judgement.

I am not sure that any user will be upgrading in February. I certainly won't recommend taking this leap until SP1 is out. But I am also hoping that new customers will be willing to go to Sedna rather than 5.9 early in the new year as from the previous webcasts it looks good.

Role on February (more likely March or April!)

To Customise CMS or Not

I have seen a lot of discussion recently on whether to customise the Out-Of-The-Box (OOB) functionality directly or not.

What I mean by this is whether, as a customiser, you should edit what is given by Pivotal (in terms of Client scripts / App server rules / table fields / queries) or should you create your own, using the base as a reference or even referencing them directly with an additional layer (for Appserver rules). There are Pros and Cons for each method, which I hope to summarise below, so you can make your own decision.

Direct Editing of OOB

• PRO: Quicker turn around for any code changes (as you don't have to create anything you don't have to)
  
• PRO: No additional dlls to cause issues
• PRO: Speedier performance as not calling 2 dlls to do the same function
  
• CON: Upgrades are more difficult, as you need to be careful not to replace any customised code
• CON: Difficult (unless properly documented) to know what is your customisations and what is OOB when something is wrong.
  

Adding to OOB

• PRO: Only use the bits of OOB that you need : if you don't want to use the OOB method for delete contact, implement your own.
• PRO: Distinction between what is your customisations and what is OOB
• PRO: Upgrades / CMS Hotfixes are easier to implement as you have not touched the OOB.
• PRO: Ability to use .NET Appserver rules for customisation even though the OOB is VB6.
  
• CON: Why alter things that are not broken? If you need to change the save form call in an Appserver, you will also have to provide functionality (or at least pass to the OOB) for Add / New / Delete / Execute etc.
• CON: Slower execute time as you are calling 2 dlls to do the same functionality that can be achieved by one. This is a negligible one now adays, but worth considering if you are doing frequent calls to an Appserver.
  

I admit that I am firmly in the Adding to OOB camp, as I believe the benefits far out way the negatives. This is also the Pivotal method. Not saying this is correct, but I always take guidance when it comes to the customisation of an application from the writer where I can. The time taken to create a pass through Appserver rule in .NET or VB6 is negligible, and I would rather do this than comment out huge chunks of code that I don't want.

I also apply this rule to Client Scripts / Queries / Forms etc. The first thing I usually do when customising for a client is take a copy of the Contact form, save it as Company Name Contact, and update security so the new form is the default. Same with the Form script and any scripts I need to alter that are referenced by the form. The Appserver, I will create a Company Name Contact .NET project and pass through to the original for all the methods (SaveForm, AddForm etc).

Hope this helps with any new people starting up in Pivotal development.

A Thanks and documentation

Thanks to Mr Kwiecinski for posting a link on his excellent forum (see link to right) to my lowly blog. I am astounded that a little mention such as this has resulted in people viewing my diatribe from as far away as Japan and New Zealand.

Also, a quick comment on his comment on my last post - heartily agree. As a partner, I get to see more that is coming from professional services than ordinary users, but this should be shared more. Allow users to play with bits, but have a one off charge to send them the code. This way the PS development can be charged for. The resources and examples out there are huge, but you need to know what to ask for and have a friendly Pivotal contact.

Last thing - when are Pivotal going to sort their documentation out? Don't get me wrong, the documentation is a lot better than back in the AA3 days, but there are still things that are not documented. How about a code sample in the API Reference for each function? What about ensuring the fields that are passed are explicitly labeled within the API?

Rant over, back to work.

Small World

Even though the Pivotal product is not widely used, it still surprises me how small a world is, well in the UK anyway. I often here about developers / consultants moving between companies, companies moving between consultancies but there still is not a lot of new customers (to my knowledge).

This is a worry, for a consultant like myself, with the knowledge that your key skill has a limited number of clients. I have always been critical of Pivotal's marketing strategy. Pivotal should be capitalising on it's key selling points - flexibility and stability. When Pivotal is installed at a customer site, the clients I have spoken to love it. It can do all they want, with the ability to expand to all they will need. Can you say that about MS CRM / Siebel etc?

I think Pivotal have missed a trick here, and hope (selfishly) that they start getting more clients soon. I know Sedna will hopefully be a huge step forward but please Pivotal, open the purse for some decent marketing.