Always is cheap and sometimes is expensive. I have been using this principle for most of my professional career. It is intended to get at the heart of what it is we do when we design solutions by driving to standards, patterns, and practices. Repeatability and reusability are key deliverables for any solution design. It is a natural inclination to want to be creative. Think outside the box. But in the realm of solution design creativity in certain areas can get us in trouble. Innovate on the problem statement but the underlying technologies and capabilities should be based on standards and shared reference models.
In my early days when I owned a software development company, I used this principle of always is cheap with my customers to illustrate the importance of defining their business processes. I knew the project was going to be a challenge when a customer would describe their business process using sometimes. They would say “sometimes we do this and sometimes we do that”. I would challenge them and say that sometimes was expensive to program and how could we get the process closer to always? How can we turn guidelines into rules? I would explain to them the benefits of Business Process Management and how they should treat their processes as assets. If they did not clearly understand their processes how could they even think to automate them?
One technique I have used that works well is I would stand at a whiteboard with the process owners and have them describe the process without introducing any exceptions. Show me the happy path without discussing the outliers and exceptions. We will address the exceptions at some point but let us see if we cannot define a consistent process that has minimal deviations. It was not an easy task, but the customers always seemed to get great benefit out of the exercise. It showed them the need to document and standardize their processes to deliver efficiency and effectiveness to their operations.
Eventually, I moved out of the boutique development world and took an Architect role for a global Fortune 500 company, originally as a Solution Architect and then an Enterprise Architect. My design principles came with me, but it has been interesting to see push back to this one simple principle. In this larger Organization, they saw my always as a drive to standardization and that it would somehow reduce innovation and creativity. My counter is that this will foster innovation in the right places. If we are doing a solution design and there is no well-defined common reference architecture, then the project will develop their own solutions. This takes the focus off the true needs of the design of the business process we are solutioning for. Too many times I have seen projects spend time experimenting with technology and lose focus on the solution’s main objectives. If we are building or designing a software solution, certain elements should always be defined. My security architecture does not need to be invented. My storage options or integration patterns should not be novel. Monitoring, logging, availability, and redundancy models need not be invented. This should always be defined for the solutions group.
How then do you bring in new technology? The answer is in a controlled and thought-out way. The holy trinity of Architects, Business Architects, Enterprise Architects, and Solution Architects should be aligned on the current reference models in the Enterprise. If new and emerging capabilities are presenting themselves, they pick a project or two to apply the new capabilities so they can evaluate the impact on the Enterprise. If the technology makes sense, then update the reference models to reflect it. It becomes part of the “always” pattern.
I remember being on a vendor call one time for a large Enterprise I was working with. We were trying to evaluate if their tool could meet our corporate needs. One of my colleagues was really pushing the vendor to describe how their tool worked. He wanted to know how it captured metadata and if that metadata was stored and persisted. When the vendor explained the technology my colleague replied, “well that won’t work for us”. I interrupted the conversation and asked the vendor to list their top five customers. They rattled off the names of some of the biggest companies in banking and finance. I asked my colleague why he felt the tool worked for these companies, but our requirements were so unique this tool just would not meet our needs? We ended up purchasing the tool and it exceeded our expectations. The supposed technical flaw never became an issue. We were able to mitigate the exception and run our processes like all the other large companies saving us time and money.
Now I know you simply cannot take a Vendor at their word. You need to vet out their positions but invest in that before you start letting the vendor quote you customizations to their standard toolsets. They would love to do that. I sat in another demo once where a coworker asked for a capability in a vendor tool. Hands down the best vendor reply I ever heard. He asked the user “I have over 1,000 companies using my tool, and nobody needs that capability. Please explain to me more what you are asking for”. The user quickly backed off and said she guessed you did not really need that feature.
People will get creative. Creativity is good but it needs to come from a base standard. I have managed development teams multiple times in my career and I always set the same expectations. There are 1,000 different ways to code but when you come on my team there is only one and it’s mine. If you do not want to code my way quit now. I would onboard any new developer by walking them through our coding standards. How we indented. What level of code refactoring we went to. Naming conventions and the like. I expected everyone’s code to look the same. You might think that would stifle creativity. I managed change by having a request for change (RFC) process. All defined standards need an RFC process to keep the standards current and up to date. If a developer of mine had a new idea or a better way to do something they were encouraged to document their approach and propose it to the team. If the team liked the idea it went into the standards document. You see it was not really my code development model. It belonged to the team. This sense of ownership made staunch defenders out of my developers and they ensured that our standards were followed.
When we design solutions for business problems we must drive for rules over guidelines, standards, patterns, and practices instead of creativity and innovation. In doing so you will find that always is much cheaper than sometimes. The closer you get to always the better you will be today and tomorrow in any solution you design.
