Marching to the beat

It's amazing how many parallels can be drawn from an IT project to reflect many situations in life. Let me start by giving you my definition of a project as it may help to highlight the point I'll be trying to make here. 

A project is a group of individuals working together to achieve a beneficial outcome

Quite a simple a high level description but I personally feel it succinctly describes what it projects are all about. Like any machine you can care to think of, it's a sum of specialised parts brought together to perform specific tasks, each component has a responsibility to the whole otherwise the machine will work inefficiently or in the worst case, break down.

Now I'm not going to have some cliched or kitsch analogy (for once) about certain roles being separate parts of the machine as I think that's been done to death but I do want to talk about the importance of the single most important aspect of any project and that is the outcome, the goal.

Now I know that projects fail for a variety of reasons which are many and varied (and well documented) but, in my opinion, one of the most important and avoidable reasons is making sure that everyone involved in the project from the executive sponsor, right down to the developer realise that they are part of the whole.

I'm sitting in front of my TV at home right now watching a military documentary and they currently have a number of soldiers marching in ranks, each soldier is marching in-step with his colleagues, everyone going at the same speed, in the same direction and all heading to the same place. I thought about some of the projects I've worked on in my career and as I expand the the thought I imagined what some of them would have looked like in this setting. Try and picture it yourselves,

• A bunch of soldiers running off in front of the group, 
• A few individuals meandering off in a completely different direction
• Some people standing still looking bemused and finally my favourite
• The group of individuals trying to rein in the group all shouting conflicting instructions

A project team can only operate successfully  if everyone is working for each other, all going in the same direction, all making sure that everyone understands where they are going, what their role is. It's not a complicated or impossible task but it is surely one of the most important things you need to get right from the start and something that can be easily overlooked as the project picks up pace.

This concept also scales out from the team and can be applied to programs and even large enterprises. It's certainly something to consider when you are looking at starting a project and thinking you can save time by cutting short the kick off and planning stages.

You Can Lead a Horse to Water but it takes a Good Change Management Process to Make it Drink

Looking around the room where I am writing this gave me the perfect inspiration for the beginning of a Blog I've been wanting to write for a while but never had a way to structure it in own irreverent style. 

I'm currently neck deep in reviewing, amending and updating documents: statements of work, proposals, designs etc... (It's a busy day) and to do this I print them all out and go through them with a pencil and make my changes on this treeware I have created. I have M*******t Word, I have the ability to turn on track changes and that would be a much greener and efficient way of doing the task I am embroiled in, but for some reason this is the way I do it and it would take a metaphorical team of horses to make me change my behaviour. I'm the proverbial tradesman with a bag of tools but I will use the hammer in all circumstances.

Now this is a small trivial example but to those of you have released new systems into businesses you'll see how this problem, and others like it, scale out to be much a much bigger issue for enterprises. 

In my Salesforce.com and Cloud career I have spent most of my time scoping, designing and creating systems that encourage a collaborative and joined up way of working for businesses, the 360 degree view that Salesforce claim is not just a clever marketing message, it's an achievable target that you can hit with the right planning and vision, but building and deploying the system is only half the battle.

Now to go back to my original point, everyone has their own ways, their own little systems and processes that they go through in their day to day job and if you manage a team, trust me when I say the next line. 

You don't know how your team are doing what they are doing day to day!

I'll ask you a simple question to quantify that statement, how many of you reading this get critical information that they need to run their business from a spreadsheet that "someone threw together a while ago" as a temporary workaround? How many of you know where the data comes from that goes into that spreadsheet?

Now for the sake of variety I am actually going to loop my blog round to my original point in the beginning and actually finish on the topic I started with ;)

Imagine the scene, you've just paid out for Salesforce.com licenses, your implementation partner has come in and configured, customised and set up your org so that its now doing what you need it to do and three weeks after the launch you still receive the spreadsheet on Monday Morning with the sales figures for the previous week, what went wrong?

Change Management is a vital piece of the puzzle when implementing new technology, an old axiom springs to mind when I write this "You can lead a horse to water, but you can't make it drink". While this is true I'm hoping my audience doesn't consist of horse trainers or my next statement won't make much sense. You are not working with horses! You are working with intelligent people who want to do their job well. You are however trying to change their world and this is where we go back to my metaphorical team of horses being needed to make people change. But it doesn't have to be that way! change Management is not a hammer, it's not a stick you use to beat people into compliance, it's collaborative, it's informative, it's a way of educating people to see the benefits of doing things the "new way" . It's a vital component of any project where people are being asked to modify the way they work.

I'd like to finish this with a final analogy (last one I promise) and  a question that I hope will emphasise the importance of change management. A person who has been digging ditches for 3 years with a spade is suddenly presented on Friday afternoon with a JCB digger, no warning, no training, no consultation. Ask yourself this question, what do you think you'll find them doing on Monday morning?

Integration, the old enemy

Blogs are very much like buses, you spend ages waiting for the topic worthy of sharing your perspective on and then you get a couple in a short period of time. Today's topic I wanted to discuss was the wide ranging topic of integration with a particular slant towards the Cloud.

Lots of people will be willing to wax lyrical on this topic for seemly hours on end but there is no need for this to be a scary or daunting thing for people to take on. There are a lot of complex issues wrapped up in the subject matter but like all problems, once you know what you want to do, it can be broken down into a series of smaller activities which are fundamentally much more straight-forward and at the risk of jinxing myself, actually quite simple.

If you take the simple and a-typical integration cloud scenario of linking Salesforce.com to an SAP system you first need to make your decision as to what integration is necessary:

1. Does the integration need to be two way?
2. Do you need a special integration platform such as Informatica, an ESB, MQ Broker, etc...
3. Do you need "real-time" integration, interval (delta every x minutes) based integration or regularly scheduled batch integration.
4. Technology, Web Services(Synchronous or Asynchronous, RESTful APIs, Flat File, RMI, etc...)
5. What messages / data / objects will be passed between the systems

So to go through this (admittedly oversimplified) checklist we can answer the above scenario:

1. For the purposes of this scenario I'll say the integration needs to be two way, e.g. the product catalog and price list needs to be taken from SAP and the orders need to be sent to SAP for fulfillment
2. The business has indicated that in future, additional systems such as a finance system will need to be integrated into the solution so we'll say yes, an integration layer will be a much more future proof solution. (I personally would always recommend an integration layer in most cases)
3. The timings are interesting as the product catalog and pricing can be loaded into Salesforce on a batch process, the reason being that this information would not typically be changed ad-hoc and therefore would not be changed regularly. Salesforce will need to send the orders through "real-time" so this integration will be different
4. Again, the implementation strategy can drive this, for SAP to SFDC we can use Flat Files or API calls to Extract, Transform and Load (ETL) the data. For SFDC to SAP (assuming we have chosen Informatica as our integration platform) we simply have a connector for SFDC and a connector for SAP and that is the way we'll integrate.
5. Now we have the answers to the first 3 questions we can now start to map this out.

As you can already see, by breaking down the problem into it's consituent parts, the problem becomes much more easy to manage. Now the devil here is in the detail of the interfaces but again this can be broken down into baby steps:

1. Who is the master of which data components
2. What are the process maps (this can be as simple as a visio flow chart showing the process)
3. What data needs to move from System A to System B
4. What interfaces will be needed to support the transfer
5. And last but certainly not least, What do we do when something goes wrong?

Again I have oversimplied this process and left out some of the steps you would take on an integration project / design but I don't want this to become a weighty read, just get across the point that Integration is not just a big bag of snakes waiting to bite you. Like most things in IT, it's a process, a series of steps and checkpoints you go through to get to the desired final state.

So next time you look at your next integration project keep in mind it's not one huge problem of nightmarish proportions, just a problem that needs breaking down and solving in a methodical, process driven approach.

Everything Is For A Reason (or you're never too old to learn something new)

Being in the role of a Sales Engineer I tend to spend most days either in a car or on a train travelling to meetings to meet new customers, catch up with existing ones and mostly support the sales guys by listening out for new requirements and thinking on the fly high level approaches to solving them. It was on the way home from such a meeting I was sat on the train typing up my notes, for once I hadn't got my headphones on to drown out the background noise, and I tuned into a very animated conversation happening between some fellow commuters.

The conversation was essentially a person trying to explain some issues they were having with a collegue at work and attempting to explain these issues to their fellow traveller. The conversation had become so animated owing to the fierce competition that had sprung up between them to dominate the discussion. Whilst the first person was trying to articulate the issues they were experiencing, the second was firing solutions into the mix faster than a machine gun and the frustration was mounting from both parties.

As luck would have it, I was able to get off the train at my stop before this exchange descended into the inevitiable argument but the exchange resonated with me as it symbolised to me a problem I myself am prone to suffer from (and those around me have experienced, sorry guys, work in progress) and that problem is to know when you need to be quiet and listen and more importantly when is the correct time to speak. I remember the owner of a previous company offering the following advice to one of my colleagues:

"You have two ears and one mouth, this is because you should spend twice as much time listening as you do talking"

Obviously this wasn't the first time I'd heard this, my parents having quoted this truism to me repeatedly as a child but it was an eye-opener to hear it in a work context for the first time. While this axiom can be taken verbatum, you must also remember that whilst you have two ears and one mouth, you also have a brain! and it's this that should be used to tell you when you should listening or talking. So remember next time you are in a meeting, in a workshop or with friends in the pub, listen to what is being said, think about what is being said and then using what you have learnt from listening and thinking, then decide whether it's time to talk or not

Is it time to move house?

Once upon a time there was a seismic event known as the dotcom boom where all business moved to the internet, ecommerce sites led the way and were the tool of the time to leverage this new powerful new sales channel. As the tools and methodologies matured the solutions became more sophisticated and allowed ever more data to be captured about the customers of these businesses and what products or services they were purchasing right down to their birthdays. For a time, this was then simple, normal, the standard approach. The customer used the internet, came into a high street store or gave them a call on the phone. The systems were integrated to allow the same customer information to be available to telephone operators (Sales, Customer Service etc...), store clerks and the online decision making systems that would offer contextual offers or dynamic discounts based on the customer currently undertaking that journey.

For a while this worked well, Marketing teams got better at analysing the data and segmenting it into manageable information that was actionable. User experiences became more tailored and customised, offers and advertising were more targeted to the user and began to get a better return as the offers were of interest to the users and slowly but surely the picture became as complete as possible for these businesses operating in the internet space. Customer service was considered value add, yes you may lose a single customer if you didn't get it right, but it wasn't like word of mouth extended more than a handful of people.

...Fast Forward 15 years and we are right in the middle of the advent of the social media eruption...

Suddenly Twitter, Facebook, LinkedIn and other tools allowed individual people more power than they have ever had before. The social media space suddenly gives the individual a voice that everyone can hear and is fundamentally changing the face of Customer Service and Brand Management. It blows open old ways of doing business via the internet and highlights massive gaps in the understanding businesses have of their customers. A great example of this was highlighted to me the other day by a colleague working with a massive global Enterprise customer.

One of the tranches of business this customer provides is printers and printing supplies to both businesses and individuals and traditionally their customer service operations were geared towards providing a better level of service to business customers as they traditionally did the large, considered purchases and the business was keen to provide them with exceptional post-sales service. Social Media has seismically rearranged the landscape here! Ever since a part time nanny called Molly Katchpole, businesses can no longer afford to ignore the individual as they now have the power to do massive damage to brands and share prices. Customers now expect the highest level of customer services from their product and service providers.

Now how can businesses do this? How can you now get to know a customer who has access to multiple channels of communication? An individual who can speak to the masses every bit as effectively as your marketing department, and how can you learn all you need to know about this customer to give them the service they require?

Yes, there are tools out there to help you do this. Radian 6, Salesforce, Buddy Media, BlueConic and Eloqua being the first few that sprint to mind but the most key word there is that they are tools!!! I myself am not particularly gifted in the realms of DIY although I have every manner of tool conceivable, I have Hammers, Pliers, Drills, Spanners, tools for tiling, tools for plastering, tools for woodwork, tools for plumbing, tools for brickwork and masonry and a whole separate toolbox for stuff I'm not quite sure what they are for but they look as if they have been used at some point in their life. My point to this reference is that I wouldn't decide one day to build a house based on the fact I have the correct tools for the job. I admit I can Google and watch YouTube videos to tell me how to lay foundations, lay bricks, insulate walls, put in a central heating system but the simple fact of the matter is I would be very quickly swamped with data that I cannot make any sense of and certainly couldn't be able to action as I'd find myself plastering walls before putting in the electrics. The resultant mess would be catastrophic.

To expand my analogy, to get to know your customer in an ever changing environment you need to think how your house needs to be built, who will be living there(Individuals, personas and customer demographics), what sort of style they like (What products or services interest them), what rooms will be necessary (Marketing Segmentations). Only then once you have thought about this you can begin the journey to truly knowing your customer, knowing what makes them tick, knowing what they buy, how they behave, who they interact with, what they are saying about you. The old dotcom houses were great at their time, they were the right size, the walls were all magnolia and the one size fits all approach seemed to be more widespread than you would imagine but these houses are getting old, they are no longer big enough, they no longer do the jobs we need them to do. In short, new houses are needed for modern times.

With the ever increasing amount of data being gathered about customers from Tweets, posts, blogs, cookies, online purchases etc. it would be very easy to take all this and try and pack it on, build an extension if you will pardon one more stretching of the analogy but we the advent of Social Media, I believe it's time to think about moving!

Working with Content in Apex

So, it's been a long while since I last posted here an this one is going to be a short one for the techies amongst us. I recently had some work to do around Content and using a trigger to take the latest version of a template and create a copy linked to a custom object and also share it in a different workspace as a specific piece of documentation. Now, if you haev been around Salesforce long enough, you'll know that when Content first came out it was completely untouchable with Apex and today, I am happy to say, this has now changed. Onto the solution... I first created a custom setting which would hold the Ids of the Workspace(s) I would be using (to get around the hard coding issue and depolyment from sandbox to production) and wrote some very simple code to retreive this:

 public static CPM_Documentation_Settings__c getWorkspaceIds() {
     // Retrieve the custom setting and get the Id of the workspace
     CPM_Documentation_Settings__c documentSettings = [SELECT Document_Template_Workspace_Id__c, Document_Workspace_Id__c FROM CPM_Documentation_Settings__c][0];
     return documentSettings;
     
    }

Whilst not very robust or defensive it met the immediate need to get the Ids back that I needed. The next job was the meat of the issue, how to pick up the latest version of any templates and create new versions in the documentation workspace and link them to the custom object. The First thing I needed to do was get all the latest versions of the templates:

    // Get the Workspace
        CPM_Documentation_Settings__c settings = ProjectTriggerUtilities.getWorkspaceIds();
        
     ContentWorkspace templatesWorkspace = [SELECT Id FROM ContentWorkspace WHERE Id = :settings.Document_Template_Workspace_Id__c];
     ContentWorkspace projectWorkspace = [SELECT Id FROM ContentWorkspace WHERE Id = :settings.Document_Workspace_Id__c];
        
        // Get the list of document templates and their current published version Ids
        List templates = [SELECT ContentDocumentId FROM ContentWorkspaceDoc WHERE ContentWorkspaceId = :templatesWorkspace.Id];
        List templateIds = new List();
        for (ContentWorkspaceDoc doc : templates) {
         templateIds.add(doc.ContentDocumentId);
        }
        List contentDocuments = [SELECT LatestPublishedVersionId FROM ContentDocument WHERE Id in :templateIds];
        
        List latestVersionTemplateIds = new List();
        for (ContentDocument cs : contentDocuments) {
         latestVersionTemplateIds.add(cs.LatestPublishedVersionId);
        }

Now that I had a collection of all the latest versions of templates I simply needed to create the new versions linked to the custom object:

//loop through all the templates and pull back the latest published version of each of them
        List latestVersionOfTemplate = [SELECT c.VersionData, c.Title, c.Supplier_Brand__c, c.Relevant_Sector__c, c.Reference__c, c.PublishStatus, c.Printed_Version_Available__c, 
                                                               c.Printed_Format__c, c.PositiveRatingCount, c.PathOnClient, c.Origin, c.NegativeRatingCount, c.Industry_Sector__c, c.Id, c.FirstPublishLocationId, 
                                                               c.FileType, c.FeaturedContentDate, c.FeaturedContentBoost, c.Description, c.Customer_Facing__c, c.ContentDocumentId, c.Classification__c, 
                                                               c.Brand_Relevance__c 
                    FROM ContentVersion c
                    WHERE ID in :latestVersionTemplateIds];
        for (Project__c p : projects) {                    
         //create the new documents from the templates
         List newProjectDocuments = latestVersionOfTemplate.deepClone();
         for (ContentVersion cv : newProjectDocuments) {
          cv.FirstPublishLocationId = settings.Document_Workspace_Id__c;
          cv.project__c = p.Id;
          cv.ContentDocumentId = null;
          cv.Title = p.Project_Name__c + '_' + cv.Title;
          cv.Description = '';
         }
         insert newProjectDocuments;
        }

And there you have it, we now have the ability to create new content based on existing templates that exist in SFDC content. There is still some fun to be had unit testing and there are still some gotchas in there they are easy to workthough. If you have any questions please let me know by commenting and I'll do my best to steer you in the right direction.

Why get SFDC certified

As I sat down to take my Sales Cloud Certified Consultant exam, I adjusted my web cam for the 14th time and tried to relax and remember every single aspect of the Salesforce.com Sales Cloud and Sales Automation proposition.

I tried to recall Wealth Management, Person Accounts, Lead Management, Roles, Profiles, Territories, Account Hierarchies, Sales Teams, Account Teams, Queues, Sharing groups, queues, Sales Processes, Pipelines, Forecasting, Custom Forcasting, Products, Assets, Opportunity Products, Product Schedules, Validation Rules, Formula Fields, Workflows... The list just seemed to spiral out of control and after a short panic followed by a deep breath, I hit the start button and commenced.

A short while after I had finished I decided to think why, oh why had I just put myself through the tortuous Salesforce.com certification process again! I takes up immeasurable amounts of your own time to revise the subject matter, clogs up my Kindle as I download the entrire help PDF onto it for some 'light' bedroom reading and causes me to say apparently strange things to my wife who, until recently, had no idea you couldn't enable Territory Management unless you had also enabled customised Forecasting.

Then, in a moment of clarity I knew why we do it!

Salesforce is quite frankly one of the most powerful and dynamic applications in the world today It has so many strings to it's bow that it is quite frankly difficult to keep on top of them, even if you are a specialist in the technology. Bearing this in mind, it's important to remember that customers will generally tend to buy Salesforce.com as a CRM application, let's face it, with a simple enough sales process you can have SFDC up and running for Sales Automation in a matter of hours and fully configured with reports, security and all the bells and whistles in about 10 days. Where it gets tricky however, is when the customer wants to leverage the potential of the SaleForce.com platform.

I have often thought one of the major strengths of SaleForce.com is often used by people to turn it into a weakness of the plaform. I'm sure you have heard Salesforce.com employees, partners and consultants religeously chanting the following mantras:

'80 / 20 rule

'CLICKS NOT CODE'

and as cliche as it may sound this is more than a mantra, it's actually best practice and combined it gives you the split of how the majority of successful implementations should be done '80% clicks to 20% code'. This however sometimes isn't followed! People starting out on Salesforce are oftern ex-Java or .Net developers and are very comfortable in an IDE such as Eclipse or Visual Studio. They don't like the standard Salesforce layouts, find configuration boring and unchallenging and are keep to jump into writing triggers, classes, components and VisualForce pages. They ignore the rich functionality of Workflows, Formula Fields and Roll-up summary fields. They have no inclination to learn about Divisions, Territories, Wealth Management, Person Accounts (I won't go through the list again :) ). They write hundreds and thousands of lines of code, massively increase the complexity of the implementation and more critically, irreperably impair the flexibilty and dynanism of the platform.

At this point I will now return to the original question posed at the beginning of this blog, I must assure you I haven't actually digressed as far as you would think.

In order for a Salesforce Consultant to be able to deliver the best possible solution for the customer, they must first know platform to an obsessive level. They need to know the latest features in the new release. They need to know what can be done with Workflows, what can be done with formula fields. New skills have to be used to get the best from the framework and this is where the certification comes into it's own.

Customers don't want to know all of this, they have day jobs, they are worried about the day-to-day running of the business and don't want to become Salesforce consultants. They need to know that they are getting real platform experts, people who actually have recognised and standardised qualifications in the subject matter. Now, to put a slight mocker on this, having a certification does not necessarily make you a good consultant and on the converse side not having certifications doesn't make you a bad one either but, having those certifications proves to the customer (and a prospective employer) that you at least know enough about the platform to pass those exams. You have proven that you know how what features are available, what can be done with configuration alone, how you can combine features to build solutions, when you have reached the limits of the platform and need to start thinking about development. At the end of the day it's an insurance policy for Salesforce.com owners and stakeholders that you are getting someone who actually knows the platform to a good enough degree to deliver a maintainable, scalable and flexible solution that meets your requirements without costing the Earth.

The Speed of the Cloud

It's been a while since my last blog as I as I have been busy working my two jobs as first a daddy and husband and secondly as a TA at Astadia. So apologies for the delay and here goes. When I started out as a young, wet behind the ears graduate as a developer many years ago, before Agile, before SaaS, before the cloud it was a well known cry of business all over the world that IT could not react quickly enough to service the business. Typically any new IT solution was completely handicapped from the start. Using the immensely popular methodology of the time, the project would started using the waterfall approach. Several weeks upfront on analysis and design, followed by another few weeks getting the design signed off and then over to the developers. Following any number of months, the design would be subject to significant and expensive changes as the business needed to react to new processes, new legislation, new products / service etc... This made IT projects a massive headache, it was a real challenge to deliver solutions on-time that:

1. Met the original design + and any accepted change requests
2. Was within the budget
3. Was devlivered on time
4. Was actually what the business needed

1 & 4 could not be relied upon to be the same thing! No matter how hard you tried, the design was always a point-in-time reference to the business requirements at the time of the projects beginning! No matter how good the change management process was, talk of phase 2 or release 2 always started to creep into conversations as the changes became more and more complex. Here we are now however in 2012 and now I believe the tides have changed, the roles have reversed, the shoe is on the other foot :) In the past year I have started to hear an almost totally unheard situation. The business are not able to adapt to the rate of change from IT! In my current project where myself and another TA from Astadia (Twitter @stuagare and blogger ) have been developing enterprice solutions for a Sales and Financial applications on the SalesForce.com for a telco client with a multi-continentental presence. We, along with the assistance of development teams from many different shores and timezones have worked with the business to capture their reqirements and build them a solution to allow them to massively update and automate complex sales processes. These complex and powerful solutions have been designed, developed and deployed in such a short timescale that the business are having real problems reacting to the speed of IT. The main reasons of this have been

• An Agile based project methodology tailored specifically by Astadia
• The SalesForce.com and Force.com platforms
• Business stakeholders, decision-makers and subject matter experts being heavily involved throughout the entire project.

So with fresh-faced enthusiasm and overwhelming optimism I am now looking forward to a change in my career. I predict that 2012 will be the year where the old problems and headaches will become a distant memory,

• project timescales will reduce significantly as more and more companies leverage the power of Cloud and SaaS solutions.
• 1 Year+ projects will be consigned to be the exception rather than the rule
• Project change requests will significantly reduce, this will have the knock-on effect of lowering risk to timescales and budgets
• Delivered solutions will be more complete, more in-line with what the business need today, rather than 6 months ago when the requirements were captured

The new problems will be lesser in comparison, the softer skills of the consultant will come to the fore, adoption assistance, training and user support. 2012 in the cloud will see ever closer alignment of business and IT and SalesForce.com and the Force.com platform will be a massive part of this.

VF Woes

Very quick blog this week and it's around an issue I had allocating dynamic Ids to Apex Input fields.

I had a recent requirement that needed me to change the values in some input fields in a targetted way on a VF page. My first thought was to assign a dynamic ID to the <apex:inputfield> only to find that you need concrete values in here.

Found a clever way round this that allows you to find fields by their <apex:inputfield styleclass="{!variable}"

As the JavaScript function getByElementClass is not support in all browsers I needed to write something quick and functional (read dirty) that did the job without using any external libraries or Frameworks i.e. jQuery Here is a very simple JS function that will retrieve all the elements of a certain classname to allow you to 'do stuff' to them.

function getElementByClassName(cl) {
    var elements = [];
    var elem = document.getElementsByTagName('input');
    for (var i = 0; i < elem.length; i++) {
        if (elem[i].className.indexOf(cl)!=-1) elements.push(elem[i]); 
    }
    return elements;
}; 

Not rocket science but you can extend it to use regular expressions etc... and all you need to do it pass it the classname you are looking for. Won't solve a lot of problems but it definitely solved one for me today :)

What did that chap just say?

Business and IT, two bodies working for the same company on the same project separated by a common language. How many times in your working life have you as a business user come out of a meeting or workshop and thought,

"What on Earth were those techy guys going on about? A workflow with a field update and an outbound call to a web service to integrate with the outlying systems via the middleware tier, I have no idea what that means"

You are not alone in this, many's the time I have left a workshop and had a developer ask what the business users meant by:

"We need a solution which will enable our back office staff to get all the information necessary for fulfilment without having to go back to the front office B2B reps to get extra detail."

Neither of these statements are complicated per se but, one of my jobs as a consultant is to make sure that when communications happen between technical resources and business users that they communicate in a common language and my role is interpreter.

Luckily this is not a difficult problem to overcome. All you need to do is invest a little time in the technical team prepping them. Here is a short list of what I like to do to better faciliate the conversation

1. Get a list of all the issues that the technical team need to discuss up front, find out what the developer needs to know to complete the work. This way, you will be having the conversation.
2. Coach/Mentor your technical team. Have a pre-meet with the team to make sure there are some simple ground rules laid down:
1. Under no circumstances should the developer talk about code or offer to show it
2. Business users do not want to hear about the details, Workflows, Classes, Triggers, Unit tests. None of these should be mentioned
3. Where appropriate, try and ask the question to your own consultants. It’s their job is to translate between Business and IT

Communications between Business and IT need not be a stressful ordeal. With a little preparation then it can become a productive and stress-free experience.

The Lazy Unit Tester

My take on unit tests? Essential!

Never mind that SalesForce.com forces 75% code coverage on any code written. Even if this mechanism wasn't there, I would still insist on them being present on any solution implemented by myself or my team.

A unit test is, at its most basic level, code that tests code! It's not a replacement for smoke, functional or system testing; it's a mechanism which helps improve the quality of code written by developers.

If you’re building a car, it’s the sum of all its parts. The parts are manufactured individually, then put together and at the end of it you have a working car! Quite a simple process, like a jigsaw puzzle, but a lot can go wrong in this process.

Let's take the wheels on the car. For the car to run you need four wheels, each with tyres. They all need to be the correct size, shape and inflated to the correct pressure to be useful. If one of those wheels is square, the wrong size or is flat then this will affect the operation of the car and make it less than desirable to drive or own.

When buying a new car, you hope the manufacturer tests the individual components (in this example the wheels), as well as the overall function of the car.

Now, onto the geekery, let's take this code example

public class Wheel {
    public static String defaultBrandName = 'Default Tyres Inc';
    public static int defaultSize = 14;
    public static double defaultPressure = 33;

    public String brandName;
    public int size;
    public double pressure;
 

    public Wheel() {
        this.brandName = defaultBrandName;
        this.size = defaultSize; 
        this.pressure = defaultPressure;
    }

    public Wheel(String brandName, int size, double pressure) {
       this.brandName = brandName;
       this.size = size;
       this.pressure = pressure; 
    } 

    // Some Accessors and Mutators for the instance variables
}

public class WheelFactory {
    public static Wheel getWheel() {
        return new Wheel();
    }

    public static Wheel getCustomWheel(String brandName, int size, double pressure) {
        return new Wheel(brandName, size, pressure);
    } 

}

It's quite clear how this now works. We go to the wheel factory and either ask for a default tyre or we specify what kind of tyre we want, as the meerkat says 'Simples'. but what would be the best way to test this to enable me to deploy it to a SDFC production org? Not much I hear you say, but here is an example of the type of thing I have seen.

@isTest
public Class WheelFactoryTest {

    public static testMethod void myUnitTest() {
        Wheel w = WheelFactory.getWheel();
        Wheel w1 = WheelFactory.getWheel('Pirelli', 20, 33);
    }
}

And there is it, as far as Force.com is concerned, a perfectly valid unit test! It makes the 75% test coverage requirement and took about 30 seconds to write. Job done! Let me ask you this though, what is my unit 'TEST' actually testing? The simple answer is that it's testing that the WheelFactory and Wheel classes compile and can be called. It's quite frankly a waste of 30 seconds and this test is useless! Is a Wheel being returned? or is it returning a null? What brand is it? What size? What pressure? We just don't know from this test! Below is what I would consider a better test of this:

@isTest
public Class WheelFactoryTest {

    public static testMethod void wheelFactoryGetWheelNoParamsTest() {
        Wheel w = WheelFactory.getWheel();
        System.assert(w != null);
        System.assert(w.getBrandName() == Wheel.defaultBrandName);
        System.assert(w.getSize() == Wheel.defaultSize);
        System.assert(w.getPressure() == Wheel.defaultPressure);
    }

    public static testMethod void wheelFactoryGetWheelWithParamsTest() {
        String brand = "My Brand";
        int size = 17;
        double pressure = 35;
        Wheel w = WheelFactory.getCustomWheel(brand, size, pressure);
        System.assert(w.getBrandName() == brand);
        System.assert(w.getSize() == size);
        System.assert(w.getPressure() == pressure);
        
}

Hopefully you can see the improvements here?

1. We are testing each method in a clearly separate way so if one method fails we know instantly which one is broken
2. We are using asserts to guarantee that we are getting the correct results! When you see a unit test with no asserts you need to change that! 95% of the time there is no excuse for a unit test with 0 assertions this is testing more than just coverage!
3. We are protected from change! Because we are using the static default variables from the WheelFactory class in our tests, if those defaults change our unit test does not need modifying, this is basic coding 101, don't use magic numbers!
4. I am actually testing that the tyres are the correct size, pressure and brand! Wouldn't you do that in real life if you were buying tyres for your own car?

Hopefully people will find this useful and when they get given a unit test to write will do the right thing and do it properly and understand the importance of a well constructed unit test!

Who Needs a new Server

My current project has me again working on my platform of choice Force.com solving business problems for a massive multi-national enterprise company. The problem the client has is that they have developed an excellent suite of 'sweet' sales tools to assist their sales people out in the field. The technologies are many and various and all have one slight weakness from a business perspective:

The Tools that they use all capture client information and details of sales orders and proposals. Again, as a toolkit given to their Sales representatives it's an excellent package, videos demonstrating their products and simple forms to allow them to capture all the information to both identify pain points for the prospective customer and also identify appropriate solutions that they can offer to solve them, this is where the problems begin for the business.

The tools all reside locally on the Sales representatives own laptop and there is currently no way for the business to extract this information and get critical data out to view in a federated way. At first impression the long rendundant IBM consultant within me started thinking of the servers that would be needed to support this, a big expensive middleware infrastructure, an appliance such as DataPower, or software (MQ, and ESB) deployed to a 6 figure cost server that would need to be housed in an even more expensive data centre. This "essential" piece of middleware would then connect to a big central database (DB2, Oracle etc...) and then we can look at deploying Business Objects or Crystal Reports to allow management to get the MIS they require out of the system. Ouch, a big expensive implementation with 5+ consultants and a lead time as much as 6 months before you even start to think about the OpEx of maintaing such a mammoth implementation!!!
Luckily for me and the customer, the year 2011 came knocking and told me that I was living in the past and that those old fashioned architectures are just expensive to deploy in a resilient fashion, unreliable unless you deploy in a resilient fashion and require specialist infrastructure and application teams just to keep the lights on so a more modern, agile and rapid solution was required.

I then lifted the lid on SalesForce after a few hours it became quite obvious that the data they were capturing was essentially Accounts, Contacts, Opportunities and some ancilliary data to support each of those objects! So we had it, a clean mapping between the core SalesForce.com CRM offering and the toolkits developed, now all we needed was a mechanism to get the data from the remote silos into the SalesForce.com org and start reporting on it. The answer was so simple and that was to make use of the excellent WebServices API that you get from the Force.com platform. After an initial workshop, an interface with core services was defined, the applications, which already have the functionality to operate in an off-line capacity were compatible with the delivery mechanism, http/https, which was considered rightly, to be a reliable and resilient mechansim and therefore removed the need for some IBM or BEA/Oracle bloatware (middleware to the layman) and away we all went.

Now to repeat the problem, business critical data was residing in unreachable, remote silos and needed bringing together to provide senior business leaded with mission critical data and reports to allow for forecast and pipeline analysis. How long do you think it would have take? I couldn't even begin to estimate the cost, lapse time for going the 'old' way all the unknowns, server procurement, highly paid product specific consultants, licensing costs, server costs, data centre costs, security considerations, the list goes on and on and on, as does the delivery date and the zeros on the end of the purchase order the customer would need to raise. Luckily for them, the modern Cloud / SalesForce.com route was chosen, and here we are, 12 days of consultant effort later, ready to plug the solution in. The platform is in place, it's resilient and secure, it doesn't cost us to maintain and only one person was needed for all the configuration and coding of the SFDC solution.

If you are reading this, have a think about your own company! How many servers do you have? How many people do you employ exclusively to keep the lights on? How much does one server cost you as a company? How much does it cost doing failover and DR simulations?

Just keep in mind that SalesForce frees you from:

1. Data Centre Considerations
1. Rack Space
2. Power Consumption
3. Air Conditioning
4. Networks
5. Firewalls
6. Bandwidth
2. Server Considerations
1. Security Patches
2. OS upgrades
3. Hardware Considerations
1. Maintenance Contracts
2. Component failure
3. Redundant infrastructure (Warm, Hot, Cold Stand-bys)
4. Skills Considerations
1. System Administrators
2. Networks and Firewalls teams
3. Security specialists

All of this is included in your SaaS licensing model, one user, one license and all of the above comes for free!

With this in mind, when you consider your next implementation, think about the costs, the lead times, the procurement processes, the on-going maintenance cost, the legion of expensive consultants you will need and then think again, why should I do/pay for all of this when the "True Cloud" frees your hands and give you all of this in the price?

Consultancy and the Word "No"

I was enjoying the company of an ex-colleague, rail travel critic and long time friend Ben Baumguertel this morning on the 06:14 train into London this morning and the conversation roamed onto a topic that provoked strong professional reactions for both of us. Whilst discussing passed projects and clients we stumbled onto the topic of what actually makes a 'good' consultant as opposed to a green-horn consultant on their first client engagement and began telling each other of some parallels we had each encountered in our careers.  

The life of a consultant is often stressful, bouncing from industry to industry, each time being required to learn the political landscape, the stakeholders, the processes and procedures, governance, regulatory requirements, the list goes on and on. In each case however, one core principle seemed to be the same, in all client engagements, all industries, all projects, one simple core principle seems to be present. The ability to say 'No' in a constructive fashion.

We've all been there, you are sitting in a workshop, you've gauged the lay of the land and you are listening intently to both hear about the project as a whole and the particular component(s) you are responsible for when the dreaded line comes from nowhere "What we need to do is X". This instantly puts you in a bind, you need to be able to understand what has been said, think your way through X and apply as may use cases as the workshop has uncovered and also apply the benefit of experience to consider your response. Often you may have the luxury of stating something non-committal such as "let's take that off-line" or "I don't think we know enough to make that decision now" but, more often than not, the response in your head is like something off of lost in space "Danger Will Robinson, Danger".

It's at this point that the subtle skill of consultancy comes to the fore, the art of taking your time, I have learnt the hard way that shooting from the hip is a terrible idea in these situations. The idea has been made for valid reasons by a member of the team you will be working with for the foreseeable future, you simply cannot afford to sit there and simply state "No, that is not a good idea". It creates a perception of yourself as negative and blocking, you run the risk of alienating the team member who made the proposal and you are there to be constructive and helpful. You may be 100% right but the delivery is everything in situations like this.

I'm not going to be prescriptive in this as I don't actually know the answer and anyone that claims so it stretching the truth somewhat but what works for me is to share my relevant thought on the matter. Phases such as
"Will that work for all the use cases we have uncovered today?"
"I think that suggestion has merit but we need to fully explore that before we go too far down the path"
"That works for what we have but what happens when A, B or C occur? Will it handle them?"

Most of the time, my role has not been to dictate an entire solution to the customer but to work collaboratively with Business and IT to produce a solution that benefits all. Don't get me wrong, as the external consultant it's my job to spot things which will cause problems down the line and to provide the benefits of my experience to the project team as a whole and to make sure that the project will be a success but, in order to do this, you must learn the right way to say that simple two letter word that you've known from infancy

"No"

I Could Murder a Cuppa

During our annual meeting, we were set a relatively simple challenge, we divided into equal teams, and we were all set a simple process to document and present to the group. This sounded quite simple but it was very interesting to see different peoples' takes on the requirement.

Here is the exercise I'll be covering in this Blog. Making a cup of Tea:

1. Fetch the kettle
2. Open the lid on the kettle
3. Turn on the cold tap
4. Fill up the kettle to the max line
5. Turn off the cold tap
6. Put the lid back on the kettle
7. Put the kettle back on it's base
8. Plug the kettle in to the electrical socket
9. Turn the kettle on at the electrical socket
10. Switch the kettle on
11. Open the cupboard door
12. Get a mug
13. Put the mug on the worktop
14. Go back to the cupboard and get a tea bag
15. Put the tea bag in the mug
16. Wait for the kettle to finish boiling
17. Pick up the kettle
18. Pour water into the mug to the desired level
19. Leave for 3 minutes
20. Go to the drawer and get a spoon
21. Stir the tea and remove the teabag
22. Open the bin
23. Put the used teabag in the bin
24. Close the bin
25. Put the spoon down next to the mug
26. Go to the fridge and open it
27. Get the milk out
28. Open the milk
29. Add some milk to the mug with tea in it
30. Close the milk
31. Put the milk back in the fridge
32. Close the fridge
33. Pick up the spoon from next to the mug
34. Use the spoon to stir the tea
35. Drink

Now this simple 35 point process all comes from the simple requirement, make a cup of tea!

Now this is quitovee straightforward, any first year university student could have a reasonable stab at this with a high success rate but let's take it a step further. Let's say that you were meeting a customer for a discovery workshop and they passed you a requirement to make a cup of tea. You decompose it down into a series of managable tasks and race to the implementing of it but I've made a common and fatal mistake in the process list above. It's blindling obvious but has caused no end of problems in projects since the dawn of IT. I've potentially made some fatal assumptions: Do we have a kettle? Do we have Teabags? Does the customer want their tea without Sugar? The list goes on and on...

The point of this is that don't be in a rush to implement, think about the requirements,

• List all your assumptions, get them verified by the customer. 
• Think about your happy path and get this in place first
• Think about all your exception flows and hang them off the happy path flow
• Thnk about how you are going to test it?
• What are the pre-conditions?
• What are the post-conditions?

This is just as valid in Agile as it ever was with Waterfall approaches, admittedly in Agile you may proceed without knowing the full requirement but you should still attempt to flag the unknowns to be bottomed out later. Making sure that your requirements are fully thought out is the only sure fire way I've seen to prevent the 'ball of mud' coding pattern from becoming the predominent pattern on an implementation. An hour spent upfront clearing up your requirement and thinking your way through a problem will invariably prevent a throwing code at problems to make them go away.

This may be a very simplistic way of demostrating my point but it's a simple thing that if done incorrectly can have serious consequences? We could potentially have gotten to step 27 before we realised that we hadn't actually got any milk!



Finally, I suppose I should give the answer to my previous blog, this is quite simple once you start to dry run the principles in your head and you have ever got a divide by zero exception :). The answer is simply that the equations don't work as if X == Y then X-Y will always equal 0... Therefore, to divide by X - Y is to divide by 0 which cannot be done

Spotting a True Developer

I was thumbing through some old Maths homework set for me in my university days and I came across a practical joke that a lecturer set us that I think would be a marvellous addition to any technical interview when assessing would be developers.

The principle stems from a Mathematical fallacy which can be proven to the naked eye but, when you start to dig into it a developer should easily spot the anomoly as it can only be disproved by 'dry running' the concept in your head. Remember dry running you old school guys? A skill that has sadly seemed to have diminished as debuggers have gotten better and better. The good news is with SalesForce.com and it's Apex programming language the debugger is pretty basic and I personally am starting to see a slow resurgence of this lost, essential art!

On to the meat of this:

If we start with a basic principle X = Y it is safe to assume we can expand this as long as whatever we do to one side of the equation we do to the other side to keep it balanced so here we go.

1. Multiply both sides by X

    X^2 =X^2

2. Subtract Y^2

X^2- Y^2 = XY - Y^2

3. Now let's factor both sides and break it down into an easier to read format

(X - Y) (X + Y) = Y (X - Y)

4. Now we can divide both sides by X - Y to clean it up a bit

X + Y = Y

5. Now if we revisit our original principle that X = Y we can now express this as

Y + Y = Y or 2Y = Y

6. Now we simply divide by Y

2 = 1

And there you have it, we have now proven that 2 = 1 but can you spot the problem with this. I maintain my assertion that a true developer capable of dry running this will spot it in a few moments.


This is a common Maths 'joke' so have a go at it first before googling for the answer and I'll release the answer in my next blog but you shouldn't really need it as long as you maintain the basic principle X = Y

Until next time,

Chris