Skip to content

Software Architecture – 5 years later

I got several interesting comments to “Who needs an architect” (both here and on DZone). Some of them said I don’t get the architect “role”, some said I am looking at things from the code level and don’t see the forest for the trees,  others said that this whole “agile” thing is crap (admittedly not in so many words). Another one talked about the construction architect as a metaphor for software architect etc.

I started writing this post as an elaborate answer to these comments but something was bothering me. Something about the comments sounded familiar , yep you’ve got it – I wrote similar things more than 5 years ago (if you’re interested in the parallels between the presentation to the comments see below). When I originally made this presentation I had about 15 years of experience in the software industry and 5 years as an Architect (by title and role) where I designed, led, reviewed, consulted and what not quite a few software projects (including some very large scale ones).

However the point of this post is not to say “been there, done that, got the t-shirt to prove it” – Rather I’d like to point out some of my observations today, i.e.  5 years and several projects later

  • The construction architect metaphor is flawed – I guess all metaphors are flawed by definition but the construction in general and buildings in particular are quite far from software in the sense that software is soft and changing. The building metaphor serves well to demonstrate size and complexity will need different methods but software is not build it is written and it is abstract and it changes.  It is very presumptuous to think you can capture the right architecture for a project on the onset. Unless the project is either  simple enough, in which case it would probably benefit from an off-the-shelf architecture just the same. A or the project is a  well-trodden path being the nth in a series of projects. In the other cases software architecture will have to change and evolve with the project (you can read a series of posts I am writing on just that). Buildings don’t do that. That number of changing requirements that software projects need to endure is on a class of its own
  • Enterprise architects are not software architects – After many years with a lot of debates on what software architecture is seems that most definitions today are in the IEEE-1471 area. Considering this definition is about the structure of software and not the constellation of software within an enterprise and their alignment with the overall business it should be pretty obvious that enterprise architects design the enterprise rather than software. This is not to say that it isn’t an important job just that it requires some different skills (like deep understanding of the business itself and less, for example, technological depth). project/solution architects and product line architects (to an extent) are software architects
  • Architectural decisions are manifested in code and how it structured. The architect should understand  the different needs of the stakeholder and base her tradeoffs. A UML drawing as nice as it is is not an architectural decision until it is actually implemented in the system. I’ve seen a lot of system that had elaborated architecture documents which had very little resemblance to the actual architecture in the project as was manifested in the code. Architects that are far from the code are just playing with themselves
  • Architects should strive to code. Whether or not an architect will write code should only depend on the number of architects vs. the size of  the team. When there aren’t enough architects to go around an architect will usually won’t write too much. In any event, the architect should know how to code and up to date on the technologies involved. The architectural constraints posed by the technologies in use are real and the best way to understand them is to write code. Things that are suggested by the architect should be reasonably feasible if you can’t code chances are what you suggest will not meat this criterion. If you don’t actively code you’d get rusty – do the math.
  • Algorithms are not developed they are researched. You don’t have a concrete plan for the development of an algorithm you have several candidate ideas or approaches – some of them will work some won’t. This is true even if you adapt an existing algorithm. Some agile practices aren’t a good fit for this kind of “development” (TDD that was mentioned in one comment is an example- though a lot of tests for regression purposes are almost a must). Algorithmic research does need to responde to change as things you expected would work may need other approaches. Also, like the rest of the software the algorithms should match the changing business needs e.g. in xsights we started with 3G video calls and small(ish) image databases and now we focus on identification via clients and large image databases -the  chalenges are different. (It might be a good idea to do a post or two on architecture challenges in project with a lot of algorithmic components – let me know if this is interesting to you)
  • Agile shines for new development – This isn’t an architectural point, but the issue was raised in one of the comments. When you start with a new system a lot of the requirements are flaky – and so, most likely, is your understanding of the domain. Having a development methodology that embrace change is a real boon (esp. in startups :) )

  • Software architecture vs. building architecture (Gilbert comment <->slides 4-7 based on slides by Philippe Kruchten)
  • Software architecture at different levels (Sadi, Arthus <-> slides 20-24)
  • Software architecture vs. design (Jerome, Sadi, Arthur, Peter <->slide 17)
  • Coding architects and agile (peter <-> few articles in DDJ see a discussion on InfoQ)
  • etc.

* illustration : Ziggy stardust album cover

Published inBlog


  1. Good post,  in todays modern agile development environment the architect should be coding.

  2. Almost all points should be taken and the actual state of thinking. That is, there should be no one saying the contrary.Almost.1. The construction architect analogy is dated back to NATO, and was a loosely and quickly deprecated one, It may be use as a introduction for people outside of IT domain, but everybody should know now it is faulty.2. Almost agree. EA should know about SA. Software is not ONE solution, but the constelation of solutions too. A system is not made only of software.3. Architecture is not the design or the UML model. The architecture is the final structure created in code. That said, you have no architecture if all you have is a model in UML. BUT, although jumping to code will create an architecture faster, it is terrible difficult to decide and control the development if there is only the code level view.4. Coding is the description of a solution. Code may be executable or not, and may be at different levels. I code in UML, so to speak. I can create a solution at tactical level, and someone may fill in the holes by writing the ifs and fors, at the end is the same solution. Architect should be able to write code at all levels.5. Agree, when research has a business value goal.6. Agree, when agility means rationale based, structured and disciplined development, instead of chaos and heads down coding.Cheers.

  3. […] Software Architecture – 5 Years Later, by Arnon Rotem-Gal-Oz at Cirrus Minor. Arnon reminisces about how far he’s come since he began working as a software architect five years ago. […]


  • Link Roundup: June 14, 2010 « SATURN Network Blog

Leave a Reply

Your email address will not be published. Required fields are marked *