Simplicity Needed

I’ve been thinking a lot about simplicity lately. The need for simplicity keeps surfacing in front of me over and over again.

We are doing some merger work and anywhere that we have customizations (one either side of the merge) we find that it dramatically increases the difficulty in completing the merge and integration. This complexity translates into slowing things down, which is deadly in today’s business, and it translates into more money(people, time, effort) to complete the integration.


We are replacing some IT systems now and I’m adopting the position that we must use the new system out of the box with only the system configuration options used for customizations. We aren’t going to change anything in the system we are buying. Making this shift takes purpose and focus because there is a huge tendency to make the system behave how you are used to things behaving. I remember putting in an ERP system years ago and the system had 18 ways built-in to do cycle counting of inventory. None of those 18 seemed to work for us. Funny. I said they had to pick one of the 18.

This complexity is one reason why companies tend to orbit around a single ERP vendor and its eco-system and they avoid interfacing to other systems. Any time you integrate with something outside the central core system, that complexity raises its head again. If you are one of the main vendors (that start with an O or an S) then this favors you.

The complexity also surfaces in how you do things with systems. We’ve built an account approval process that in one case requires 8 approvals in the system before a person can get permission to do whatever. 8 approvals! I suspect one could start a war with less approvals. But now unwinding this complexity takes work and focus and purpose to achieve.

IT has got to be more vocal about stamping out such complexity. I’ve not done enough.


4 thoughts on “Simplicity Needed”

  1. Hi Mark,

    Simplicity is becoming increasingly difficult to achieve in the API economy world. App vendors are selling base platforms with the expectation that the customers will customize it to their needs using the provided REST APIs. I used to like this approach as it gave IT implementors and system integrators lot of flexibility and power. But I don’t feel the same way anymore. API based customization and integration is good for automation of tasks but not good for the architecture simplicity. As the number of API hooks increase, the complexity of the overall system increases exponentially. It is no longer easy to switch cloud service providers because of all the API hooks in place. Simple things like User Provisioning (both user onboarding, and termination) have become increasingly complex in the API world. The O and S vendor you mentioned, and also G and M, all want be the Identity Providers. Once they become the Identity Provider it is not easy to swap them with a different vendor. They all participate in the Simple Cloud Identity Management (SCIM) standards group, but none of them want to implement SCIM.

    I am not seeing anything on the horizon from any of the major cloud vendors to address the simplicity issue. I think this has to be driven at the executive level. The executives of the customer companies should band together and have regular meetings with the executives of the vendor company and demand standards based APIs, simplicity and out of the box capability rather than using APIs for everything.


  2. I think the API trend is the solution to simplification. However, if we intend to implement an out-of-the-box solution, we have to account for majority of the work in the organizational change management domain. We might be saving time rolling out a technical solution but this will require people to change their work processes and I think this is where the bigger challenge comes into play.

    Solution delivery folks cannot make this happen without an executive champion who can pretty much remove political impediments to implementing out-of-the-box solutions. In as much as we want to be democratic in our leadership, we sometimes need to take an authoritative position to make things happen.

    In Neil Whitten’s book titled “No-Nonsense Advice for Successful Projects”, he used the words benevolent dictatorship leadership. A style of leadership where the leader hears every input from his team and then makes a decision that everyone must follow. This is a more effective leadership style than consensus or democratic style of leadership. A related story on this is Sun Tzu’s “Art of War”. I cannot forget the story of the emperor’s concubines. The emperor commissioned Sun Tzu to train the concubines for a conflict. The usual hierarchy was followed and the head concubine was made team leader. When Sun Tzu tried to make them follow some instructions, they sort of ignored his instruction and Sun Tzu did what he needed to do to get the job one. The emperor was furious on what he did to the head concubine and he told the emperor that if he wants the concubines trained this needed to happen. The emperor had to agree and empowered Sun Tzu. This got him the result he wanted.

  3. Good comments and all right Randy. We need leadership who makes tough calls based on smart analysis. It needs to be done quickly after hearing the tradeoffs. There are huge change management implications and trade-offs involved in this matter. Thanks for stopping by.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s