The 10 Keys to Successful Architecting

I've been using the following "Top 10" keys to successful architecting lately - since it allows me to touch on almost every aspect of architecting - you might find it useful. Of course, there's a lot more behind each key - and if you're attending the Rational Software Conference in the UK (http://www-01.ibm.com/software/uk/itsolutions/developer/rational-software-conference-2009/) I'll be going into each of these in some detail. So ... here they are:

Successful software architects …

1. Understand end-to-end development
For example, they ... follow a repeatable process

2. Understand their role
For example, they ... understand what an architecture is
For example, they ... understand what an architect does
For example, they ... understand the benefits of architecting

3. Manage risk and manage change
For example, they ... derive their architectures iteratively

4. Communicate with stakeholders
For example, they ... document their architectures

5. Reuse assets
For example, they ... embrace different types of assets

6. Right-size their involvement
For example, they ... select relevant viewpoints

7. Influence the requirements
For example, they ... ensure tradeoffs are negotiated

8. Derive solutions from business needs
For example, they ... produce business-driven architectures

9. Refine solutions based on technology
For example, they ... realize architectures in available technology

10. Appreciate the broader context
For example, they ... align their work with the “bigger picture”

Context is Everything

I met a very nice chap today, who was introduced as "the Architect". Even his business card had "VP of Architecture" on it. I nearly fell into the trap of assuming he was an IT architect interested in all things software (and more besides). Turns out he was an enterprise architect and that IT was just one part of his remit. I'm glad I asked (and yes, we did have a good conversation once that contextual information was shared!).

I know it's obvious, but it's essential (and reasonable) to ask an "architect" what they actually do when they tell you they're an architect. I mean, there are enough different architecture-related roles out there - enterprise architect, system architect, software architect, infrastructure architect, security architect etc. etc. and if someone told you they were a "manager" you wouldn't think twice about asking them what they manage! And some "architects" really aren't - but that's a longer blog :)

And as for the title of this blog - "Eeles on Architecture" seemed to roll off the tongue better than some of the alternatives!