Risk Management in IT outsourcing: How much commercial risk is reasonable to shoulder

Risk management is defined as identifying, assessing the impact and prioritizing the risks associated with the execution of a project or program. There is a relationship between how risk is managed and the relationship that a service provider shares with the client. Sometimes risks can arise from the internal application of resources and sometimes they can come from external factors. From a service provider perspective, focusing on risks that arise due to external factors poses the question, “how do you decide on how much of the external risk should you shoulder?” For example, in cases where a client fails to meet its commitment on providing certain resources results in a schedule risk towards the delivery of the project. To me the answers seems to lie in the responses to the following two questions

1. Where do you stand in the current relationship with the client?

2. Where do you think the portfolio fits with your strategic goals?Where do you want to stand in the relationship in the future?

Relationship is an absolute must as a contract is neither self-enforcing nor self-adjusting. If engagements are driven through contracts, there is no trust and no relation. Although a transaction-based relationship can lead to future opportunities, the risks associated are very high compared to a relationship-based engagement. There is a higher sense of trust in arelationship-based engagement compared to transaction-based engagements.

Relationships can either be transactional, a partnership or a strategic partnership. As trust amongst the parties involved increases, the relationship moves from transaction oriented to strategic partnership. The catch is how we create the sense of trust with the customer.In my opinion, the answer is for the service provider to start thinking from a customer perspective and identifying the risks as the first step. Once risks are identified propose a structure where the service provider is sharing the risk with the client. Once risk is shared there will be enough focus on identifying ways to reduce the negative effect of the risk. The one most important thing that the service provider should not do is to transfer the risk if the intention is to take the relationship in the right direction.

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/719

Data Processing: Do you Map Reduce for Large Datasets

A common problem statement that customers talk about is being able to process large amounts of data quickly. Some of them have the ability to scale up horizontally and some of them have to come up with alternate ways to improve the processing time. Map Reduce implementations can be applied to any Cloud deployment model.

Map Reduce is a is a patented[1] software framework introduced by Google to support distributed computing on large data sets on clusters of computers. Hadoop Map-Reduce is a software framework based on Google’s map reduce for easily writing applications which process vast amounts of data (multi-terabyte data-sets) in-parallel on large clusters (thousands of nodes) of commodity hardware in a reliable, fault-tolerant manner. The 3 core pillars of Hadoop are Map, Reduce and HDFS (Hadoop distributed file system).

Large data sets are split into smaller units for processing and are processed by the Map tasks. Map tasks can run in parallel independent of other Map tasks or any other tasks. The output of Map tasks is normally referred to as “Intermediate output”. The output is always in the form of a map. The output of Map tasks act as input to the reduce task. The intermediate output is sorted by the Hadoop framework. The reduce task is then responsible for reducing the set of intermediate values which share the same key on the intermediate output. In general we find that both input and output are stored in some form or manner on a file system. Figure 1 below depicts map reduce processing. We can introduce a combiner operation in addition to Map and Reduce that will be responsible for local segregation of data based on key prior to the reduce task.

Figure 1

One of the core features of the Hadoop Framework is HDFS. HDFS stands for Hadoop Distributed file system and is the configuration that allows the framework to effectively schedule tasks on the nodes where data is already present, resulting in very high aggregate bandwidth across the cluster. The distributed file system can handle large files with sequential read/write operation. Files are split into smaller units and saved on local nodes.

Through Hadoop, you have the ability to run parallel, concurrent versions of the mapping and reduction code to generate the desired result in Batch processing mode. I have seen a typical problem of non-availability of server hardware in the desired environment whereas a lot of server hardware lying idle and the logic to process large amounts of data is very machine dependent. Major configuration implementation is required before we could use a server and as always Data should be delivered yesterday. This is a major advantage of the Hadoop implementation where Programmers familiar with the problem domain can write elegant solutions without worrying about the multi-processing nature of the task. As long as the infrastructure is in place to synchronize process execution across multiple threads, processors, or complete systems adding Hadoop can work wonders to utilize available capacity with very minimal configuration change.

One question I wanted to pose is how do you ensure that you have replaced the legacy home grown systems with logic embedded in code for both functional and non-functional implementation for data processing with a Map Reduce implementation appropriately. This problem is typical for Data intensive systems as to “How do you test a reservoir without filling it” in this case how do you know the data is correct unless you have tested the full data.

Obviously one question that follows data processing is how do you use it efficiently through a machine learning system. I am fascinated by the concept and implementation of Lucene Mahout and will share my thoughts around that later.

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/718

Sell Where Your Customers Buy

Many marketing or business planning discussions eventually hit on the seemingly self-evident notion that you should "Sell What People Are Buying." (For a humorous discussion of this, see this blog) In addition to this basic truth, it is also important to "Sell Where Your Customers Buy." Think of the sidewalk entrepreneurs in New York City selling ice cold sodas or bottled water out of a cooler on the corner in lower Manhattan on a hot summer day. These vendors are able to charge a premium for a cold drink because they are right where the people are walking and thirsty - they are selling Where their customers want to buy.

For Information Providers, this truth is becoming very important. Not only is the Information industry moving heavily from a print to an all-digital delivery model, and not only are the roles of intermediaries and centralized procurement "locations" (such as corporate libraries) being diminished, and not only do Information Consumers have more choices and more access mechanisms than ever before, but in addition the easy access to information is changing the notion of information gathering from a stand alone task to simply one small (and hopefully automated) step within a larger process. Let me explain what I mean in a little more detail.

We all know that Print media is turning Digital. See the news stories about declining Newspaper readership, Amazon's (and BN's, and Border's, and...) push for digital books, the frequent discussion about the "Google Effect" on content providers, and the Open Access Initiative. The digital content is available on many platforms - the web, your mobile phone, smartphones, tablet computers, and e-readers. Information Consumers expect to be able to read the articles, analyze the data, and do their jobs on any of these devices, anytime during the day, on the train, in the airport, or wherever they are. This is what I mean by "Sell WHERE Your Customers Buy" - you need to be able to sell the article, or provide the data visualization, or the drill-down analysis on any device connected to the internet. If your valued, long-term Customer is sitting in the airport, curious about something she is not going to wait to get back to her office to use her subscription service to order a new report - she wants to download it to her phone, right now. If your service does not provide that, she will go to your competitor's app and get her Information right now. Your valued, long-term, trusted relationship goes right out the window because your Web 1.0 Information Delivery website cannot meet her expectation of instant information access.

The effect of this is to require every Information Provider to need an iPhone app. Well an iPhone app and an Android app. Oh, and an iPad app. And probably a Galaxy and Playbook app. And of course, a mobile friendly version of the web site. You can see, this quickly adds up.

Early attempts to create mobile apps usually involved creating a separate application stack, content collection, or Information Delivery Channel. This was the quickest, and least expensive approach to get the first mobile app out and does work. But the cost curve is not pretty, and you soon need to maintain and support 10 different applications, delivery channels, etc at 10x the cost for only marginal revenue increases.

The better approach is to build an API. Not just a dirty hack of a url that can be used to access content, but an actual, thought-out Service Oriented API that provides billing, metering, search, retrieval, and easy integration for apps. Now those 10 apps are just thin layers reusing the core SOA enterprise services and can be built and maintained cheaply. Better yet - if you have a loyal community who truly values your content, they will wind up building innovative apps on every platform you have never heard of to access and embed your content. This is because your customers are empowered to scratch their own itch, and build an application to solve their own personal or particular corporate need. And it turns out that a lot of times your customers know how to use your content better than your own product development team -- so the apps they build and the embedded data usage they put together are more useful to your customers than the pre-built website or stand alone applications you might design. Your customers become your distributors and open up entire new retail channels you were not even aware of.

So... you get more sales channels, at a cheaper delivery cost, with more customer value from enabling your content through an API. Sounds like a Win-Win-Win!

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/717

Enterprise Search and Beyond – Part 1

Did you know that Gartner is changing Enterprise Search from Magic Quadrant to Market Scope. Inclusion of this in the Magic Quadrant and moving it to Market Scope itself is a testimony that an organization or an enterprise if had not already included search as a business strategy or productivity tool, needs to make it available for its knowledge workers.

Enterprise Search can augment people, business and knowledge areas coupled with actionable items that directly impact profitability, business productivity and information awareness. With Microsoft’s acquisition of FAST, Google in a box Plug/Play Search Appliance, Lucene/Solr and many other vendors offering tools, this space has become a cynosure in the current day. Needless to say, the heterogeneous data in an Enterprise makes it even more compelling to have the capabilities to search for the needle in the haystack.

Knowledge worker is spending 9.5 hours a week searching using various tools and interfaces. Companies that are poised to leverage Search in their Enterprise are bound to experience newer horizons not only in terms of productivity but knowledge worker’s satisfaction and an Enterprises overall information awareness level by consolidating widely scattered data silos existing in structured, semi-structured and un-structured formats.

Why Enterprise Search? . Let’s take a real time example of the following error code (-81024) which resulted when a trial version of a HP product was tried using a Windows 7 client machine. An Internet search revealed that there was no clue even from HP other than the fact that it is a compatibility issue. The knowledge base from HP could have been a little outdated or could have been lurking in a data silo making it difficult to find the needle in the haystack.

Business Drivers :

1) A pre-defined business value should be the most important step in identifying the need to have an Enterprise Search Platform in a given organization. Example: A smart phone for a sales person Versus Enterprise Search Platform for Support Professional

2) Information that is available in silos namely individual desktops, emails, Intranet Portals, RDBMS, CMS is not projected via a single interface and employees need to run from pillar to post or get help from outside or re-invent the already existing information thereby duplicating efforts

3) Knowledge and Action are tied up and the results of the Search needs some actionable items geared towards monetization or improvement of job productivity of an information worker within an Enterprise

4) Right information to the right people at the right time improving business productivity

5) Different relevancy models for different users in an Enterprise facilitating anticipated discovery

6) Push-Pull model where Search provides related info via push that was not explicitly sought for

More to follow in a sequel to this blog...

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/716

Medline versus PubMed

Is it prudent to call the title of this blog ‘from Medline to PubMed’ which of course is the truth from a Data Structure perspective because the FIELD queries used for bibliographic searches are much more sophisticated than keyword search queries directly used in PubMed

PubMed is the FREE version of Medline which is maintained by US NLM (National Library of Medicine) and PubMed is the brain child of NCBI (National Centre of Biotechnology Information) in addition to Genbank and BLAST which I will cover at a later time.

·Point your browser to http://www.ncbi.nlm.nih.gov/sites/entrez?db=pubmed which launches the PubMed home page. Entering a string such as ‘Leukaemia’ yields a sizeable count with author name, related citations and most importantly PMID (PubMed Id) which can be used at a later time

·A classic case to use the Fields would be to search for Down which could result in both Down syndrome and an Address containing the word Down. Here we could leverage MedLine fields Down[AB] or Down[AD] for Abstract or Address as applicable which will restrict the count and have meaningful result set

·Click on the display settings to see all formats such as XML, MedLine, Abstract, Summary etc… The option MedLine is an area of interest which is nothing but a pool from which PubMed gathers its information

·The essence of this blog is to use PubMed and the free articles which can be filtered from the LIMITS option available near the RSS icon. The LIMITS\Text option displays check boxes to choose from ‘Links to Full Text’, ‘Links to Free Full Text’ and ‘Abstracts’. Free articles will directly take you to the publishers site and of course, one could purchase anything that is of importance after looking at the abstract

·There are some limitations with PubMed however such as unavailability of Abstracts for references recorded prior to 1976 and no papers prior to 1965

I hope this simple primer will let the reader understand what PubMed is all about!

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/711

Project Management: Medium Raw

I’ve recently become a fan of Anthony Bourdain. Tony is host of ‘No Reservations’ – a travelogue for those who enjoy international travel, off the beaten path eats, and sarcastic, sinister, and always honest humor.

Tony started as a cook and worked his way up the ranks to owner of ‘Les Halles’ in New York City, through many highs and lows with a mix of cockiness and humility when needed. It wasn’t his cooking that put him on the map though; it was his exposé on what really goes on outside of the dining room in restaurant kitchens – a book called Kitchen Confidential.

In Tony’s recent book, Medium Raw, he declares it a shame that high schools across America stopped teaching Home Economics due to the rise of feminism. Instead of abolishing the class, Home Economics should have been modified to include both genders. Tony believes that everyone should know how to use a knife, how to cook a steak (and let it rest!), how to roast a chicken, and how to make an omelet. These are the basics, the essentials, which everyone should know how to do.

Like Tony, I get frustrated when I watch people ‘butchering’ a craft. In my case, it’s Project Management. I believe there are certain basics, certain fundamentals, which one must do in order to not cut their finger off, decimate the steak, and dry out the chicken. These fundamentals are as follows:

1) Plan. Create a Project Plan. Not just the MPP version which has all the tasks, dates and resources on it, but a real plan describing the project, explaining the deliverables, defining the methodology, documenting risks, special requirements, technology to be used, etc. This is the same as learning to use the knife. If you don’t know how to chop, you should get the hell out of the kitchen.

2) Understand the requirements. Don’t just depend on others to do all the understanding for you. It’s like the owner of a restaurant who has never rolled up her sleeves and cooked. I once worked with a manager who declared ‘I don’t work, I manage.’ And so he managed himself right out of a job.

3) Communicate. Open your mouth and holler when you see a risk. And you better write it down too in a Risk Tracker. You must communicate to your team and communicate to your client. And it’s a lot more complex than that. You need to know how to tailor your message depending on with whom you are speaking. Maybe it’s another Project Manager whose application will be integrating with yours. Maybe it’s your newly hired tester who needs a lot of coaching. Maybe it’s the President of the company. You better know what needs to be shared with each of these fine folks. Just like the chef at a busy restaurant better know when the fish is being delivered, that the dishwasher isn’t coming in tonight, and that the front of the house is getting slammed. And he better know how to communicate with each person to make sure that every customer walks out with a smile on his face.

4) Know your scope. What did you sign up for? What does the agreed upon statement of work between you and your client state? Are you following this? If not, have you put a change order in place and received signoff on it? If not, and you deliver something completely different than the customer asks for, weeks later than originally planned, guess who’s at fault? I don’t care if you added all those fancy bells and whistles… you didn’t deliver on what was promised effectively. You burned the omelet.

5) There is a term in the restaurant business called being ‘in the weeds.’ It’s basically when someone is in trouble and they are having a heck of a time climbing out. If you’ve seen the television show ‘Hell’s Kitchen’ then you have had a chance to see it each week. The ruthless chef, Gordon Ramsay, makes determinations of how to fix it ASAP before the entire restaurant crumbles. He triages the situation and determines if he can get a backup or needs to promptly kick someone out of the kitchen. A good Project Manager knows when her team is ‘in the weeds.’ And with experience can generally triage the situation and get things on the right path. The first step is knowing when there is a problem. The second is figuring out how to fix it. Like Bourdain, I get ready to pull out my hair when I see a green status report coming in every week for a project riddled with major, complex, issues.

And a final basic: Say Thank You. There are times when the team steps up to a challenge, and they need to know it is appreciated. It makes them far more likely to want to step up again when it is called for. It doesn’t need to be grandiose measures – sometimes it means taking the team out for a drink or giving someone a special award. A Project Manager cannot deliver the project by himself. Like the head chef in a restaurant who are dependent on a sous chef, line cooks, wait staff, etc. etc. If you don’t respect your team, how will they ever respect you?

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/710

The New CMOS - Cloud Mobile Open-source Social

CMOS is a well-known acronym in chip manufacturing meaning "Complementary Metal-Oxide-Semiconductor". According to Wikipedia:

"CMOS" refers to both a particular style of digital circuitry design, and the family of processes used to implement that circuitry on integrated circuits (chips). CMOS circuitry dissipates less power than logic families with resistive loads. Since this advantage has increased and grown more important, CMOS processes and variants have come to dominate, thus the vast majority of modern integrated circuit manufacturing is on CMOS processes.

In other words - because this way of designing and building chips has distinct advantages in improving efficiency and enabling new features, it has become the dominant approach to building chips. Any mainstream (non-experimental) chip manufacturer has settled on this process because of the inherent benefits.

There is a new CMOS taking over the software development industry - "Cloud Mobile Open-source Social." New applications, whether they are commercial software products, internal enterprise applications, or B2C web applications (think "Web 2.0", Linked Data and related) are - by default - leveraging the combination of Cloud, Mobile, Open-source, and Social technologies to enable rich feature, scalable, always on applications that are developed faster and cheaper.

Users expect 24/7 access. Consumers expect to be able to share and tag and link content. Readers expect to be able to access articles and applications on any computer, any device, anywhere. This is a fundamentally different mindset than "traditional" application development and traditional publishing models. It requires new ways of architecting applications and new ways of thinking about data and content. It's a heck of a good place to work!

Trackback URL for this post:

http://www.allianceglobalservices.com/trackback/708