Diego Pacheco Tech blog

I have been doing practical and real software architecture for more than 20+ years. Software architecture is a great passion of mine, close to my heart and even to my identity or just id function if we think about functional programming :-). I have mentored and coached many architects during the last two decades. Today, I want to share some thoughts on something that represents the complexity and duality of the software architect role. Being an architect is not easy, it requires a lot of sound judgment, trade-offs analysis, design skills, research, requirements extraction, trend prediction, futurology, and lots of non-obvious skills. Architects must code, be practical, and make very good calls, resulting in better positioning for the future. Doing such a task is not easy and requires a lot of hard work; it's demanding and requires constant improvement and attention to detail. What is essential to extrapolate an architect's non-obvious antagonistic skill set, which the architect...

Services are a very important architectural construct. Proper services( POSAM definition and principles) are even more important. However, not all services are the same. Not all APIs are the same, and definitely not all services are the same. Just having a Service or API, we can call it many different ways; the question is how good it is and how solid it is. I still put my money where my mouth is and say that services are a very powerful concept and the right level of abstraction for most problems. However, when a service is presented to you, you cannot assume you will have high quality just because it's a service. IF services are desired, multiple services must still be desired; after all, service orientation is about having services, not libraries. However, we know that when the granularity is wrong, and when we move data and capability to the wrong places, let's say, the wrong domain, we make things worse, not only risking breaking isolation but also leading to wrong abstra...

In the matrix movie(classical and awesome movie), there is a classic scene where Morpheus challenge Neo's understanding of reality and offers 2 pills the Blue one which would keep the status quo, and the red one, which could be painful but would be the reality.  If you have a successful company with software thats the reality of the industry. In other terns, the discussion can seem as should we re-write the software or should we strangle it. Re-write software and even strangler patterns have cases of success and failure. Before we enter into the trade-offs of this complicated dilemma lets us understand the forces which create problems and opportunities that are around this discussion. Let's talk more about the context and their trade-offs. 

Big Companies have lots of software. The Software industry moves pretty fast. However, not all pieces of software are moving that fast. There are always competing priorities between news business domains, acquisitions, new features, improving user experience, fixing bugs, improving security, and being up to date. If you have good architecture, isolation of databases, proper contracts, and tests, migrations can be much easier. However, not all pieces of software have the same conditions as you might have orphan software with no owners, old tech, lack of testing, lack of isolation; in those conditions, migrations could be pretty challenging. There will always have migrations one way or another. In the last decade, lots of companies have been migrating from on-premises to the Cloud. 

Complexity is something that needs to be managed down and is an eternal battle. Part of the battle is to stay away from the style and cosmetical changes. Can we really get 100% of style discussions? Even removing discussions of 2-4 tabs, there will be some form of style on the discussion because every engineer has a background towards JEE, Spring, or Functional. That's a greater generalization, and there are other "design schools" over there but still quite common to find people within these 3 backgrounds. A Philosophy of Software Design is a great book that explains what complexity means. In the book, complexity is mainly described as "Obscurity," something that is not readable and has a high cognitive load to be understood. IMHO some problem spaces require you to have some background and experience on how some problems are solved; otherwise, it might look the worst they actually are. Complexity discussion often hard since lots of engineers have high EGO and h...

There were some interesting posts about UML recently. Mainly being  “   Has UML died without anyone noticing? ” and “   Why UML “Really” Died ”. I also made some po s ts about UML in the past — mainly “   UML Hidden Gems ” and “   Architecture 101: Thinking about Design ” and “   Internal System Design: The Forgotten Discipline   “. IMHO success means decline and eventually abuse. That happened to all successful movements, technologies, and methodologies I can remember such as Agile, Architecture, DevOps, Docker, Spring, and many more. Yes UML was abused and used in the context of the heavy and rigid process. UML was often used for all CRUDs which does not make sense and does not add value. But honestly, if we see things with DDD lens even CRUDS don’t make sense especially with UX sense CRUD are not ideal at all. IMHO what happens is we are exposed to fashion and marketing. There is internal and external pressure to do things in one way instead of anot...

UML . Ouch. OK, Diego don't you have some newer or shinny or sexy to talk about. Well, it's 2020 right? So jokes apart.  UML is modeling language from the 90s. Software Architecture and Software Engineering evolved a lot in 30 years. So is UML still relevant? IMHO Yes and No. The part that I dont think it makes sense is the notation part of the formalism part. Visual diagrams can be simple enough to be understood and you can survive without notation language. So if UML is not about the notation what is about? Or why there is value in UML in 2020? Questions that I intend to Answer in this very blog post - Let's get started.

DDD is a modeling method highly focused on business domains and comunication. DDD solves several issues we have with Services/Microservices and Backend Systems in General.  One of the biggest challenges in Services but especially microservices is to find the right boundaries meaning what should belong to one service or what should belong to another service. It's common for engineers, often, just write code right and ignore the design. Modeling is hard for several reasons but one reason is the software might work, even with the wrong design. The right Design starts placing the code in the right place. DDD is key to that. DDD is not only about placing the code in the right place but also about how we communicate with the business to figure out that and other ways(DDD Patterns) to express the solutions.  

Software Design is a super important discipline. However, Design is often made by accident. Software Design is really needed because there is a huge cost associated with some changes further down when you have a scale and lots of software. Lots of engineers dont understand design or understand it on a superficial level. Software design is on the core of everything we do in software and I believe we need to talk bout this super important discipline. So I made a slidecast talking about the subject. Let's get started. 

Several years ago everybody was talking about and trying todo deploy automation. This is a fixed problem, right? well, several companies now have good pipelines but most of the tech industry is not quite there. There are several reasons why release pipelines are more important than they look. First of all, Deploy != Release, I talked about that on my previous post about Testing in Production . Several companies have doubted if they need the newest forms of CD(Continuous delivery) like GitOPS but I can say almost 100% sure, this is a must-have. So let's step back and talk about Lean and Kanban and business agility. Even if your business is not asking to increase your deploys and release frequency you should be in pursuit of that. Lean has the concept of LEAD TIME, DevOps is about Lean if you have doubts go read the amazing Phoenix project from Gene Kim. Lead time is about from Idea to Production and how long it takes to get there. Production is the best place to be, so you must i...

As a consultant, a question I got a lot is what is software architecture anyways? What should architecture do, what is the skillset it needs to have? So, first of all, I believe everybody in your team should be a software architect. That's the silicon valley way. Brazil has a huge demand and very few qualified people for us to work in that model which ends up having a few software architects per company. Hiring is extremely complicated, slow and difficult and easily you will pay a lot for someone who is not a proficient architect. However, develop these skills is a good idea for every engineer there are a couple of problems like A) Not everybody wants to be an Architect. B) It takes time. Companies dont have time and the demand is here; So this forces a pre-mature software architect exposure. At the end of the day, it does not mean this is a bad thing. Having opportunities is great for everybody but it all depends on how you develop and use your opportunities.  Going back to the...

This is a complicated matter. Every single company on the planet deal with estimates somehow and use some kind of estimates. There are people who are pro-estimate and belive giving an estimate is a professional thing and we need to do it and there are people who believe we need to reduce the number of estimates we do(I'm the second kind of people). Estimates often are wrong and incorrect. However, there are people who are really good on the estimate and get it right with very few error margins however when you look into details you might realize that being good on estimates might be killing your business. You might think is enabling you to sell more and get better but easily it could be the other way around, no worries I will answer why. This is a very hot and passionate topic so brace your self and let's go. Estimates are old, most of the time they are lies and they are not reliable however we continue to work with estimates expecting they will work when they dont work.

I believe a lot in Agile and Lean Principles. Agile movement historically often focused too much on teams and really left Software Design and Architecture behind it. Regular Engineers often belive a lot in Clean code and take it as a dogmatic bible and only source of truth. Clean code has some good stuff like the Boy Scout Rules(Alway left the code better than you found it). However lots of clean code "truths" are not so "true" at the end of the day. I've found considering the code without a Design and Architecture, extremely dangerous.  Most of the time I saw the worst codebases ever was related to very poor Software Design and very poor Architecture. Having a Good Architecture and Good Design does not mean you will have Good code, however, if the Architecture and the design write the code is very simple and easy to change. However, if the Architecture and the Design are wrong it might be impossible or very hard to change the code.

Estimates are lies, estimates are not reliable. It's super common to have companies doing estimates completely wrong. There is no way to do estimates right, however there are ways they can be even worse than usual like: A) Having managers doing estimating for engineers. B) Not accounting holidays, Refactorings and Bugs. C) Not comparing working items D) Ignoring variation: Different sizes, complexities, technologies, needs. E) Not understand when the system is stable or not. Very often estimates are done before the project or product start and where variation and uncertain is sky high. When we take a look into PMI, which is based on bridges and buildings we still see buildings and bridges with extreme delays, extreme over budget and poo quality. If this is true for construction engineering why the hell would not be true for software engineering where we barely have 50 years of experience as a industry compared with the +2K years in construction engineering. Project after pr...

Several years ago it was impossible to think about software development without having at least a business specification(usually in a word document) and a bunch of UML diagrams like package, class and sequence diagram. That was a pre-agile era where process and formality ruled the IT software development industry(yes folks, yes I'm old). Back on that time software engineering was pretty much conceived as "process".  Now we live in a more civilized era, however, back on that time, there were some interesting and valuable things(tools, techniques, principles and even practices).  Like the English expression, you need throw bath water but keeping the baby. I was wondering why these phenomena happened and still happen today. First of all, we are SOCIAL animals we tend to have some kind of "fashion" behavior where we follow the "flow". Needless to say that UML and Software internal design is not quite popular today with the new kids. I don't miss the...

Quality is such an overrated word. Itś so 80s to say that you are doing something for quality sake. Today quality can appear with a different meaning -which often means specific things which people care about let's say Green or Organic or Oil-free. When we are are talking about software development it's the same thing. Quality is a 2k thing and nobody uses in this way anymore however when you think more most of the times we are talking how we do things like automation or microservices or Chaos Engineering this is what we do and how we do it. It's quality but with a different and specialized focus.

This could sound strange. Martin fowler said once, who need architects? (fowler article) . I always believe that to be specialist in something you need to that thing, for me is very complicate the view of *Specialized Architect* the IT Industry have. First all IF you dont CODE you are not an architect anymore, because CODE is want make you pure, its the bound that make you practice every will keep you current. If you think about money when money become with no value? when the coin is not current, so if the coin is not running and its old its consider not current and lost the value, why for software architect we think just because you did something 5-10 years ago you still have value? Because is far as i know things change pretty much everything is sense of technologies from 3 to 3 years. There is value being a mentor and give guidance for other architect, discussion high level solutions are well but this is only 30% of the problem, that's all the piratical, operation and producti...

The IT-industry always got 1 thing of of 10 and just because they have 1 thing they think they got the point. I saw this with SOA, REST, Agile and now DevOps is happening too. Yes i will say one more time that the DevOps team is wrong. Is so wrong, is not just a name and is not just a matter of practices. More and more a see what the it industry got from DevOps is CLOUD and Automation - witch is great because this a very important aspects of devops but however devops is way more than that. The confusion a SEE is calling OPS -> DevOps, OPS is OPS, OPS is not DevOps. You have Dev in your company a most likely have a ITIL shared OPS in your company so lets say you have 100 developers mostly you have 20 DBAs.

What is an architect? What it does? why do you need them btw? Thats really depends on what you belive and how to you see systems. The IT Industry have some common ground ideas, but often ideas get mixed with different interpretations of the terns and practices. There are company that say stuff like an Java Architect or .NET Architect. I think this is worng, most likely they are senior developers in java or .net or a architect that knows one of this languages a real architect know more than one language for me. So an Architect is an architect is not an Java Architect. If you just know java could you be consider architect? Today a solution could be using several different technologies and stacks, would a pure vendor/language solution be ideal?

Software development continues to improve, once you add new languages, design concepts, paradigms(like functional programing) we start having new ways of doing things, so whats really matters? should i change somethings and embrace everything or should i change nothing? In this post i want cover something if you was java developer was the central idea around java development for years. Spring Framework dominate the fields for more than a decade. The real question is not if  you should be using XML or annotations(like Guice ). Either if you should go XML or java Annotations. Thats kind of old discussion, so basically what are the options now a days?