Infosys Microsoft Alliance and Solutions blog

« July 2010 | Main | October 2010 »

August 30, 2010

As you sow, so shall you reap: Effective Application Portfolio with 'Cloud Inclusivity'

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.

Silverlight Error 2103

Recently while trying to integrate an existing Silverlight component into my ASP.NET based application, I got error 2103 "Message: Invalid or malformed application: Check manifest". Online search resulted in almost similar answers everywhere that talked about a change in project namespace and not correctly reseting the startup object.

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. 

<param name="source" value="/ClientBin/FileUpload.xap" />

 

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.

 

 

August 23, 2010

Unique Column values in Azure Table Entity

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

PartitionKey (Literal)

RowKey (TemplateID)

TemplateName

TemplateDescription

Infosys

1

AzureTemplate

This template is used for Azure

Infosys

2

AmazonTemplate

This template is used for Amazon

Infosys

3

GoogleTemplate

This template is used for Google Apps

    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

PartitionKey (Literal)

RowKey (TemplateID)

TemplateName

TemplateNameCAPS

TemplateDescription

Infosys

1

AzureTemplate

AZURETEMPLATE

This template is used for Azure

Infosys

2

AmazonTemplate

AMAZONTEMPLATE

This template is used for Amazon

Infosys

3

GoogleTemplate

GOOGLETEMPLATE

This template is used for Google Apps

     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.

August 11, 2010

Connecting the Dots: Sizing & Percentage Fitment for Package Applications - A Perspective

While working on the Sizing Approach, we have found that there are various factors which come in play to define  a "true" fitment of the package application to the client needs. Some of these factors are described in my previous blog around "Percentage Fitment Anomaly - Gosh! Did I just over-sell/under-sell the product to my client?". There is a detailed blog by my colleague Amol Gupta around the Challenges in Sizing Package Application Based Implementations which brings forth the concept and its related dimensions. This blog is an attempt to try and explain this furthur to stress on the need of having a multi-dimensional view of the fitment before selecting a package of choice.

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.

 

sizing_representation.jpgThis 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.

 

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter