Christian Posta

About Christian Posta

Christian is a Principal Consultant at FuseSource specializing in developing enterprise software applications with an emphasis on software integration and messaging.

Being a better enterprise architect

Enterprise architects seem to become more and more involved in “trying out new things” or pushing down technology or implementation advice — nay dictation — without having a dog in the fight, or having to code any part of it. I’ve observed this in quite a few place, both working with the architects as a fellow architect, or as a developer. From these observations, I’ve come up with three rules for myself for being a good enterprise architect that I believe may be worthy for sharing and discussion.

#1 Gain the respect of the developers

I would like to generalize and say that developers seem to be the type of people who don’t want to put up with more bullshit than they absolutely have to. So trying the typical political maneuvering that you find in big companies to impress developers wont work. That includes salesmanship, power point presentations, etc. Those skills can be important for relaying a direction or vision, but it’s not going to impress the developers. The most tried and true way to gain their respect is to code with them. Yes, indeed. Good architects code. Bad ones pontificate. And there seem to be *way* more of the latter than the former. Coding your brilliantly “architected” solution will help gain their respect. But it also helps in another area. The second rule I follow.

#2 Realize that you cannot design a system on paper.

The source code is not the product that you’re engineering. The source code itself is the design. So when I sit in an architecture role, I remind myself that coming up with diagrams and flow visualizations is not the design. It’s a brainstorm to help develop a model in my head. But without putting that model to code, you don’t know how it will truly behave, or how the architected solution should be altered. And believe me. In almost all cases, it should be altered. In other words, there should be a feedback loop between the developers and the architects. And if you follow rule #1, you’ll be right there to observe first hand how your solution plays out in code.

#3 Don’t resume build

Don’t glom onto the latest and most shiny technology and push it onto the developers without putting it through some rigorous, real-life situations. Playing with new technology is fun. I do it all the time. But I do it outside of my day job. Sacrificing the stability of the team, the software, and the business model just because some technology seems cool and Google might hire you if you know it is not a respectable way to go about solving enterprise problems. Even if you’ve seen enough sales presentations about how this new technology is going to be such a magic bullet, resist the temptation to try to indoctrinate the rest of the team until you’ve put the new technology to real life software problems in an incubator.

I’ve been on both sides of the fence, have worked with a bunch of good developers and architects, and these are my three rules. Anyone want to add anything?

Reference: Being a better enterprise architect from our JCG partner Christian Posta at the Christian Posta Software blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

4 Responses to "Being a better enterprise architect"

  1. Hanynowsky says:

    Your article is quite accurate. Nevertheless, it’s a whole art when it comes to using new technology for the benefit of the team and projects. Nowadays, Software architects are asked to be more creative and to anticipate competition. Respecting the standards and ensuring long term stability is the core of enterprise software activity, yet don’t you believe these same developers are worth the challenge of incorporating new technology without sacrificing the stability. 

    In companies, this might be easier to achieve through dedicated cells, but in small boxes like statups, things might get ugly if the architect forces its way to innovation instead of security!

  2. springzen says:

    Great article, by the way.
    #3 is a bit more complex than it appears. Although playing with newest technology for the sake of it is a dangerous thing; the flip side is also true. Forgetting to upgrade and letting things age just because they work is perhaps far more dangerous. I would consider #3 as a split rule; Do not upgrade your resume – instead upgrade your technologies. In Java, at least, the technologies move quite fast and often times upgrades are necessary to fix certain bugs; in turn those forced upgrades create ‘classpath’ issues in an non OSGi world. I am referring to collisions caused by the upgrade where dependencies cause a ripple effect in the classpath continuum. In my opinion, once you’ve joined the open source dance, you will be forever married to upgrades – this is a fact. I would therefore rephrase the concept of upgrade to perhaps migration. Often times we read the flavor of the month article how technology X is better than technology Y – and some fall for that “Y is better syndrome” and hence perhaps this is what your article is really targeting with rule #3. Do not migrate for the sake of making your resume look good because you have handled X and Y and therefore you are now a ‘true Architect’. Do migrate to Y when Y is necessary as perhaps X was ex-ed out.

  3. juristr says:

    My absolute rule is #1. Practiced it myself and experienced just positive feedback. That way your devs will trust you as they see you’re facing the exact same hard problems they do. In the end we are all devs, aren’t we??

  4. qnaguru says:

    “If you do not talk about, do not sell, do not force developers to use Every Shiny New Technology that you have read about – then you are not an Architect.”

    Unfortunately, this is what most ppl believe.
    Use as few Technologies as possible to Solve a Problem – And you have my respect.

    Simplicity is the sign of excellence.
    Complexity of mediocrity.

Leave a Reply


6 + = eleven



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close