Skip to Content

In my function as a software architect and through my activities on SCN, I meet many different people, and sometimes they ask for advice on how they could become software architects themselves.

I could write or talk for hours about many different aspects of the question, but I’ll try to be brief. I did it again – so here are the four crucial ingredients to being a good software architect.

1. Experience

Software design is not a science, and despite many claims to the contrary, it isn’t even much of an engineering discipline yet. There are no deterministic rules or procedures for making good software, or making software well. It is still very much a craft, and some exceptional craftsmen might even reach a level of mastery that deserves the label “art”.

There are books and classes on software architecture, but those don’t teach anybody how to be good software architects. More precisely, they go only so far in making students produce software architectures that work, and they will make only few students better judges of good or bad software architectures. However, they do have great merits in that they can help establish a shared vocabulary and make it easier to discuss software architectures with others. 

Good software architects usually distill their architecture skills out of their experience as developers. As a developer gains experience, they become better and better at making higher-level design decisions, and expand the scope of their work accordingly. With each new level, the granularity of their scope changes and they govern collections of software artifacts at a higher order of magnitude:

  • The first level (Developer) might be the ability to make good decisions about the design of a small functional unit, such as a single class, report, or function group.
  • Second level (Senior Developer): designing larger functional units, such as an entire package consisting of several (independently reusable) classes, structures, reports, tables, and so on.
  • Third level (Application Architect): designing an entire application, making decisions on which frameworks to use, how to implement persistence, extensibility, configurability, and so on.
  • Fourth level (Enterprise Architect): designing and governing multiple applications, making decisions on application landscape design, and governing the interplay of forces between several applications and larger software components.
  • Fifth level (Application and/or Technology Strategist): Laying out the strategies and rules for the evolution of entire application landscapes and technology platforms.

It usually takes a few years to go through this growth process. That being said, age or years of experience aren’t necessarily reliable predictors of how far someone can have progressed.

People start at different ages: I started developing software for money at age 12 and built my first libraries of reuse components at age 11. Others start when they finish university – in Germany, this could be around the age of 25, 26.

People learn at different paces: The most gifted developer I have worked with needed about two years to learn what I had learned in six years. Similarly, after one year I felt more advanced than my senior colleagues who had ten years of SAP experience.

So there’s no point in saying that someone has to be at least 16, or 26, or 30, or 40 to reach maturity as a software architect. Each of these ages is the right age for someone. On the other hand, even though some start early and some are very fast, there are no shortcuts: It does take a significant amount of hands-on development experience to become very good at making high-level design decisions. The higher the level, the more experience is required.

2. Creativity

Making software is about making things up. We produce inventions. Good problem solving in software development combines a highly analytical (the Ancient Greek root of the word means “to break something down into its constituents”, “to decompose”) approach with a synthetic (from Ancient Greek “to put together”, “to compose”) approach.

Being creative, imaginative, inventive is something that cannot be taught to an unimaginative person. Software architects who don’t have at least a bit of an imaginative streak are rarely able to develop good judgment even in simple matters. If I were to hire a software architect today, I would probe for signs of imagination and vision in the candidate’s background:

  • fantasy role-playing games (RPG), writing fiction, engaging in story-telling
  • engineering, building, making technical inventions, developing their own computer programs
  • developing social, philosophical, or political visions, engaging in community-building

3. The Architecture Instinct

I came across the notion of “architecture instinct” in this article about architectural anti-patterns, which I highly recommend: http://sourcemaking.com/antipatterns/the-grand-old-duke-of-york

To quote from the article:

“Programming skill does not equate to skill in defining abstractions. There appear to be two distinct groups involved in software development: abstractionists and their counterparts (whom we call implementationists) Abstractionists are comfortable discussing software design concepts without delving into implementation details.

As stated, they possess the architecture instinct, the ability to define and explain good software abstractions. Implementationists, on the other hand, often require source code examples before they can grasp abstract concepts; they are not particularly adept at defining new abstractions that can be readily understood by other developers.”

4. Street Credibility

This is the reason I’m writing this blog post. This aspect is easily overlooked, or at least underestimated. If you take the first three ingredients – experience, creativity, architecture instinct – and put them together, what you have is basically the recipe for unpopular opinions. An architect equipped with these three things will

  • take the long-term perspective among people who only look until the next deadline,
  • anticipate changing or additional requirements nobody else sees,
  • warn from designs that look like the quick and easy solution to everybody else,
  • ask developers to jump through a number of hoops that may seem counter-intuitive and unnecessary to them,
  • tell experienced developers that what they’re doing works right now but it’s still wrong,
  • try to convince senior managers to spend more time and money than seems necessary and sufficient at the moment.

In other words, they will appear like a complete and utter fool right out of the loony bin, or perhaps coming straight from the ivory tower where the kind of software architects nobody listens to are educated.

What makes the situation even harder for the architect is that their role doesn’t usually give them any formal authority that would allow them to push their opinion through and force the other people on the project to follow their judgment.  Neither do they own the budget, nor are they in charge of the execution – so all a software architect can really demand is to be heard, and that their recommendations are given due consideration.

That being said, how can software architects escape their likely fate as a whining annoyance, and become highly effective, respected advisors whose recommendations the projects actually follow – even when it hurts? The answer is simple: They have to be very convincing. Being very convincing, in turn, requires a number of components.

Communicate well

Of course it’s helpful if you’re a Jedi in command of the famous Jedi mind tricks (“These are not the tables you are looking for.”), skilled in covert and conversational hypnosis, and generally a rhetorically skilled speaker. Being empathetic, understanding where person you are talking to is coming from, and being able to speak their language is part of this component which I would sum up under “communication skills”.

/wp-content/uploads/2013/01/notthedroids_170935.jpeg

Fig. 1: “These aren’t the tables you are looking for.”

Be right

It may sound silly, but you’ll only be respected by smart people if you turn out to be right at least reasonably frequently. This involves making claims and predictions that are concrete enough to be tested. You have to know what you’re talking about, and talk about what you know. (It’s also okay to go out on a limb and present opinions in an area where you don’t have solid knowledge – but then you should be honest and make the appropriate disclaimers.)

Earn your credibility

Yes, you can make an excellent impression in one meeting, but: To gain the standing and credibility that makes others rely comfortably on you in important matters takes many years. A senior enterprise architect is in a position where C-level executives and board members must sometimes bet their careers on the correctness of their judgment, and where errors can cause millions of dollars or Euros to be misspent. Getting there takes an excellent track record that is best earned over a few years, in several different positions, with extensive experience in a wide-ranging array of topics and technologies.

Part of your credibility is the respect you enjoy in various communities. If you’re a respected member of the SCN community with a track record of great contributions, perhaps even a top contributor in one or two fields, this might be beneficial to your credibility. Similarly, if you’re a respected member of the developers community at your employer and colleagues tend to seek your advice, this might persuade others to listen to you more carefully.

In summary, to build the standing you need in order to push through unpopular positions, or to bet their careers on you, you need to convince a wide base of people in your field that your word now is of actual value to them, because it was in the past.

It all boils down to: You need to provide good value to many people over years.

Summary

In order to be a good software architect, you need to provide good value to many people over years. Then they will follow your advice even if it hurts, or bet their careers on the correctness of your advice.

To report this post you need to login first.

26 Comments

You must be Logged on to comment or reply to a post.

  1. Tammy Powlas

    Wow, Thorsten Franz you “knocked it out of the park” once again.

    I would be curious to know what applications you were developing for pay at age 11.

    I liked your “street cred” assertion – and tying it all into SCN contributions. 

    I am curious as to why you didn’t discuss personality types; I have personally stayed away from architect roles as I struggle with big picture concepts.

    I am amazed at your ability to explain the progression to architect.

    Well done!

    Tammy

    (0) 
    1. Thorsten Franz Post author

      Thank you, Tammy, for your kind comment. The stuff I did for pay at age 12 – small games, very humble. Looking back, what I like best about them is their architecture, consisting of reusable components, and the approach to developing it I took back then.

      You’re right, personality types are very important here and I missed the opportunity to go into what is perhaps my favorite topic here. 🙂 I would say that architect roles are most natural to people with a Keirsey/MBTI xNTx type (iNtuitive Thinker), and perhaps the most prototypical architects are found among the INTx types (Introverted iNtuitive Thinker), but of course good architects come in many flavors and there are many examples of brilliant architects with completely different personality types.

      Thanks again,

      Thorsten

      (0) 
  2. Martin English

    Nice work again, Thorsten,

      I do have a point that you may have thought obvious, but I feel needs to be made explicitly… The progression from the First level (developer) to Fifth level (Application and/or Technology Strategist) is not a step-by-step progression. There needs to be evidence that you meet the prerequisites to being a software architect especially Street Credibility – before people will give you that responsibility. That means making the right decisions (and getting the reputation for being right) when you’re working at the first two levels, before you get offered a position or work as an Application Architect, and so on up the hierarchy.

    PS and don’t forget to be nice to the BASIS team 😀

    PPS Hope you have a happy, successful, and most of all FUN 2013 !

    (0) 
    1. Marilyn Pratt

      Great post Thorsten and very thought provoking.

      I’ll agree with Martin English here in thinking that the progression of levels isn’t always a step progression.  I also would like to hear just how you delineate and describe a systems analyst and systems architect (or is that just some older terminology?).  Back in the early ’80’s the normal progression went something like developer->senior developer->systems analyst . Found myself doing some lookups and came across this piece: http://www.krio.me/enterprise-vs-systems-architecture/

      (0) 
  3. Sascha Wenninger

    Really great work yet again Thorsten!

    Your points on creativity – manifested in the ability to think outside the box, know when to bend or break the rules, see the same problem from a different (maybe unorthodox?) perspective, etc. – rang especially true for me.

    You alluded to unimaginative people; do you think they exist, or is it possible that their creativity simply doesn’t overlap with their work? Maybe because they have not yet discovered their area of innate creativity?

    I do believe though that people who care are able to nurture their creativity over years of study of a different and more varied kind: for example by learning from architecture case studies, post-mortems, etc. (SlideShare, InfoQ, SkillsMatter, HighScalability, etc. are all great resources and I’m sure Alisdair Templeton could easily rattle off many more!).

    Maybe that should be another addition to the list: Passion. Or maybe it’s already there, woven right through your post, for without passion it’s difficult to be an effective leader, convince management to spend more time/money on some piece of the architecture or have much street cred. Doesn’t matter which of the five rungs one is on, without passion, progress is sideways in the best case.

    I’m sure there was a point there somewhere in that rant…

    Anyhow, great piece and it really resonated! 🙂

    (0) 
  4. Micky Oestreich

    Nice summary of what defines a (good) software architect (in your opinion). I have

    some questions / remarks though.

    You define several levels of experience. But often at projects, only the first two levels are really involved and the architecture part is done by them (partly or not done at all). It also depends on the ‘ size’  of the project of course, but nonetheless, I sometimes see it as a great miss.

    So when you are part of a (large) project, do you actual discuss the software architecturale ‘things’ with the developers? Like persistence, extensibility, etc.? Or do you review what was built? Or do you just lay out the big picture and leave the rest to the (senior) developer(s)?

    Should the customer deliver an architect as well? It would be a (great) benefit as well seeing that he/she knows all about the current architect. But should he/she also have some (basic) understaning of SAP in general and (ABAP) development in particular? I know you have, but what is your experience in this during projects at customer sites?

    Anyway, some really nice insights and some good reading.

    (0) 
  5. Fred Verheul

    Hi Thorsten,

    Great blog post, and good to have a solid personal roadmap for the coming x years 🙂 .

    One thing Two things you didn’t mention (at least explicitly) and which I find very important for an architect, especially as they (as you said) never own the budget, is are negotiation capabilities and the ability to influence/manipulate people (in a good sense of course 🙂 ). IMO this can compensate (partly) a lack of street credibility.

    Great piece!

    (0) 
  6. DJ Adams

    I’ve marked this post as ‘Exceptional’ and that it is. It takes great skill to describe something that is off the beaten track. It takes even more skill to analyse, discuss and distill into a concise set of paragraphs ideas that are self-evident … once explained. Your clarity of thought is second to none, my friend.

    The five levels that you describe above re-animate for me the word ‘architect’, a word which hitherto had been lost in the IT buzzword wilderness. I also like your emphasis on craft and (ultimately) art, which resonates with me.

    dj

    (0) 
  7. Jim Ward

    Thorsten,

    As is often the case when reading your writings, I was saying ‘yes, that’s right’.  Then I hit ‘Street Cred’, and it was ‘So True’.  Then it was ‘Be Right (at least frequently’, and I said Now he nailed it.

    Thanks (again) for reminding us why we work to be different (i.e. better) in our profession, even after many years.

    Jim

    (0) 
  8. Nishan D Singh

    Hi Thorsten,

    Great blog !

    As  a Functional Consultant, and when ever I end up read blog of ABAP or developer, I feel like we guy’s are so far behind ABAP and developer, it like a long way to go……

    Thanks again,

    Nishan Dev

    (0) 
  9. James Oswald

    You failed to mention that the quickest way to street credibility is pistol whipping the first person to question your authority. Do it on the first day and do it in front of everyone.

    Now all that’s left is coming up with a cool nickname. I’m thinking I’ll start calling you “The Diff-Franz”. Please send theme music submissions to my youtube channel.

    (0) 
  10. Chiara Bersano

    Thorsten, thank you for leaving a pointer to your new blog on my previous comment… indeed, I see the thinking progress, very rewarding. 🙂

    While for many a Software architect is just a techie, design is a creative experience, never an exact science. As much as software design might require a technical expertise (much like civil engineering require an understanding of static and sometimes dynamics), there is a part of the task that calls for a creative mind that cannot be squared in a box. While classes can teach the know-how, the creativity is inborn, I believe. To me, creativity is correlating different items and ideas, iterating and arriving at a final product that is fundamentally different from the starting point, where the original direction is intuitively selected – and how to read the intuition is only learnt through experience, through trial and error – as you so well describe.

    …. and yes, while being unpopular is no sure sign of being a good architect, being a good architect is often a good way to become unpopular at some point or another. Some kind of Cassandra’s complex, I guess.

    Great job, and looking forward reading you again!

    (0) 
  11. Kartik Iyengar

    Brilliant. Particularly liked “A senior enterprise architect is in a position where C-level executives and board members must sometimes bet their careers on the correctness of their judgment, and where errors can cause millions of dollars or Euros to be misspent. Getting there takes an excellent track record that is best earned over a few years, in several different positions, with extensive experience in a wide-ranging array of topics and technologies.”

    (0) 
  12. Lakshminarayanan V

    How true is this statement from the link you provided

    Experts report that only 1 in 5 software developers is able to define good abstractions On hearing this, a practicing software architect retorted, “It’s more like 1 out of 50.”

    And thanks for naming this an “art”.

    (0) 
  13. Thangadhorai Kaliyaperumal

    Wow…that is a great way to tell a complex story 🙂 . I like the “street credibility” part and especially  “try to convince senior managers to spend more time and money than seems necessary and sufficient at the moment.”. This is a tricky area where senior managers are always interested to hear the sweet options.

    Also, one important skill an architect need is “Communication”..I have seen so many times, architects turning up in middle management meetings talking alien language. If you can’t explain in simple terms, you can’t convince managers…! But i think it is convered in your creativity section…creatively..!

    (0) 
  14. Stephen Johannes

    If making a good software was an exact science, then real engineers would never cringe when the term “software engineer” is used.  I strongly agree that it is a mixture of knowledge of learning what does work and doesn’t, along with experience.   I definitely think the transitions between phases are not digital, but rather an analog curve or sometimes even quantum type uncertainity where you can be two levels at once.

    The interesting part is sometimes I think programming/development/software skills are more like musical skills.  You can attempt to teach everyone how to sing or play an instrument, but as seen in the real world, not every person will end up as the next Mozart, Louis Armstrong or Paul McCartney no matter how many lessons they take or practice.  Why should we ever think that “mastery level” technology skills don’t follow this pattern that exists in almost every othe professional area.

    That being said great article and hopefully showing off street cred in software will not devolve into “being served”.

    Take care,

    Stephen

    (0) 
  15. Robin van het Hof

    Truly amazing blog! So well written and concise, I have actually saved a copy of it in PDF and stored on my Macbook / iOS bookshelves

    If I recall correctly, the last time I had “streed credibility” probably was when I was 9 years old, and received the Star Wars Millennium Falcon spaceship as a Christmas present. This very toy made me the king of the street for at least a couple of months 🙂

    My main takeaway from your blog that I absolutely need to work on my street creds again 😉

    (0) 
  16. Phil Gleadhill

    Hi Thorsten,

    Great article and good advice for anyone wanting to succeed and progress on this career path. Some really good comments in this post as well.

    For “Street Cred” in my opinion one could substitute the words “Engagement, Influence and Collaboration”.

    In too many work places as you say, at least in my experience “IT Architects” have a tendency to see themselves as separate and somehow “above” the very people they are influencing, working with and relying on to deliver results. (The ivory tower syndrome). They deliver designs, policies, standards, diagrams, pictures like a range of “proclamations-on-high” and somehow remove themselves from any accountability for the impact such architectural commandments have when they have to be actually implemented.

    Avoiding the above by having a willingness to engage and collaborate I believe achieves always, much better results for all concerned.

    Cheers, Phil G.

    (0) 
  17. Markus Theilen

    Very great article, once again! I can only agree to all of your points and statements. A software architect without street cred is just not working. And this makes it hard to start again after changing the job. 🙂

    The situation as an architect is comparable to the folks that have to do Enterprise Architecture Management: no money, no real KPI to “prove” to do useful work and unpopular opinions. The only way out of this hell is to be useful to others. If your thinking and work saves others from epic failure, trust is starting to grow.

    Good to perfect social skills and a handsome face don’t hurt either. 🙂

    (0) 
  18. Niladri Bihari Nayak

    Dear Thorsten,

    Excellent Blog ! This blog was featured in SAP Community voice , so I am lucky to redirected here! 

    What is the career path for a SuccessFactors Consultant towards Enterprise Architect ? I am planning for TOGAF 9.1 this winter . But that would be an entry pass to start a journey only !

     

    What would you recommend ?

     

    Regards,

    Niladri

    (0) 
  19. Caroleigh Deneen

    Wow, what a great read! I also wandered here from the  Community Voice newsletter Valuable Lessons Based on Years of Experience section.

    The architecture instinct really resonates with me, because I’ve seen that abstraction mind-set at work. The difference in those that have it and those that don’t is quite remarkable — and (from my agency experience) does make a dramatic difference in how a project is approached and ultimately turns out. And to extend Tammy’s point about personality, even with earned credibility, not everyone can advocate under those types of pressure, so it’s good to address it directly.

    Jason Cao thanks for bringing this back to the surface. It’s a nice resource to refer others too, as career guidance that this relates to this is often sought in the Careers tag.

    (1) 

Leave a Reply