Software Architecture – 5 years later

I got several interesting comments on “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, and 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 five 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 five years as an Architect (by title and role) where I designed, led, reviewed, consulted, and whatnot 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., five 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 the software is not built 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 at the onset. Unless the project is 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 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 in a class of its own
• Enterprise architects are not software architects – After many years with a lot of debates on what software architecture is, it 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 the 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 is structured. The architect should understand the different needs of the stakeholders 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 systems that had elaborated architecture documents that 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 usually won’t write too much. In any event, the architect should know how to code and be 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 meet this criterion. If you don’t actively code you’ll 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, and 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 mentioned in one comment is an example- though many tests for regression purposes are almost a must). Algorithmic research does need to respond 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 challenges 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

Related posts:

Evolving Architectures – Part V – Leaps Evolving Architectures – Part IV – Design mechanics Evolving Architectures – Part VII – Parallel