Monthly Archives: April 2016

Electric Cars – are they worth it?

Every now and then, when our constantly-getting-older (but still not obsolete.. not even quite old yet) car needs some extra attention because of her age, we start looking around to see what could possibly replace her. This time around, there seem to be a few electric cars on the horizon which, I thought, would be worth at least some consideration. As usual, the problem is that all of them, as of now, have such a short driving range.. So, Tesla Model 3, Leaf 200, or Chevrolet Bold, which are supposed to deliver over 200 miles on one charge are, likely, the first electric cars that might be useful for something more advanced than city driving.

However, with all due respect to the technological advancements and more powerful batteries, this makes me wonder how is that range supposed to help at all. Just imagine being able to pass 100 miles and not a single mile more because you have to plan for the return trip. How long will it take to build the infrastructure required to quickly charge those vehicles? Yet, even if that happens, it will still be taking much more time to recharge the batteries compared to just a few minutes one has to spend on the gas station now to fill up.

So, what is all the hype? Seriously, I understand the desire to have a nice new technologically advanced toy, which is potentially environment friendly (potentially, since there is some evidence they might be not so good at that: However, these cars are not practical at all. Even if they get extra 100 miles per charge, how is it going to help? City drivers don’t need that much anyways. Long family trips won’t really become possible just because of the relatively short added distance. And all those limitations come with quite a bit higher price.

All this makes electric cars not an option for us, at least not at this time. But I’m still wondering WHY are there such cars at all on the streets..

Finding software design patterns in the normal world: decorator and proxy patterns

This is a continuation of the original “finding software design patterns in the normal world” challenge. For this one, let’s have a look at the proxy and decorator patterns.

The difference between those two seems to be more conceptual than structural.

For example, let’s say we have a soldier who can fire. Let’s put that soldier into a tank.. He can still fire, though he has been turned into a much more powerful weapon now. Is there still a soldier in this picture? Yes, there is. However, what really matters is that there is a tank. They are together, but, when looking at that “firing object” on the battlefield, we see a tank. One can say, our soldier has been improved, yet he was not really changed. In a somewhat weird sense, the soldier has been decorated. He is hidden from us by the tank, and, because of that tank, he is capable of delivering much more fire power than he could on his own.

Decorator pattern is all about giving other objects improved characteristics without really changing the essence of what we use those objects for.  A soldier alone can deliver that much firepower. When put into a tank, he can be turned into a much more powerful weapon.

What about the proxy, though? There is still a tank, and there is a soldier. But we move our attention away from what the soldier can do, and, instead, we now concentrate on how we access the soldier. Let’s say that tank was firing on us, so it would not be our tank, really.. so, our goal might be to somehow get through tank’s armor all the way to the soldier who is controlling the tank. That’s, though, one of the reasons  there are proxies. They can control access to those objects we really care about, and, in particular, proxies can protect those other objects.

So, proxy and decorator are two patterns with very similar implementation, though there are quite different intentions. In case with the proxy, we need to control access to the object. In case with the decorator, we need to give our object some extra/different power without actually modifying the object. There is still a tank and a soldier in both cases. It just that we are concerned about different attributes of that tank depending on whether we are using it as a proxy or as a decorator.



Proxy Pattern

Decorator Pattern

Finding software design patterns in the normal world: the singleton

I was always a little too lazy to really learn all those software design patterns, and it’s probably time to fill the gaps. However, there would be no fun in re-writing the definitions of the design patterns again and again.. I figured a little challenge might help.

How about trying to find software design patterns in the non-software world? Would it be possible?

There is a list of 23 GoF patterns here:

This time, let’s have a look at the singleton

How about this: imagine a small business with just a single employee(who is a business owner, too). That poor chap can be a cleaner, a CEO, a recruitment manager.. it depends on what he is supposed to look like at any particular moment. Still, no matter how we call him, it’s the same employee/person. That’s what a singleton is: you have something that may look as if there were many, but, in reality, it’s always the same.

PS. I’m not suggesting that you should be calling your neighbor a singleton if he/she happened to be that kind of small business owner. After all, they might not have read this blog yet..

Blogging: what’s in it for me?

What are the reasons I’m blogging? Even if it only happens occasionally? I used to blog in the past for a few years, then I sort of lost connection with that first blog.. And, eventually, I closed it. Now I’m starting to do it again, so why?

This blog is not about making money – I would not mind if it were, but it’s not the goal. Neither it is about making friends – same note here.. I would be happy to make friends through blogging, but it’s not the goal either. The real reason is that blogging, for me, is a practical tool which allows me to organize my thoughts, knowledge, and experience.

In other words, it’s all about this:

“If you want to learn something, read about it. If you want to understand something, write about it. If you want to master something, teach it.” (Yogi Bhajan)

Personally, I don’t see any reason in learning something without establishing some level of understanding. And, if you start writing about something, you are already teaching. However, that quote above, even if it sends a somewhat ambiguous message, does come very close to explaining my reasons for blogging. I want to learn, understand, and master quite a few things that I`ve been putting aside for a while either because of the lack of time or because of the lack of motivation. Blogging is, essentially, writing. I might probably do writing somewhere else(in the word document on my laptop).. However, blogging also has at least a potential for audience, so it does motivate me to organize this writing in a much better way, and that comes very close to the actual teaching.


Software Architecture: a mysterious discipline

I am surprised how software architecture discipline is suffering from the lack of self-identity, so I’m going to rant about it in this post.. just for the record, there will be no yet another definition of what software architecture is below.

Why do I think there is a problem with the software architecture discipline? Let’s consider a few simple questions:

– What do figure skaters do?
– What do software developers do?
– What do horse riders do?

Got simple answers? Now, then, consider the following question:

– What do software architects do?

Got any answer at all?

Probably the easiest way to find out what they are expected to do is to look up the description of software architecture opportunities on the internet. Here is what a Software Architect is supposed to be doing according to one such opportunity posting:

• Participate in full life-cycle development from requirements through implementation.
• Translate the business needs to the technical team and assign programming and development tasks to the technical staff.
• Develop and provide mentoring to less experienced technical staff (other architects, technical leads and developers).
• Design coding and software best practices, develop reference and proof of concept implementations.
• Design and development of reusable components and services.
• Create unit and component integration test strategies with a focus on validation of proper function and appropriate data.
• Must be comfortable with multiple areas of responsibility including but not limited to presentation, business logic, persistence, performance, scalability, and integrations.
• Expected to help specify the features of physical design, estimate time and effort to complete each feature, build or supervise implementation of features, prepare product for deployment, and provide technology subject-matter expertise to the team.
So.. An architect is supposed to be a developer.. a manager.. a business analyst.. a techinical lead.. a mentor.. be able to multitask..

Does this description mention the ability to actually “architect software” somewhere? Not even once. If you think that’s an exception, try googling similar opportunities and see for yourself.

On the other hand, here is how Wikipedia defines software architecture:

Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. These structures are needed to reason about the software system.

BTW, this definition is almost copy-pasted from the “Software Architecture in Practice” by Len Bass, which, as I understand it, is a classic textbook on the subject.

Does it mention anything about the coding skills? Does it mention anything about the integration and test strategies? Building the features?

That, I think, is where the problem is. Most if not all of the companies are not looking for Software Architects to do what, in theory, those folks are supposed to be doing: designing and documenting the system. Instead, they are looking for some sort of super-heroes who are well-versed in the software development, project delivery, mentoring, sales, and business analysis.

To me that looks like a good indication that the discipline of software architecture is not quite “practical”. It’s been in existence for over 40 years so far, and it’s still not recognized at the practical level as a dedicated and well-defined discipline. Because, otherwise, that opportunity description above would be much more concerned about what the candidates know about the software they can use to document the architecture, about the methodologies they can use for documenting, about the best practices, and about all the other particular deliverables that only a Software Architect would be expected to provide.

Who are Dynamics CRM Architects?

There are Dynamics CRM consultants- they do CRM consulting. There are Dynamics CRM developers – they do development. There are, also, Dynamics CRM Architects. What do they do?

Here is a sample description of one of the actual CRM Architect positions:

  • Deep Know-how and proven record of applying CRM in one or more industries; experience in Media and Publishing, Financial Services and Public Sector preferred
  • Proven experience in presales activities including Proof of Concepts, Demo, Presentations and positioning in front of C-Level Executives
  • Ability to envision, architect, and evangelize CRM / xRM solutions within our prospects and clients
  • Proven experience selling consulting engagements which includes estimating, scoping, and writing effective statements of work that clearly set expectations and limit risk
  • An ability to articulate architectural differences between solution methods and the challenges and approaches to integrating solutions built on different platforms including a working knowledge of different architectural frameworks that may be used by our customers
  • Ability to move between high level architectural review / design and the “roll up the sleeves” level of actually doing all phases of a CRM / xRM delivery project
  • Working knowledge of specialized tools, solutions or ISV solutions is a plus
  • Experience using Microsoft Sure Step for Project Management is preferable


So what differentiates a person who meets those requirements from a CRM consultant? Strictly speaking, it seems to be the breadth of experience rather than anything else combined with some sales and management skills.

Is it aligned with a more generic Software Architect role? Here is an example of that one:

Responsible for initial design and development of new software or extensive software revisions; products may be for use internally or for resale. Defines product requirements and creates high-level architectural specifications, ensuring feasibility, functionality, and integration with existing systems/platforms. Requires a bachelor’s degree and may be expected to have an advanced degree in area of specialty and at least 7 years of experience in the field or in a related area. Demonstrates expertise in a variety of the field’s concepts, practices, and procedures. Relies on extensive experience and judgment to plan and accomplish goals. Performs a variety of complicated tasks. May provide consultation on complex projects and is considered to be the top level contributor/specialist. May guide a team of developers through the project to completion. Typically reports to a head of a unit/department or top management.

The whole reason I started to ponder on this question is that I was not quite sure what’s that CRM Architect means. I am, now, an Architect.. officially. And, yet, I’m still doing development half of the time. So what does it make me? Where both of those position descriptions are similar is in the fact that an architect needs to have the depth and breadth of experience related to the software development/delivery/design, and, also, be capable of wearing different hats. What CRM Architect has to have on top of that is extensive experience with Dynamics CRM. I guess that’s the essence of it.

Dynamics XRM – why is it dangerous?

I think XRM is awesome. And I also think it is dangerous. This post is about the dark side of XRM.

First of all, I think it’s not XRM itself which is dangerous. It’s how XRM is explained and sold to the clients – that’s what is making it dangerous.

We do like to repeat that mantra about the “out of the box CRM functionality which will cover 80% of what is needed”. We also like to conveniently forget the fact that the other 20% can cost a lot of efforts/time/money before the whole system is, finally, delivered. At least that’s how it works on the sales side.

That creates a couple of false expectations, though:

1. One may think that 80/20 also applies to the efforts. It’s not always true – more likely than not it’s going to be quite the opposite

2. One may think that 20% is not something to worry about. However, we are talking about XRM. Which means custom code. Which means we are talking about software development. However, how many clients will fail to realize that it is, actually, software development till it is a little too late? There will be plugins, but there will be no source codes. There will be javascript customizations, but they will be using unsupported features. There will be QA, UAT, and Production environments, but they will have different versions of the same plugin. There will be a black box system and no one will be able to explain why is it failing with a strange error, yet Microsoft support does not want to recognize that error as their fault.

It’s not all, however. There is another scenario which I find almost amusing. We don’t have to use plugins. We don’t have to use javascripts. We can just choose to create lots of custom entities.

Now, the problem is not that it’s unsupported, or complicated, or difficult to implement. The problem is that, with each custom entity we create, we are deviating further away from the out-of-the-box system which Microsoft keeps building, so, out of a sudden, we find ourselves not using a lot of CRM features since they have nothing to do with those custom entities.

    What happens if we have 100 entities and only 10 of them are out-of-the-box entities? It’s very likely we will start having problems relating those entities to all the nice functionality Dynamics is offering: business processes, customer lookups, product catalogue.. pretty much everything starts falling apart since we are trying to squeeze a lot of custom data structures into the system. And, yet, surprisingly as it is, we can stay well within “80% out-of-the-box” rule since, technically, CRM gives us that option to create custom entities and to configure them. We do get relationships, we do get user interface, we do get workflows.. it’s just that we are not using any high-level abstractions like SLA-s, for example. Essentially, in this scenario we are using CRM in the same way MS Access used to be utilized.. to build a completely custom application.  And, as a custom application framework, it covers 80% of our needs. Does it have anything to do with sales/marketing/service modules which are, actually, what CRM is for? Well, quite often those custom applications don’t care about that part of CRM, so the whole power behind those modules ends up being unutilized.

Does it all scare you? It does scare me, especially when I see projects where clients don’t realize those traps XRM has for them until it’s too late to change anything, and, so, I find myself on such projects constantly thinking: do we even know why we are using XRM here?

And yet, with all that said, I still think XRM is awesome! More on that in the next post.

Dynamics XRM vs Dynamics CRM

I’ve been working with Dynamics CRM for over 5 years so far. That did involve various projects, for both private and public sectors. Some of those projects were more about CRM than others, but I’ve never seen a project where a client would take Dynamics CRM and start using it as is. There is always something.. missing. And there is always a customization required, then another one, then a security role, then a workflow, then a javascript, then, maybe, an integration with another system. The more people start using Dynamics, the more they really want to customize it.

I think it’s good, though. I would rather have that than find myself in the situation where somebody would start using CRM, find out that it does not meet the requirements, and put the whole implementation on hold just because there would be no way to customize the solution.

However, what I am wondering about is whether there is such thing as Dynamics CRM vs Dynamics XRM, or whether it’s always Dynamics XRM?

Check this out, for example:

What they are saying there is that “xRM depends on extensibility of the CRM platform on which it is built. Microsoft Dynamics® CRM currently provides the most powerful xRM platform available because of the Microsoft® .NET Framework that underlies it. Companies can typically achieve 80% of their business requirements using Microsoft Dynamics CRM. The .Net Framework, meanwhile, provides a common architecture that software developers can use to build custom line-of-business (LOB) applications that supply the remaining 20% of a company’s requirements quickly and economically.”

Which is, for the most part, a fair statement. However, there is an element of marketing there. If we make an analogy with a car, then it does not matter if 80% of the car functionality is avaialble out of the box or if 99% of the functionality is available. What matters is that the car should be able to take us from point A to point B, and, for that, it has to be 100% ready. So, if we turn that famous 80/20 rule around and use it differently, could it take 80% of the time to build those remaining 20% to get the whole thing working? I think the answer is that it may well take that much.

I guess what I am trying to say is that there is no pure CRM implementation out there – they are all XRM. Some of them are more XRM than others, and I actually see it as a potential problem.. but I’ll talk about it in the second part of this post

I found a monster..

Ok, it’s all about the mood. Criticizing today..

What is Dynamics CRM these days? It’s a monster. Remember those long-gone days when we had CRM 4? Or CRM 2011? When there was no interactive service hub, when mobile applications were not there, when there was, essentially only one type of CRM forms, and when we did not have to worry about setting up business processes, contact cards, SLA-s, etc.

Yes, we were complaining. Sometimes in a very loud manner.

As it is said, “be careful of what you wish for”, since, apparently, somebody out there was listening.

Problem is, some of those things which are there now are making Dynamics CRM more complicated than it should probably be. Of course, that also means we are getting new functions, improved usability, etc.. However, sometimes I’m just missing those good old days when I new that the only place my CRM users would go to look at their case records would be in the main case entity form. And now? They would go to the main form, to the service hub, to the mobile form.. and, shh, what’s that with the ADX portals?

So is it good or bad that we have so many options now? Well, the interesting thing is that, with all those new features being added to CRM, Dynamics CRM implementations are definitely not becoming more simple. They are, actually, becoming more complicated since somebody has to understand all the relationships between different aspects of the CRM solution. Like I said, Dynamics CRM has turned into a little bit of a monster.. hopefully, it’s going to stay tamed.

Interesting Dynamics CRM position

Was looking at the Interactive Service Hub user guide and found something I have never seen before(well, maybe I was not looking properly)


It’s official: those of us who used to be called CRM Administrators, CRM Consultants, or CRM Developers can now be called CRM customizers Smile Well, I’m not sure if this is a promotion or not..

However, there is something there which keeps bothering me. There has been a tendency lately among Dynamics CRM clients to request as little customizations as possible. Instead, they would prefer configuration changes. I’ve been always of the opinion that configuration and customization are, essentially, two sides of the same coin, and it’s almost impossible to stick to just one side when implementing Dynamics. However, the fine line between those two approaches probably lies somewhere along the lines of javascript or .NET source code which is required to implement customizations and which is not required to implement configurations. Now, it would not sound that nice if we were called CRM configurators.. So, how come Microsoft, essentially, equalizes customization and configuration, and yet there is, apparently, a difference between the two in the clients’ minds?