Monthly Archives: May 2016

Step into the emptiness

I noticed a strange thing about those stairs in my house. It’s a split house, so, every night, I would turn off the lights in the living room and go upstairs.. And what I hate about it is that almost every single time I would keep going up when there are no stairs anymore. Did it ever happen to you? Do you know that wonderful feeling when it hits you that you are trying to climb into the emptiness? And then, of course, you just hit the floor with all your weight producing a nice “boom” sound which resonates through the house.

I’m just wondering, though, if that tricky behavior those stairs in my house are exibiting is, really, natural for just any stairs. Like career stairs, for example. Apparently, if you try to climb the same stairs you used to be climbing to get higher than they lead to, you are bound to experience that “step into the emptiness”. Hm..

Disaster Recovery in Dynamics CRM online

Salesforce outage that happened this month has rightfully provoked all sorts of discussions about the dangers of cloud offerings. Most of those discussions are only theoretically interesting, since they are, for the most part, speculations on various aspects of what needs to be done to avoid this kind of situations, what the customers can do, what the service providers can do, why A is better than B and so on.

In my mind, what happened to SalesForce manifests a problem that can happen to other cloud services any time. It is a given, it is not something to discuss, it is just in the nature of this technology that it may fail. And it will, sooner or later, which was so effeciently demonstrated by SalesForce. So the question is not whether it`s going to fail and when, the question is what happens if it does and how that affects us, the customers.

And the only way we can somewhat appreciate those effects is by looking into the disaster recovery plans which are implemented by the service providers. So would not it be interesting to review what Microsoft is offering in that respect for Dynamics CRM?

Basically, there are two distinct aspects we could be looking at in that respect:

1. Compensation

This is all about Service Level Agreements. Which are also called uptime guarantees. I don`t like the term since it is really not a guarantee – it is more a promise of service fee compensation. That, of course, is better than nothing, but there is something inherently wrong with this whole idea. You either have to trust the service or not. And, if you do, the service you purchased can become a very core part of your business processes. Once and if it happens, that kind of service fee compensation stops meaning anything since you will be expeiencing a business disruption whenever the service goes down, and that will be costing you much more than the service fee itself.

With that said, Dynamics CRM Online is offering the following SLA-s and service credits:

https://port.crm.dynamics.com/portal/static/1033/sla.htm

Less than 99.9% uptime – Microsoft will issue a 25% service credit.
Less than 99% uptime – Microsoft will issue a 50% service credit.
Less than 95% uptime – Microsoft will issues a 100% service credit.

Just to put this in perspective, though, 95% uptime means that you need to experience at least 1.5 days outage per month before you get to the point where 100% of the service fees are compensated.

2. Disaster Recovery Plans

Once we know the compensation structure, which, again, might not be that important, what we might really be interested in is to know what happens to the service when the disaster hits. Surprisingly, this is a somewhat grey area when it comes to Dynamics CRM online since Dynamics CRM is making no specific promises in that respect.

There are some parameters which would be normally looked at in the disaster recovery scenarios. For example, we might be looking at the RTO(recovery time objective, or how long it is going to the service provide to recover data) and RPO (recovery point objective – more or less about how much of your data will be lost).

Whether I was looking in the wrong places, or whether it is just what it is, but I was not able to find any details on that.

There is limited amount of material on Microsoft web site which is indirectly referring to what may happen, though:

https://msdn.microsoft.com/en-us/library/hh771583.aspx

This is where possible data loss and outages are mentioned.

http://download.microsoft.com/documents/customerevidence/Files/710000000389/CRM_Online_SQLServer2012_Final.docx

This is where Microsoft speaks to the benefits of using SQL Always On feature withoug commiting to any numbers, though (besides, again, providing a reference to the SLA-s mentioned above).

What`s the conclusion, then? It is simple – disaster recovery plans for Dynamics CRM should be explained in much greater details. Otherwise, I would love to say that Dynamics CRM Online customers are protected better than SalesForce customers, but, right now, this is not something we can easily prove.

Why best practices in IT are not necessarily what we think they are

Lately, I have been observing how a commonly accepted approach to the business analysis collided with a little bit unorthodox business analysis methodology, so that made me thinking of what really makes a best practice..

Many of us start in the information technology industry through some sort of “science” education. For me, it was applied mathematics. For many, it was computer science. For some, it might be engineering or other technical education. Either way, it seems that, in order to work in the IT, one has to possess some of the personal traits which are usually associated with the logical reasoning.

However, a lot of IT is, actually, illogical. It is illogical in the sense that, quite often, it is impossible to trace the whole sequence of decisions which lead to a particular outcome.

It is easy in mathematics, for example. You start with something established, you transform that knowledge using well-known logical rules, and you get a result that anyone else can validate just by applying the same rules to the original statement.

Computer science follows a similar approach. For example, you can take an algorithm, you can calculate the complexity, and you can say upfront which algorithm would work better in a particular situation.

Information technology, on the other hand, is not just about science. Come to think of it, how often do I really have to recall the idea of algorithm complexity in my daily consulting/development work? If it happens once a year, that’s already good enough. Instead, a lot of what we, information technology people, are doing is mostly based on the so-called best practices. But best practices, by definition, are based on something that cannot be easily validated. What is a best practice? It is, basically, an agreed upon description of the best approach to the process implementation.

Are best practices following the same logical reasoning patterns as science, though? The answer is yes and no. Once you have established that there are specific best practices, you can mix and match them to create other practices. That process would likely follow common logical rules. However, you have to establish those basic best practices first, and that’s exactly the area where information technology has become somewhat sloppy having assumed that best practices are universal.

As a result, we have started accumulating immense amount of knowledge in various areas, all combined under the umbrella of best practices: we have business analysis body of knowledge (BABOK), we have project management body of knowledge (PMBOK), we have various methodologies such as TOGAF, Prince2, Six Sigma, SureStep.. and this list can go on for quite some time. Yet it is almost impossible to question any of that knowledge because, essentially, there is nothing specific to question. Or, more exactly, we can question anything there, but how do we validate the answers?

Problem is, to say that something is a “best practice”, we need to be able to compare that practice with other practices, but we can only judge a practice based on the outcomes of implementing that practice. Let’s compare this information technology scenario to Formula 1 racing, though. If Michael Schumacher was able to tell you, in great details, what he used to do to win those races, would it turn you into an F1 champion? The answer is obvious – you might not be able to even finish one lap.. But this analogy easily demonstrates a few points:

– A lot there depends on the person who is implementing the practice

– What works for one person might not work for another

– When describing best practices, it is easy to miss on some of the critical details

In other words, as much as best practices are meant to provide guidelines, they have to be treated with some level of scepticism. That internal contradiction is, likely, the reason why we do see some adoption of the best practices, but it has not become mandatory at all. Any “best practice” should always be accompanied with a disclaimer: make sure you try it first to see if it fits you, and, then, use it at your own risk. That might put it all in the correct perspective where we would be considering best practices as tools we can use, but it would clearly be up to us to choose the tools which are fit for purpose.

UX Design Guidelines for Dynamics CRM

There is an interesting document that talks about some of the best practices for Dynamics CRM:

https://www.microsoft.com/en-us/download/details.aspx?id=48268

What’s really interesting is that it does not tell you what and how to do, but, rather, it explains what was the thinking behind Dynamics CRM design and what the expectations are. Once you know that, there is, really, only one option: you have to follow these ideas when implementing your Dynamics CRM solutions. Try anything else, and there is a good chance CRM will start working against you.

Before designing any CRM solution, think about user personas and objectives. Designing for the most specialized roles yields the best results. It’s also important to focus on actionable insights rather than just on data. To measure the success of a CRM implementation, measure outcomes and not actions. Last by not the least – use the right CRM UX components in the right place of the user flow. Following the guidelines in this document can allow for optimal user experience and successful CRM implementations.