Three things that negatively influence an architects design choices
There are three things that software architects and developers let influence our design choices that we should all be wary of. On the surface these may not seem all that bad but give me 5 minutes to change your mind.
New and Shiny
I may be going out on a limb here but here goes…Architects and developers sometimes let new technologies, frameworks, and tools influence our design choices, not because they are the best solution to the problem, but because they are new and shiny. I would even go as far as saying that we feel a tinge of guilt and embarrassment if we don’t use new technologies because we feel like we are falling behind. I am just as guilty of this as the next architect and I openly and frankly admit it. But in our defense, how can we resist the new and shiny ? After all these things are new and shiny aren’t it?
Software architects and developers are typically early adopters of technology. As a group we tend to be very open to trying out new gadgets and software applications that provide technological solutions to many of lifes challenges. But in the realm of solution architecture we must temper this natural inclination because sometimes the newest technology is not the best solution. Now don’t get me wrong, I am not saying that we shouldn’t use new technologies and tools. For many of us, experimenting with new technologies is one of the most interesting parts of the job. What I’m saying is that when we do, we should always ask ourselves if we are solving the problem with the best solution or are we solving it with the newest solution.
Our Experience
The second and more insidious influencer is our own experience. Architects and developers sometimes let experience influence our current design choices negatively. Now I know what you are thinking; It’s our hard earned experience that makes us good architects and developers. Its our experience that helps us make the right design choices. Well, you are correct, but sometimes we rely on our experience too much. Sometimes our experience doesn’t lead us to the best solution, it leads us to solutions that have worked for us in the past but don’t necessarily apply to our current problem. It’s just human nature to solve problems with solutions that we know work. However, we must continually remind ourselves that every problem is unique. Every problem must be thoroughly evaluated and understood before a solution is chosen. We must resist the temptation to chose previous solutions as the default because they have worked for us in the past. Just like the new and shiny, we need to ask ourselves, is this the best solution, or is this the familiar solution. Sometimes the old solution is the best but our job as architects and developers is to thoroughly evaluate the problem first, before we decide if the old solution is truly the best solution.
Others Experience
The third influencer is the experience of others. Sometimes we let the experience of others influence our current design choices negatively. We look outside, rather than within, for how other people are solving problems. We sometimes even lend more credence to what others say simply because it is someone else saying it, not because the solution is better. These outside influence’s could be other architects and developers that you work with. They could be solutions posted online via blogs, vendor and tech sites. They could even be patterns or design solutions touted by experts as THE way to solve a problem. Now to be clear, I am not saying that looking outside your own experience is bad. I am not saying that we shouldn’t learn from others. I’m saying that your experience should not be discounted simply because it is your own.
As architects we need to think outside the box. It’s important to embrace the new and shiny and it’s important to leverage our experience as well as the experience of others. But its MORE important to evaluate our choices in the light of the problem we are solving. We need to question our assumptions as well as the assumptions of others. We need to question the practices that others may blindly accept as fact. We need to evaluate our choices and not blindly accept that a particular pattern or design is the only way to solve a problem. If our practice (architecture) is to continue moving forward we need to question what we understand as best practice and common knowledge. We need to continue to evolve, providing new solutions that solve the problems of today.
This article made me think about our architecture. We have a service
layer that is hosted in WCF. Our presentation layer apps use this service for
most of their business functions. I chose this design because I know we have,
and will have, other apps that need to use functionality that the services
(which are hosted in our WCF host) provide.
I set a requirement that none of our entities in our service business layer can
go out. They have to be mapped to a data contract. I struggled with this
because it adds overhead to development. The biggest is our main website could
use a lot of the same entities…but at the same time, I know the benefit and
I’m starting to see it pay off, mainly because we have another team in our
company hitting one of our services.
I could have the entities library used in the website, but that adds complexity
and with 20 developers in the code, I’m not sure what would happen to the
entities…website logic would surely find it’s way into them.
My question is, have you used this approach and if so, has it worked well or is
there a better way to handle this situation?
The design you outlined sounds correct to me. You don’t want to pass your domain entities over the wire.
But more importantly don’t second guess yourself. You are the one closest to the problem so you are also the best one to provide the solution. You are going to make mistakes and there will be developers that question and even criticize your work but that just goes with the architect territory. Just keep on doing what you are doing: designing solutions, learning, taking my courses 😉 and asking lots of questions.
Hanselman has a great post on impostor syndrome. We all second guess ourselves, even Hanselman.
http://www.hanselman.com/blog/ImAPhonyAreYou.aspx
Thanks Dan!