Welcome back to Armchair Architects as part of the Azure Enablement Show. Today we will be discussing the term concentration risk, which means concentrating your solution on one technology and how to avoid what one architect terms ‘silly miracles’. Our hosts will be David Blank-Edelman and our armchair architects Uli Homann and Eric Charran.
Eric defines concentration risk and gives an example.
Eric has friends in the financial services industry and the term concentration risk to them means over indexing or over investment in a specific area to the harm of the larger portfolio. The term concentration risk is gaining traction in the technology space also, specifically the architecture space because the same dangers of safeguarding your investment also exist.
When you're talking about distributed systems and microservice architectures, if you concentrate in one industry or one vertical or one area, you risk the stability and diversity of your portfolio to withstand any challenges associated with other areas that you're super invested in. The same thing happens when you're looking at architecture. If your architecture has transaction processing, has analytics associated with it, has a user experience, there's a key element of technical risk associated with that architecture. Your first instinct is to make sure that the system does what it's supposed to do by addressing that element of technical risk. And sometimes if you're not careful, you can find yourself subjected to concentration risk by over indexing and solving that technical challenge. And then just hoping/trusting that the rest of the system will develop around that core area of technical risk and that when you put it into production things typically don't go that well. That's what happens when you find yourself a subject to concentration risk and you say “oh, I over indexed on asynchronous transaction processing to the detriment of streaming analytics or and inventory reservations” or anything like that in nature.
Uli talks about how to determine if you are too bound to one technology and gives an historical example.
David brought up the question of how do you know if you have concentration risk and what do you do about it? Uli is going to use an historical example to answer the question and his view is when you think about the world's dependence on relational databases in SQL. It started in the late 1980s, then in the 90s it started to become the default choice, then in the 2000s there was just no question you built it on a relational database because it was great. Transactional, asset backup, restore was easy and stuff like that, but it worked really well for the scope of computing solutions we were trying to solve. But ultimately it became a concentration risk because there were new requirements coming in that impacted the relational databases which were ill equipped to handle.
For example, the rise of ecommerce, when you have zero idea how to scale your system, you need elasticity, you need to be able to scale beyond a single node and so forth. And for the most part, relational databases effectively are still bound to a single computer because of lots of reasons why that is. Then came the rise of NoSQL, so from Uli’s perspective, the detection primarily is that you can't meet the requirements that you're supposed to meet with the technologies that you have been focusing on because you have talent, you have training, you have experience, the operational model is clear, all of these are good things. But then suddenly you see, oh now I need to really do lots of arm twisting and lots of crazy things to make that technology work for my scenario.
So, an example of concentration risk is being too focused on relational databases to NoSQL. You know you are in a concentration risk area where you say, “oh, I've concentrated too much on one pattern, the relational asset, all this stuff which doesn't meet my requirements.” Apply this to an ecommerce scenario, for example, where you have lots of unknowns; unknown scale, unknown transaction rate, where you just can't design the system or if you design it, you over provision, it's a ginormous system and then you have just a small number of transactions come in. It would then be considered a mistake as you spent a lot of time and money to handle the small number of transactions. In Uli’s opinion, that's where he thinks concentration risks happen. Then funny enough, the world shifted to NoSQL, which is the answer for everything, which is also nonsense because relational databases have a lot of great attributes that make a lot of sense and make development of applications really easy. For example, asset transactions are fantastic. You can write into the database, you hold the transaction, and some other people can try and write/read the data, the database will protect you from ghost data and stuff like that if you don't have an asset such as a NoSQL database you have to figure out is this data right? Is this data written already or not or what's going on? There's a lot of good things about NoSQL, there's good things about relational databases and you must understand which is what. To Uli, concentration risk is if you over pivot to one or the other technology and/or pattern to effectively solve your problems.
David sees a combination of dependences for concentration risk along with attention economy. The term attention economy reflects an acknowledgement that the human capacity for attention is limited and that the content and events vying for that attention far exceed that capacity. Humans are good at sticking with the things that they really know and have a lot of expertise in.
Eric reacts to David’s phrase ‘Attention Economy’ and adds the concept of ‘Silly Miracles’.
Eric likes David’s phrase attention economy because that's really what it is. It's being able to spend your attention in different places and it's easy for you to over index. We all gravitate towards what we are comfortable with and what we've grown up on and what we feel confident with. Which is why newer, early in career folks think NoSQL is the answer for everything because they're more comfortable with it than older architects such as Uli and Eric who grew up during the relational era. So, here's what Eric thoughts are to tie this all together. His thought process is to avoid ‘silly miracles.’ Eric calls them silly miracles because they're unnatural human tricks associated with you trying to fix concentration risk that you've already experienced by doing things that are miraculously kind of silly to cover up a hole in a portion of an architecture or portion of a solution that didn't do what it's supposed to because you focus too much in one area.
Eric gives an example of a ‘Silly Miracle’.
An example of a silly miracle is one in which you focus on flushing transactions to the database and your order taking application, but you don't do a good job of taking the orders themselves or scaling to take the order. So, the order taking experience suffers because you focus so wholeheartedly on making sure you can flush those transactions to the database with intentional consistency that you have a really good database write engine, but you have a really bad order taking experience. A silly miracle would be “well holy moly now I actually have to write a whole bunch of hard code in order to make sure that the front end of the application actually can provide a good experience for customers, which by the way will generate technical debt” which makes your system kind of untenable from a maintenance perspective.
How to best avoid ‘Silly Miracles’.
To avoid those silly miracles, the question becomes, “well, do I want to detect when I'm in it?” And the answer is “yes” you certainly want to think about it from a from a concentration risk perspective. Eric’s idea in the way he keeps track of this is he audits the concept counts associated with the entire system. So, if you have addressable concept counts, one way to figure out if you're over-indexing is how much time have, I spent looking at all these other concepts that the system has to do in service of the end-to-end; in service of the experience and what this thing is really here to do. It might be fun to create a really scalable transactional system that flushes to the database but is that going to denigrate or be detrimental to the whole purpose that the system is here to serve, which is taking orders.
Eric reiterates the original concept of concentration risk from a financial perspective.
So, taking this conversation back to the origins of this concept of concentration risk in financial services.
You're over indexed if you have over invested in a specific industry or a specific stock that makes you feel comfortable. You might feel good while the stock is going up, but then when the entire industry takes a hit and goes down, then you're like “OK, all of my funding was in this bucket and now it's, it's trashed.” Think about this concept and apply it to over indexing in technology as it's the same concept.
Consult with others on your problems.
The way that Uli thinks about this is to keep an open mind and have a tools chain of capabilities that you're looking at from the technology, relational, NoSQL and so forth, the patterns and the approaches. And always step back and say, “what's the most rational course we can take?” And if you feel like you are going down your usual rat hole because that's what you really understand, maybe reach out to some other friends in the field and saying “hey I'm looking at this problem. Am I looking at this the right way?” So that's another way to work around concentration risk because you only know what you know and if you are able to reach out to a community of people either internally or externally to say “here's what I'm trying to solve. What do you guys think?” Uli thinks you will get a much more diverse perspective. Keep in mind, you should temper this with what your organization capabilities are; what can we operate and so forth. But don't go for esoteric ideas, that is maybe the right thing to do for the solution without looking at the other half of the problem. Can I implement it? Can I operate it? Do I have the money to buy whatever and fund the solution. Uli thinks there's a little bit of a balance, but it's important to not over index on specific things to the point where you just say that's automatically the answer to the question.
How to avoid the pitfalls of chasing the new ‘shiny object’ solution.
From Uli’s experience when something new comes up people get excited about it, one example is the term metaverse. Everyone talks about the metaverse, everything is a metaverse. It still doesn't solve relational or transactional database problems as we still need other technologies to solve those problems. So, from his perspective, avoid the hipster terms. Not at all costs but use the hipster terms for things that make sense but still have the arsenal of technology in your mind to solve for your business problems.
Recommended Next Steps:
If you’d like to learn more about the general principles prescribed by Microsoft, we recommend Microsoft Cloud Adoption Framework for platform and environment-level guidance and Azure Well-Architected Framework. You can also register for an upcoming workshop led by Azure partners on cloud migration and adoption topics and incorporate click-through labs to ensure effective, pragmatic training.
View the whole video below.
