Tony Maley in Choices, Architecture, Agile



I once spoke briefly to Malcolm Gladwell at a conference where he was one of the Keynote speaker, about his famous TED talk on choice in the spaghetti sauce retail market. I had been struggling with the thought that too much choice for my kids with Movies, Video Games, TV Shows, Books, and Activities was overwhelming for them or even that too much choice stopped them from actually engaging deeper like I did as a kid, where choice was not a problem. His talk struck a chord, and when I spoke to him, I told him that his talk and my own experiences have since taught me that choice is what my kids wanted and even needed as being exposed to a wide range of content and activities was more beneficial to them.

Years later I had a similar thought in my day job where I was in the role of Chief Architect for a multinational company. It was evident to me that Developers, Scrum teams, Architects and delivery executives all loved choice. Choice of language to use, frameworks to embed, data platforms, where to host, what vendors to use, etc. People like choice, restrict that choice and they will push back and argue with every "standard" you set or vendor you choose. They want things their way; they want to be in control and have a say in the design of their product. It's normal, they should, and if they don't, then you should be worried.

Should we restrict choices to make it more cost-efficient and easier to manage or do we provide many options that our teams feel empowered and in control when they choose?

My opinion is clear now, the more you empower teams to choose their stack and platforms the more they feel like they own the overall solution, the more they want to make it work and show the world their choice was not only correct but inspired. We need to empower and enable these teams to do this to realize the power of agile or in fact any team development.

Choice empowerment is not the norm though. Far from it. Most, if not all, IT executives and Enterprise Architects want to do the opposite.

Why? And are they right to want limited and controlled choices? Here are a few of the more common reasons that I hear:

1.The belief that cost will be lower if there is only one choice and we all use that choice.

Maybe, not convinced on that but what I am sure of is that if you restrict choice, then the development teams will sneak it in somehow, they will find a way, and you may not even know about it. They will argue, push back and ask for reasoning behind that choice, documentation, comparisons, etc. - all of that effort will cost money, potentially lots of it.

2. They believe that development will be quicker with only one choice.

That is possible, but only if:

  • That choice is a 100% fit for the solution requirements both now and future
  • The team are already skilled in using that choice
  • It does not slow them down to use it.

Unlikely to be true in most cases, therefore giving the team choice will provide them a higher percentage chance of being able to design a solution that does meet the requirements, that they can use and will not slow them down.

3. They believe re-use will happen with limited choice.

Yes, this will happen. The question is, do you want it to?

Don't get me wrong, reuse can work, Libraries, Patterns, and UI/UX are good examples of this working well, but mostly I feel that the time and complexity of making reuse work are not worth it, usually slowing teams down to try and make it work. Often teams are encouraged or mandated to make it work to show benefits promised elsewhere by a CTO etc. - this stifles innovation and results in design compromises or countermeasures.

Scavenge don't reuse. I believe that by letting the teams choose what they want to reuse or scavenge perhaps being a better word will provide better quality innovative products and potentially time reductions.

4.They believe that a vendor with one choice will be better strategically.

This strategy I have seen fail many times. You buy into SAP, Oracle ERP, Sharepoint or even CA IAM suite as a strategy. Every solution now needs to use that platform for you to realize your investment or to justify the 50 people you had to hire to get it implemented.

Most of the solutions that use it, I'm sure you had to compromise to make it fit, or even worse, you forced your business not to use the choice they wanted as you had a "standard" that they had to adopt. Of course, your stakeholders now resent you for it, don't want to use it and are just waiting for it to fail so they can get back to implementing their original choice.

More often than not this strategy will end in an expensive rip and replace situation for all the solutions, you forced it into when they didn't fit in the first place.

5. Vendor management will be easier and more cost effective.

Only one MSA or Enterprise Agreement to do, only one line item to manage the portfolio. OK, this is horse manure, IT Portfolio lists are monumentally large, the business drives this, why? They want choice or to be in control. We need to stop fighting this and start to find a way to embrace it. The standard MSA >SOW process may not be the way of the future.

6. We don't have or can't afford to hire skilled staff to manage and support all these tools.

In 1995 this would be a fair point but not in 2017. Developers, Architects, Data Analysts, and even business team members are self-sufficient in supporting the tools they want to use, they don't need or want anyone "managing" their tools. Most tools don't require the same level of support needed ten years ago.

A PaaS approach means no support teams for OS/App Server etc., and this allows for teams to choose what platforms they want to use without needing to hire support and engineering staff to make it happen, this reduces cost, time to deliver and increases quality.

With SaaS, of course, this effect is even greater so long as you resist the configuration overkill urge!

7. For every tool introduced, an existing tool should be retired.

Like the previous two points, there is a belief that fewer tools will equate to lower costs. I agree with this IF you manage tools like you did in 1995, but we don't.

Teams and even individual developers etc. will want to use specific tools that make them more productive, this is normal and should be encouraged, let them choose, let them feel comfortable with the tools they typically use. Empowering them with choice will pay dividends as you will be removing obstacles, even if sometimes they are only perceived, for them to be productive.

Clearly, when tools become platforms like automated testing, build platforms, Code repositories, etc. then you need to mandate absolutes rather than choice but at the tooling level, allowing for choice will be greatly rewarded.

8. How will we govern the security and quality of our software with all this choice?

At this point, the absolutes come into play, and choices end. I will answer this point in detail in my next post on Absolutes.