Infosys | Microsoft

On July 1, 2010 -  i had put forth a blog titled - Defining the Application Portfolio using the "EXIST" framework  which looked at a 'holistic' approach to choosing the 'right' applications for the enterprise. There were several comments and offline discussions which led me to post a follow up blog on the topic. Before going into this blog in detail you may want to check the original blog on this subject. And needless to say, i would look forward to your thoughts and opinions as this subject in itself is a lot debated one and there are no 'correct' answers as yet.

Before going any furthur, as a refresher, i would again like to define the "EXIST" framework - the 'EXIST' framework simply classifies the application needs on the basis of 'purpose' of the application. This helps in laying down some standard decision making criteria while choosing the application types for varying business needs.

The idea of this framework is NOT to advocate multiple applications; but to assess 'cloudability'  based on Business need, ROI horizon and Sponsorship. In the process it also breaks some myths that are prevalent in the IT circles.

MYTH 1: Cloud application sell to Business Leaders but not to CIO/IT team
REALITY: As per the Cloud Computing Survey 2010 by Sandhill Group; in 57% of the surveyed organizations (70% were sub-billion dollar in revenues), it is CIO or the IT department which is driving the adoption of cloud computing in business while only in 14% of cases, the heads of business units are doing the same. The reason is simple, CIO are not separate from business and need to respond to the need for Business Agility, Cost Efficiency while attempting to free IT resources to focus on innovation.

MYTH 2: Application Consolidation is order of the day.
REALITY: As per the same survey, 60% of the respondents mentioned that they use or plan to use cloud computing in the next 3 years. More than half the companies have been experimenting or piloting while a third have started deploying non-critical applications on the cloud. Interestingly, 20% have even started deploying mission-critical applications on the cloud. A consolidation in a deployment model is true but not across deployment models. There are few thoughts around need to plan the cloud strategy  to build out your next generation IT systems published by Kamesh Pemmaraju blog here . There is  a wonderful blog by Kevin Fogarty on CIO.com - Which Apps Should You Move to the Cloud? 5 Guidelines which outlines a few more necessary steps to take before deciding to move from a traditional app to a Web-based one.

Some of the "counter arguments" which were given to this concept of "EXIST" framework in my last blog are listed below. I would be more than happy to see a counter point for a mutualy rewarding discussion. Few feedbacks and my current thoughts are as below -

1. The market is looking at application portfolio consolidation as cost of managing disparate application is very high
   My Thought - In an on-premise model this is true; but in a model cutting across On premise and Cloud; it is not the case (as per the Myth 2 above)
2. ERP are one stop solution to meet all needs - either out of box or through customizations
   My Thought - While this is true to some extent; it is the business imperative and availability of "Cloudable" applications that have altered this thought process. A recent example is Royal Mail  - Royal Mail Group Limited, the national postal service of the United Kingdom,  has moved services for personal and small or medium business customers, and high-quality, innovative parcel delivery services to meet the needs of the UK's boom in online shopping onto the cloud. This "IT-on-demand" aims to transform its business and consumer online services, help to reduce its annual website IT costs and support expansion and diversification into a wide range of new web-based business opportunities without the delays and expense of traditional IT. These features can be achieved in "Collaboration" pieces of ERP as well; but then the time to return may be longer.
3. A consistent technology stack is something every IT leader thrives today to reduce TCO
   My Thought - This can't be denied; but then again some of the "cloud" applications have actually removed the headache of managing an application 'technically'. Of course this has led to difficulties around integrating the portfolio of application together. This is an area which is being focussed upon by number of players as focus moves from Application, B2B, Data and Event integration to Cloud Integration and focus on built-in web services framework for cloud applications.
4. The end users are pretty familiar with the application running for years any change in that will pose serious issues with their day to day operations efficiency.
   My Thought - Here, the basic premise is that the users are same across applications. However, in real business situations; we have seen cloud applications being used by front-ending staff, service personnel, client relationship personnel and liasoning teams while typical LOB applications (ERP) are managed by internal staff for financial accouting, order processing and manufacturing. Having said that, i think this aspect should always be considered at time to finanlizing the application strategy.

This is an exciting area and i am sure you too would have your thoughts. Please share the same. I would look forward to listening on this from peers, practioners and clients whom i am sure would be jostling with few of these questions themselves.

Posted by Sachin Bery at 8:00 AM | Permalink | Comments (0) | TrackBacks (0)

In my case this wasn't the issue as I had not changed the namespace and additional point was that if I used the auto generated test page, the application was working fine, but there was this error when used from my custom asp.net page.

I spent many hours trying to fix this. Since it was working for a test page but not my custom one, I got suspicious of if Silverlight had any issues in being used inside of a 'fieldset' tag in ASP.NET page or was it due to my using it inside of a 'MultiView' control? These didn't make sense however.

After a couple of hours of wasted time, it finally struck me. The test page like all typical Silverlight web applications was in the root folder. However the page from where I was invoking my Silverlight XAP file was inside of a sub-folder. The main issue was that the XAP file wasn't found (as relative path is used) and hence the error. If only Microsoft will fix it and raise more appropriate error messages. Something like "XAP file not found", will be so much more easier to understand in this case. 

I had to only add the extra "/" just before ClientBin in the path above and things started to work. I think this is a change that can easily be made as part of the default template implementation for all Silverlight projects as ClientBin will almost always be a root level folder.

Posted by Atul Gupta at 5:31 AM | Permalink | Comments (0) | TrackBacks (0)

Recently in one of our projects we had a requirement, where column TemplateName within an entity named Template should have unique values. Users were supposed to enter the value for TemplateName while creating a new template. Later on, saved templates were being used by all the users in the system. Obviously, duplicate template names would confuse users while selecting the specific template.  At a glance this seems to be a very simple and standard requirement.

In traditional RDBMS databases we would have created a column TemplateName as unique. In case of non RDBMS systems like Azure Tables, we start with querying the table to check if entered value for TemplateName already exists.  This looks simple to implement but the fact that values stored by Azure tables are case sensitive, makes it a little complex.
If we go by the approach of query, to check if the entered template name already exists then it would not be the logically correct solution. Due to the case sensitivity, the template names "AzureTemplate", "azuretemplate", "Azuretemplate" etc. will be considered unique, which could have confused the user while selecting the required template (e.g. AzureTemplate). We solved this problem by adding another column which stores Template Name value in UPPERCASE and referred the same column in the query for checking the uniqueness of the TemplateName value. The problem and solution are detailed below.

Problem Scenario:
Entity Name: Template
Earlier Structure: Entity Properties and Sample Values

    In this case we used to query the table Template against column TemplateName to check if record with the entered template name value exists. If user enters azureTemplate or Azuretemplate, then the query would return as the template name doesn't exist in the table and user could create a template with that name.

Solution:
   To overcome this issue of case sensitivity in the values stored by Azure table we have added one more column to the entity Template called TemplateNameCAPS. At the time of saving the template, we stored TemplateName in the capital letters in column TemplateNameCAPS. Later on, in the query to check the uniqueness we used the column TemplateNameCAPS.

Modified Structure: Properties and Sample Values

     Now, whenever user enters template name for the template to be created, we convert the entered values into upper case and query the table Template against column TemplateNameCAPS for checking its uniqueness.
     Now, whenever user enters template name for the template to be created, apart from storing the same value, we also convert the entered values into upper case and query the table against column TemplateNameCAPS for checking its uniqueness.
This helped us solve the issue of not allowing template names like "azureTemplate" or "Azuretemplate" when AzureTemplate value already exists in TemplateName column.
You might address the similar problem by not using another column but by converting the input to a specific case (lower, proper or uppercase) before saving it and use the same case for comparison.  We didn't do this to avoid changing the case of the template name value while storing and displaying it to the user. We wanted to keep the same case as what users have entered.
Hope you find this helpful in your projects too.

Posted by Sachin Prakash Sancheti at 11:46 AM | Permalink | Comments (0) | TrackBacks (0)

In the Web 2.0 world, companies are developing rich sites / portals to promote their services and products that intend to provide better customer experience. The objective is to increase the stickiness, provide self service capabilities, market the products to the customers and increase the revenue. Discoverability is the first step in the process to meet the above objective. Any large Brand site or e-commerce site needs to make sure that customers are able to find their sites first before the products and services can be targeted.

One of most common way users find the site is using Search engines like Bing, Google and Yahoo. The users search using the keywords and if they are related to your site, your sites should appear in the Search Results. Higher ranking in the search results will increase the probability of the customer navigating to your site. More traffic to the site translates into more opportunities to monetize and increase the revenue. Although different search engines have different ranking algorithms, all the sites need to be crawled if they need to be displayed in the Search Results.

If the sites need to be available as one of the top results, the site needs to be optimized from the search engine perspective. This is different from optimizing the Site search which the customers can leverage once they are in the Site and look for specific information within the site.

Microsoft SharePoint Server 2007 and SharePoint 2010 is becoming the Digital Marketing Platform for various companies. Sites created using out of the box components in SharePoint are not fully SEO (Search Engine Optimization) friendly. SharePoint 2010 is more SEO friendlier as compared to MOSS 2007.

The relevancy of the site can be improved in different ways. Some things which need to be kept in mind during the development and content creation of the web sites in SharePoint are as follows (most of these apply to non-SharePoint sites also)

1. Allow authors to add keywords to pages that gets added to the keyword metatag of the Page
2. Add the description of the page into the corresponding metatag of the Page
3. Make sure that author provides the title for every page and it is present within the Title Tag in the rendered Page
4. Have meaningful Page names
5. Prepare Sitemap.xml with all the key links that needs to be crawled and update it regularly. This can be generated by a Tool or via PowerShell for SharePoint
6. Generate Robots.txt file with the list of directories which need to excluded from Search engines (http://websiteURL/robots.txt)
7. Avoid using images for navigation controls. Always use simple, readable text which the search spiders can crawl
8. Avoid using nested tables in HTML. Make sure that all custom Web parts, custom controls, Master Pages and Page Layouts are XHTML complaint (Many out of the box controls and Pages in SharePoint are not fully XHTML complaint)
9. Avoid any inline Styles. Always refer to a separate CSS files
10. Avoid inline Scripts. Always refer to external jQuery and Java scripts files
11. Avoid unnecessary redirections within the Site
12. Semantic URLs would help. Leverage URL rewriter (http://www.microsoft.com/web/spotlight/urlrewriter/)

NOTE: The list is not a comprehensive list. 

There are many tools in the market that helps evaluate the web sites for their friendliness with the search engines. SEO Toolkit from Microsoft is a free download that gets integrated with IIS 7. It analysis the site from Search engine optimization perspective and provides the recommendations to improve the relevance of the web site in the search results in major search engines.  More information regarding the functionality of the Tool is available at http://www.microsoft.com/web/spotlight/seo.aspx .

I think every project that is developing web sites especially on Microsoft Stack (ASP.NET, SharePoint, and IIS) should start leveraging this tool to make their site Search Engine Optimized.

Please follow the URL http://www.practicalecommerce.com/articles/368-SEO-Toolkit for details regarding other Tools in SEO space.

Posted by K. Suyog Hebbar at 11:05 PM | Permalink | Comments (0) | TrackBacks (0)

Sizing is an important aspect as it helps our clients and the delivery teams to be on a common foundation and understand the way the business needs of today and the future would be met by the package through package solution definition, configuration, customizations and workarounds.

Sizing is not only related to the cost of the project but is a good measure of assessing -

• What is the size of the business need of the client that need to be achieved in the application?
• What is that business functionality that is available out of box from the package?
• What is the business functionality that is available in the package but is not the current business need for the client?
• What is the future business need of the client that would have to be incorprated in a package?
• What are the features in the product roadmap that may meet the client future business needs?

While recommending a package to our clients, we are always concerned about answers to these questions. Besides this, we also need to look at the overall portfolio and technology footprint. I had touched upon the EXIST framework for Application Porfolio Management which can work along with sizing perspectives to give real value to our clients.

I thought that it might be a good idea to depict this "Sizing Concept" in a visual form for clarity. The figure below depicts the footprint of the 3 buckets of fitment for 2 different packages and same client needs.

This is the convention -

• X represents the coverage of out of box functionalities of the product meeting the client needs.
• Y represents the coverage of un-used out of box functionalities of the product that the client does not need.
• Z represents the coverage of additional customizations that need to be done to the product for meeting the client needs.

In the figure, the first package is an advanced package application (like Microsoft Dynamics AX) with a lot of functionality. The client need would be met out of box (X1) with some customizations (Z1) while a large portion (Y1) would remain unused. Taking an example, we can have a client who needs Financial Management, Procurement and Sales as a business need. This can be met mostly out of the box in AX (X1); but there could be some customizations needed in the product (Z1) around the way credit history needs to be verified and holds applied on Sales Orders. However, there would be lot of functionalities like Warehouse Management, Manufacturing, Process Manufacturing, Master Planning, Project Accounting, CRM, Service Management, Human Resources Management, Employee Self Service Portal, Payroll, Expense Management, POS/Retail Solution, etc. which are available in the product but would remain unused (Y1). These may be needed by a larger enterprise as the need for an ERP expands into other business lines and functions. Hence, this will work well for clients where we have a clear future roadmap for the advanced features which may/would be implemented in future.

On the other hand, the second package is a leaner product with lesser functionality (like Microsoft Dynamics NAV). Here the same client need would be met to a lesser extent out of box (X2) with more customizations (Z2) while a smaller portion (Y2) would remain unused. Taking the same example as above, we can have another client who also needs Financial Management, Procurement and Sales. This can be met to a lesser extent out of the box (X2) and would need more customizations (Z2) around credit history, holds, workflow, requisitions, reporting, etc. There would be lesser functionalities available beyond this in the product (Y2). Hence, this may be a good option for client whose needs are more or less defined and would not change or expand into other areas too much.

From the sizing perspective; this means that in isolation percentage fitment can't be classified as GOOD or BAD. It is the overall context of X, Y and Z which will help define the true sizing and fitment.

Does this make sense? Do let me know...would look forward to your PoV on this.

Posted by Sachin Bery at 12:39 PM | Permalink | Comments (8) | TrackBacks (0)

Can package application based implementations be sized just like the way an ADM work can be? Is it feasible to use FP estimation methodology  for package implementations? These are some of the question I have been trying to get an answer for in a quest to identify a mechanism to effectively size package applications in general and MS Dynamics apps in particular.

Over the past few weeks, I have come across multiple mechanisms. On one hand, there are the standardized methodologies based on FP which do not directly fit in this space given that we are talking of a large base of functionalities/features already available in the package even before we start thinking about the client requirements. On the other hand, there are SME developed mechanisms/tools, of which most seem to be derived with effort spent as the key basis of sizing.

This has led me to  think of  a sizing methodology which takes the best from FP based sizing methods as well as effort based methodologies. The benefits from such a methodology should be:

• Will enable a holistic sizing of a package application (MS Dynamics in our case) based implementation.
• Allow practitioners to compare the size variations across products, eg. Variation if choice is between AX & NAV thereby enabling optimum product selection for customers
• Will enable delivery teams to measure productivity improvements over a period of time by being able to compare similar sized projects.

From a package application perspective, the client requirements can be classified under the following buckets:

1. Direct Fit with the features available in the package
2. Not a direct fit but can be met with extension of the package application
3. Requirement cannot be met by leveraging the product base feature and hence needing customizations

Among the three categories mentioned above, in principle, I could use the FP sizing technique directly for the 3rd one to a reasonable extent. But for the 1st and 2nd categories, the size becomes a challenge as the composition of the solution is  two-fold. The size has to take into account the base features provided by the product, some of which may not be of any use at all for the customer. This adds to the complexity as it is imminent to first arrive at a size for the base features of the package. The closest this can be compared to is with a book with a lot of content. The size of the base package would be akin to the size of the book. But the actual solution would be  like buying a book for one of the university exams that has some portion of the relevant syllabus but because of the other content, its size is larger than what is actually needed. :)
 
Going by this, another inference that could be derived is that, the size of a solution with the same set of requirements will be different for different packages. This would  depend on the base package application that is selected for implementation. ( Analogous to different books available in the bookstore for the same syllabus).

From a mathematical point of view, assuming that we have a standard unit of measurement for the size (sizing point), key constituents of the overall implementation size would be

• X sizing points for out of box supported functionalities
• Y sizing points for un-used out of box functionalities
• Z sizing points for additional customizations

Based on the package being considered, the value for all these variables would vary, thereby making the size different. The above illustration may look simple but arriving at X, Y and Z values is the real challenge!!!!

I am still thinking on the best approach (available already or otherwise) to achieve this sizing but am sure the same thought would have occured to other practitioners as well.

I remember one previous post by my colleague Sachin about the percentage fitment anomaly which again highlights the need for a sizing mechanism for package implementations and is not restricted to only fitment and/or effort estimation.

In this context, I do look forward to hearing back in case you come across any such methodology which is able to address these challenges.

Posted by Amol Gupta at 9:56 AM | Permalink | Comments (1) | TrackBacks (0)