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.

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

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


8 − = two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
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.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books