Wednesday, February 18, 2009

Do you have a content management system?

I have encountered this question several times and many many arguments from people.

Based on my experience, the best time to implement a CMS system is when you have decided redoing your website. Well am not saying that a CMS cannot be implemented for an existing site. This is very much possible if your site is straight forward, else you will end up investing much time and cost for casting your site to fit into the CMS without “customizations”. If you are ready for a compromise you may not fall into the above situation.

You need to ensure that the need for CMS is communicated to the team working on the website well in advance and if you have any particular CMS in mind, that too. Many often it happens that the design is quite difficult for a CMS as the designer is trying to show his best!

So you've decided that a content management system (CMS) is right solution for you, well there is some more things you need to know more now. I have tried to put these in the sections below.

Deciding your CMS

This section is comparatively easier than the next one :)

  1. Inform your agency to design a website with DIV Based Layout and CSS. Now it is necessary to have a CMS to have a DIV based publishing. From my experience most of the CMS systems are designed this way
  2. What kind of CMS? Typically this can be categorized into 2
    - Open source CMS (some may have some paid service)
    - Enterprise level CMS

    I would say you should decide on a CMS tool that matches your agency’s capability. I have seen many instances where the client insists for a CMS system and the agency will make this works in the scare of losing business. The problem starts when a customization is required or when problem arises. I would always prefer a CMS that has an online support, this can be even a open source.
  3. Ensure that the CMS is SEO friendly. The easiest way to ensure this is to check whether the CMS supports Permalink
  4. Non-technical CMS – The users of the CMS should be able to update the content with several clicks without knowing HTML, CSS etc. This should be as easy as using a MS Word or any editing software of this kind. The CMS can have many advanced function like workflow, queuing etc it should not be confusing the user
  5. Ensure that your CMS is adequate enough to handle web vulnerabilities plays. Today the online script vulnerabilities are very high and you don’t want the website to go down due to this

I made a sincere effort to see which is the best CMS in terms of implementation and customization . Follow this link to know what others say...

http://www.linkedin.com/answers/technology/web-development/TCH_WDD/429527-15102360

Thursday, February 12, 2009

Take Responsibility for Your Missteps!

I happened to read this article and found it very interesting. This is from one of the tips of day from Harvard Business School.

Every manager makes mistakes. When you do, resist any urge to attribute the misstep to forces beyond your control. A defining mark of effective leaders is their willingness to take responsibility for their failures.

To keep yourself accountable for mistakes, adopt these practices:

  1. Stay vigilant. Make sure you're always aware of what's going well and not so well in your group. Doing this successfully requires taking frequent steps back from the day-to-day flow to observe and reflect.
  2. Acknowledge the consequences of your mistakes. To do so isn't a sign of weakness; it's a measure of leadership. The sooner you accept that you've slipped up, the sooner you -- and your group -- can move forward.
  3. Resolve to improve. Before you can improve your own performance, you must commit to making a positive difference. To make sure you follow through, return to step 1.

Friday, February 6, 2009

Website and custom developed applications…

I always give this feedback, never get into the business of developing things that’s not your core focus like shopping cart, chat engine etc. Definitely my intention is not to ask you all to download and use whatever free application or open source you get on the web.

Let’s take the example of shopping cart, reason being a module that requires much integration. Today you have several companies that are core providers of such modules, these modules does not cost you much compared to your effort. Most of these offer one year free updates and support also, even the price will come down on every purchase. You can even buy the necessary modules instead of buying the whole bundle.

These modules will give you the power of skin customization for sure, may not be 100% percentage. It is not difficult to convince your client as you can show them the clear benefits. Today everyone wants to cut costs and organizations are saying no to products that costs high, which needs an average of 6-8 months customization. A ready to deploy solutions is what all wants!

An average shopping cart will consume 2 – 3 months of effort including integration and testing. If your organization charges $10 per hour, and with 2 resources this will cost $6000 to build. The ready to deploy module is available for $2000 and your time for integration will be 100 hrs, max.

Sure I can even build one reusable shopping cart and use it across my projects. I will accept your answer if the answer is yes for 2 points below.

1. Is this your regular business or core competency?
2. Are you a domain expert in this business?
3. Are expecting at least 10 such projects in a year?

Building a shopping cart is not difficult, but do you have the bandwidth to maintain this module?
Image, with this approach the entire project delivery cycle will come down at least by 40% and that’s a clear benefit for you and the customer isn’t it?

You may have a different approach to this, I would be glad to hear it!

Cheers,
Sudhish Chemmur

An interview that made me think…

Architecture that works well for web application development…

3-tier architecture, n-tier architecture is the commonly used words in today’s world and each of them have a different story on how they achieved isolation of various layers. I have been doing many experiments on this and several POC’s were established, but I could never make a POC that worked the way I wanted…

During one of my discussions with a company interviewer, I was asked “how can you decentralize the business layer, thus enabling multi-server hosting” using .net. I was shocked for a moment on how to answer this. I thought for a while and told him that “hey I have not attempted this but it is definitely possible by using web services effectively for inter-module integration”. The next question was “How”, I paused for a while and told him, well I will plan my modules in such a way that objects with higher interactions will be grouped together and each groups will be interacting with each other using WS, thus enabling multi-server’s. Again “okay, give me an example”, the only think came to my mind was the message queue service which is a reasonable answer (I read about the mail queue architecture on web the previous day).

Frankly speaking the same old repeated explanation came to my mind, “business logic layer is a layer that contains an application ‘business logic’ and is stuffed between a persistence layer & presentation layer”.

I was not sure whether my answer was correct at that point of time, but it was definitely wrong for the interviewer as the job was never offered :)

The above incident made me think more for sure. I wanted to crack this and was ready to put in more time to find a solution / approach. Finally I have something to share with you all, now it’s up to you all to comment on this with your thoughts…

The main idea was to use XML/XSLT, of course we all know that it separates the presentation from the business logic.

I see many advantages in this approach.

a) You don’t have to re-invent the wheel again, since the reuse of business logic code will be reliable and faster
b) You don’t have to tamper with any code at the business layer to take care of your branding, look and layout
c) The designer – developer idea exchange / dependency is always a fight (DIV is the best, No html is the best), the dependency here is very less
d) The testing cycles can be restricted up to interface level
e) The validation can be controlled at XML level hence no need to touch the code even for validation changes. Validation here refers to the field level such as First Name, Last Name etc

The disadvantages I can think of below

a) You will not be able to use VS up to the extend you are doing now
b) Since the Ajax control tool kit is not fully reliable you many have to use a normal way, if you are looking for a google style
c) XML cache issues along with the mixed content will be another problem to handle

If any of you want to know what I mean by XML & XSLT, read the sample from
http://www.w3schools.com/xsl/xsl_transformation.asp

Coming to XML, it can represent any data structure and MS SQL Server has option to output data in XML format, which makes it easier.

All of these above are much easier to handle, now the next item to tackle is to build in the ability for multi-server operation…After much reading, I have found a solution for this also. The assumption I had in mind was of an application where the delivery has to be done in various devices such as browsers, mobile platform, Kiosk’s and desktop.

Let’s assume that the application we are developing is a Air ticket reservation system where consumers can book online using browsers, mobiles and also through Kiosks, corporate will be using a desktop application for reports and all such related stuff’s...

While doing the BLL, I will ensure that the module that requires high integration is kept together. The SMS & email alerts definitely will be a detached module that will be invoked on demand (sending SMS, email after a successful booking) using WS and also this module will be capable of doing scheduled stuff’s like reminders etc. It is also possible to detach the scheduled stuff to another server if required. User profiling and reservation / cancellation will be kept together as interactions are high here. The payment module can be again kept separate if required as the gateway is 3rd party and will not have any issues. The reporting engine will be individual engine hence am not too bother d about it. The other modules that will have high interactions will be the flight schedules, routes and crew.

I am not very sure whether my example really made sense but I would always make a chart of all modules and degree of their interactions before deciding on the separation of BLL.

The interface of the application will not be a problem in browser, mobile and kiosk’s as we have planned it well and this architecture is futuristic, that can stay forever as we have thought through the whole...

Moreover, you are not dependent on any system variables; hence having no impact for upgrades and updates since you can handle each of them individually!

I hope this was helpful, looking forward to hear more from all…


Cheers,
Sudhish Chemmur