Why It's Called Enterprise Patterns

[00:00:00]
>> The talk is called enterprise patterns, and where is the emphasis on enterprise? And I think that's a fair question. When we talk about enterprise patterns, and so somebody chimed in and said capitalism, which I think is hilarious. But when we talk about enterprise software, and it's somebody who has been on hundreds of enterprise engagements that the patterns that we need to communicate or rather that I find that individuals within an enterprise need to adopt to be effective is not the by nature or not an escalation of complexity but rather, they're oftentimes so simplistic that in and of themselves, they look like almost childish in a way.

[00:01:11]
And so, for me kind of this big, I think, philosophical and fundamental shift Is that when you talk about enterprise patterns, that the best ones are going to be very simplistic, in so much that you can apply them at scale across your entire application. And so this is where, when we talk about enterprise patterns, that I would be doing everybody a disservice if I came through and I started talking about immediately, right out of the gates, microservices, distributed architectures, high scalability, infrastructure with orchestrators etc without addressing the core problem that exists across all enterprise applications, which is complexity, which can be solved through the diligent application of first principles.

[00:02:22]
So just a little bit of commentary about this, is that when I run across a team that is struggling, implementing a solution, more often than not the temptation is to put the blame on the framework, or whatever technology that you happen to be using at the time. And so a really good example of this is that you'll show up and somebody or a team is having a problem implementing an angular solution, and it's not because angular is bad is because the implementation and the execution of that particular initiative is not great, it's problematic.

[00:03:20]
And the solution to this is to simplify the architecture, simplify the implementation, embrace first principles that even the first thing that I would do is, I would go through and I would look for the axis of evil and I would start to refactor those pieces out. Unfortunately, the default position, or typically the most common reaction that I see is that because a team's not identified the root cause of the problem, which is complexity and their response to it.

[00:03:59]
That they blame the framework, and then what happens is that they simply just say, we need to switch frameworks, and we need to go to react or view or from view to react or vice versa. And so I see this cycle of almost every three years, teams that have not embraced first principles, that they get themselves into problems, they blame the framework and they simply hop to the next hottest thing without understanding why their previous initiative failed.

[00:04:31]
And so if you want to change the quality of code that an engineer is writing, first of all, you don't change the way that they code, you change the way that they think and the way that they think about code, as a result, their code will get better.

[00:04:53]
And so I think that's a fair question in that, when we talk about complexity, the antidote is simplicity. And if you'll bear with me, that everything that I'm teaching you in this workshop, it all stacks on top of each other, in that all of these patterns and concepts that I am talking about, they scale infinitely.

[00:05:20]
And so we'll see more of that as we go along.