Are you working for a company that is looking to increase productivity or velocity? Are you looking to remove inefficiency in task hand-overs? If yes, try to honestly answer this simple question: is it possible to remove inefficiencies if you have waiting queue all over your processes?
There is a need in the queues where it is impossible to avoid human decision but, after the decision has been made and an approval was received, wouldn’t you want your request be executed as fast as possible? The single and most obvious answer for me is: Yes!
I constantly observe all the companies, I’ve worked with, fail to recognize that the need to solve an immediate and “burning issue” without even applying a common cohesive set of rules and guidelines across all the solutions in the company, lead to proliferation of one-offs solutions that are not reusable, that are becoming outdated very quickly and become a dead weight of a technical debt. People that solve the “burning problem” just in place receive a praise and move on to the next new shiny thing, leaving their bastard child behind to be supported by the poor souls that come behind them.
This issue of proliferation of non-reusable systems becoming even more acute in the IT organizations where development experience is scarce at best. IT professionals that have limited development knowledge are not positioned properly to follow “best development practices”. I’m simply saying that they are great expert in a different knowledge domain and may not have proper training in development processes and mindset. They may lack knowledge of which coding practices and decisions lead to better outcomes and which ones are future dead ends.
The same way a domain expert works vey closely with a development team to build customer-facing products, the internally-facing products should follow similar approach. Granted internal products may have much relaxed requirements for quality and eye candy, but nevertheless they should follow the same “best practices” and quality guidelines that real products do. In many cases internal products have much longer shelf life than the external ones and slowly they become the operational backbone of the company itself.
So, if you’re hoping some day to start increasing the velocity of your delivery, you can’t enable proliferation of the internal systems that do not enable automation and/or integration capabilities. Building non-reusable systems and components is a total waste of time and resources – it’s a technical debt. Systems that do not provide service capabilities will prevent other components and processes in your organization to benefit from them. Every time a similar functionality will be needed, it’ll lead to rewrite and duplication of data and code and you’ll find yourself in the need to correlate, reconcile and make sense of inconsistencies.
If all the above makes sense to you, here is a simple list of guidelines you can ask your guys to follow:
- Ensure that all the scripts and systems to be testable (basic development practice).
- Ask for mechanisms that a test system be reproducible. The test system should be representative of the production one. [This is needed to enable development for people that don’t have access to or don’t want to develop against the production components. Without this the development will be limited to only the person with the administrative rights to the target component]
- Establish a guideline that all the new components be reusable and expose service endpoints so other systems can interoperate.
IMHO the last item is the most important one that can lead your IT automation into the bright future. If all the systems in your organization will start to offer services, it’ll position you properly to integrate them better and get more automation in the future. If you delay establishing these or similar guidelines in your organization, you’ll find your organization very quickly in a situation with systems that don’t talk to each other, outdated, duplicated, fragile and smelly to the point that no one would want to touch them with a mile-long pole.
How do you deal with these situations in your companies?