On software architecture and software architects

Introducing the Big Gorilla

While working at Sun I had the pleasure to work within the Sun Java Center organization (the link points now to Sun's IT Consulting Services).

I say it was a pleasure to work with them because that was a great group of about 300 individuals. Among them you could find John Crupi, Deepak Alur and Dan Malks (authors of "Core J2EE Patterns", now at JackBe), Wilfred Springer (now at TomTom), Cindy Mitchell now at ThoughtWorks and Mark Cade(author of different books on J2EE), for instance. Of course I'm missing lots of them, if you know one please let me know.

Yes, as you can suppose I was the one that was learning from others all the time! :-D

I remember the group as being very customer-oriented, and highly focused on delivering fine J2EE applications all around the world, to all sort of customers. Managing such a bunch of geeks was, for sure, a very difficult task. This was done by Stu Stern, at the time the Vice President of Worldwide Java Consulting at Sun.

Stu founded Gorilla Logic in 2002 (there're other Sun Java Center members with weird photos there too), and he's now blogging in his Big Gorilla blog.

(He's also delivering some open source stuff, such as this flexmonkey project for testing Flex applications.

On Software Architecture

Of course, and it could not have been otherwise, Big Gorilla is talking in his first blog entries about Software Architecture.

He summarizes the definition in the very first sentence:

An architecture is essentially a set of design constraints imposed on an IT development project.

Of course there're tons of definitions everywhere, but I do like that one. It's really perfect.

Many people find that definition confusing, as the term "set of design constraints" may sound too vague, so let me enumerate some of those "design constraints", by grouping them in turn in different categories:

  • Systemic constraints These include most of the -ilities you can think of when building a system, such as security, high availability, scalability, performance, usability, ease of deployment, maintainability etc. You can categorize these in different groups as well (I may do that later on).

  • Customer (and user) constraints These include constraints imposed to the system by the customer (probably the user too). These include budget constraints, time to market, usability, existing environment constraints (such as interfacing to existing legacy systems or re-using existing infrastructure, such as specific browsers or applications) or even existing development team constraints (such as involving their in-house COBOL developers for the brand-new J2EE project).

With Stu's definition, and with the those categories above, let's now proceed to the next part of this (long?) blog entry:

On Software Architects

A few weeks ago there was a post at InfoQ talking about the Qualities of a Software Architect.

Of course there're lots of software architects out there (and lots of definitions out there as well). Here in Spain, for instance, someone who knows Struts and MySQL may be considered a Software Architect, for instance, even though he knows nothing about transactions, high availability nor budgets.

But let's talk about real software architects.

With Stu's definition above, and with those few categories, I can think of the following definition of a good software architect:

A good software architect is able to design and lead a development team to build the system that satisfies the maximum number of design constraints imposed on an IT development project.

I may change this definition later on, of course, but I think this fits nicely what I mean.

Note that I say "lead a development team to build". The architect is usually the bad guy that imposes constraints to the project, all through the development process and that initially selects the underlying technologies for the project.

(Of course, there're some Software Architects out there that choose technologies because they know then well, and not because they fit the solution at hand, but those are bad architects).

Now let's see some real-life examples of what I think are good architects.

Real-life Software Architects

Some quick examples of software architects you may know:

Example I: Linus Torvalds

I think Linus fits the definition quite well. He's a great leader (a benevolent dictator, or a non-belevolent dictator, you decide). He's been able to impose many design contraints to a huge development team.

Of course Linux may not be perfect (lots of people would say it would have been a better idea to build a microkernel, for instance), but the fact is that the resulting system satisfies many design constraints: Linux can run now on mobile devices, laptops and high end servers.

Example II: Jaroslav Tulach

I've just adquired Jaroslav Tulach's Practical API Design: Confessions of a Java Framework Architect, which is a whole bunch of explanations about his architectural decissions aimed to build an API that satisfies tough design constraints (such as comprehensibility, consistency, discoverability, preservation of investment and allowing API users to make simple things in an easy way). I'm just starting to read it, but it seems to me this is going to be a good read.

It's interesting to see how Jaroslav has lead the team all along NetBeans history. He describes himself as the "enfant terrible" of NetBeans because

I'm always unsatisfied with something and I make other people's job more difficult, e.g. by forcing them to write tests, design API's properly, and so on.

That's part of an architect's job, I'd say!

Even more examples

For more examples you can see this older blog entry talking about Open Source Governance.

Now, I hope you find the definition (and your very own software architect, if any) appropriate.

Happy architecting,


blog comments powered by Disqus