I have been using the same architectural principles for solution design for years, always is cheap and sometimes is expensive. I am amazed at some of the different reactions I get from IT professionals when they first hear me say it and I do say it a lot. For the most part, the response is affirming. It resonates with people in a solution design capacity. But most recently I came across a very seasoned IT professional that I was getting to know and was very impressed with his background and experience. When he first heard me utter my favorite phrase in a group meeting, he reached out afterward for a one-on-one discussion. He wanted to discuss in more detail the meaning of what I was espousing. His first reaction was that mandates never work. You can’t tell people to always do things a certain way. There are only a few examples in tech history where a mandate worked. The most famous example is the Amazon Manifesto. I considered this excellent feedback and I wanted to capture the summary of that conversation here.
I have considered the “always is cheap” comment not as a mandate but as something aspirational. I know an Enterprise will never get to always. That is not the goal. I considered the phrase more of a fact-based position when it comes to designing solutions. The more variations we add to a design the more exponentially complex the situation becomes. If we have multiple ways of doing the same things then we have to have multiple support models and multiple governance models and multiple security models and you get the picture. But can we mandate teams to work towards always? This is where leadership needs to come into play. Leadership needs to demonstrate the importance of adhering to standards, patterns, and practices. Look at line 6 of Bezo’s manifesto:
In making this claim Bezos was showing his commitment to supporting his directives. Thou shalt do this or else! I used this story in a presentation to the IT leadership onetime for a large Fortune 500 company I was consulting with. I was presenting them with an API-centric model to transform the operation and I referenced the Amazon Manifesto. The CEO’s response was interesting. He laughed it off and said the company would never threaten to fire someone in this way. I replied that he needed to at least demonstrate the commitment to the importance of this sort of mandate. Just make the statement and see how people respond. Show a commitment to truly changing the way the company operates and transforming the Enterprise. Otherwise, it will be death by a thousand cuts. Different ways to do the same thing over and over again drive costs and erode the customer experience.
So I never thought of always as a mandate but I guess it is. But what is wrong with mandates? Why can we not dictate how work gets done?
This gives reference to one of my other favorite phrases, the Benevolent Dictator. Every group needs a defined ultimate decision-maker who keeps the team on task. When tough decisions need to be made they listen to the options and help drive consensus. They don’t need to threaten to fire anyone but they do need to be a strong leader that shows the importance of their decisions.
I was working on another project that had a great leader at the helm. I was in a design session for a new product release and the team got caught up on the simplest of phrases. They were establishing their mission statement for the product. The conversation was around the phrase “a leader in the market” or “the leader in the market”. The difference of one simple word stopped the team in their tracks as they debated for almost two hours. On one hand, was the position that saying “a leader” meant to establish that there are other players in the space and we are one of them. On the other hand the bold phrase “the leader” solidifies their dominance in the market. After two hours the leader of the team looked at me and commented that I had not ventured an opinion yet. I commented that I was being paid by the hour and I was enjoying the debate very much and until someone made the final decision the debate would continue to rage on. He smiled and agreed. “We are the leader, decision made”. He said to the team that we would revisit it in 6 months to see if the sentiment in the room would change once the new product was released. He took a stand but offered the team members the chance to give their opinions again in the future. They did end up being the leader in the market. It is important to note that these decisions should be recorded. Read my article on a solution design process for more details.
Leadership must support and enforce standards patterns and practices in the Enterprise but how can they know what those standards should be? I think one of the most useful emerging tools is Business Architecture. By investing in the components of business architecture the Enterprise can begin to see the holistic view of the business capabilities that help drive value for the organization. And if we align those business capabilities to the technical solutions that support them you will start to see multiple ways of doing the same thing. Look a little closer and you will see lots of money spent to implement and support a model that delivers a subpar customer experience. True leaders, the Benewvelont Dictators will see this and work to drive to standards patterns, and practices. Call it a mandate if you like but the fact is in the world of Enterprise solution design always is cheap and sometimes is expensive.
