Use standard, why and how?
One thing I’m known for the last couple of years is my approach to implement solutions based on standard, all the time. One could argue that using standard is impossible since everyone is different, that to standardize makes a business loose its competitive edge.
It’s easy to understand that mentality since many of us have worked within the IT industry for a very long time. Not that long ago to use standard was to adopt to the software suppliers strict usage guidelines, today this is quite different but we will get back to that. At those times we had software suppliers that developed their software based on customer demand but the customer base was much more limited, also limited to mostly IT departments. If we take for example Microsoft they had most of their contact with IT departments in larger corporations who often demanded more administrative functionality, for example security features or features on how to limit or “handle” the users in the system. In many ways the software supplier was limited to the input that came from larger IT departments, in that time their direct customers and not the end-users of the systems themselves.
The IT departments of those larger corporations needed administrative capabilities to administer the users, groups, features and also customizable in the administration functionality itself. UX design was not something largely invested in, so systems were not user friendly but IT departments were liking them. The systems worked because working meant that it was easy systems to administer and they were stable, what more could we want?
Everyone happy everywhere, not really, the users were not impressed and when IT departments were criticized they started to try to help out customizing systems. Using standard customization tools like GPO for Windows or customizing SharePoint with custom development. It was difficult and costly to make variants so the customizations were often strict standards for everyone. All users have the Word icon on the start-menu forcibly.
In the end two kinds of standards was implemented on top of eachother which both became problematic, the software supplier standard and the IT departments. This became hard to administer in the long run and upgrading software was difficult if modifications were done, upgrade projects took long time.
Entering the cloud era is to enter a time when things got completely turned upside down, users got a direct line with suppliers for example with UserVoice, twitter, feedback inside apps or just to get latest news through any online source. A two way communication got established between suppliers and end customers and the software transformed to a user-first software rapidly, this to hesitation for the IT departments, security experts and legal departments. Users adopted new ways of working without the help from internal IT nor wanted to follow any guidelines, things for the users were much easier, faster, lower cost and just better than before – one could say this led to shadow IT.
It is important to understand shadow IT and why it exists, I say it exists because it’s something users believe it’s needed. Shadow IT exists because the IT department is viewed as a supplier not as an integral part of the business. Shadow IT should be something that is incorporated within the IT department and this can only happen when there is no such separation between IT and business, shadow IT is just IT. When an IT department understands truly why users need new functionality and when users understands that IT can help with security, administration and lifecycle management a deep cooperation can evolve. Who’s responsibility is it to “change”? I takes two to tango so obviously it’s all parts but I would say that the major part are the internal IT departments that needs to show a change of mindset. It’s for example to go from a “no” to a “why” and to open up for discussing solutions and challenges, to go from a supplier-customer relationship to partnership where it’s an equal responsibility for the end result. Of course with each function to be primarily responsible for each competence area.
This is when standard can be redefined to be able to use all minds to try to implement software that takes all aspects into account as much as possible. To combine the evergreen mentality and to help users understand lifecycle management makes it possible for IT departments to also receive questions such as “why” and “how”. How can a combination of user- and administrative friendliness grow? For me this comes down for the use of standard, a definition on standard of today is to be able to release standard functionality from software supplier who develops features that have been received from thousands of users. To do this, we need to help in how do we provide everything possible as fast as possible without loosing the necessary control that in reality the business and also the users want. Everyone wants security but not such security that makes it impossible to work. Everyone wants new great features as fast as possible, as long as it doesn’t means high costs or disruption in production. I believe this can be achieved by combining the entire competence within the organization. Everyone needs to “give and take”, the IT departments might need to change their way of working but users also in accepting what they also want, flexibility and new “great” features which might change their way of working.
Accepting and adopting constant change is something that the IT industry have been struggling with last couple of years and the time has come for users to also start adopting constant change, or if everything is as it should, to adopt constant improvements also in their business life as they already accept outside business. This, I believe can only be done if the software is deployed as close to standard as possible providing the functionality users seems to want and need which provides the possibility for IT departments to upgrade without hesitation. Customization on software should be done outside of the software itself with the help of API’s to be able to disconnect our customizations from the software itself, to create a microservice architecture out of all customizations as much as possible. This makes it possible to always be able to upgrade the standard software and to be able to discontinue our development when and if our custom code is no longer necessary and can be replaced. Keep custom development low, keep that custom cost low and don’t get attached to your custom babies, they should in my mind be replaced as soon as the possibility appears. If your need never comes as standard functionality, then you just might to evaluate why and always evaluate if the cost is worth the effort, there is no easy answer to this.