RSC 2010

The 2010 Rational Software Conference has now opened its call for papers. See http://www-01.ibm.com/software/rational/rsdc/.

Through the course of my career I've been the architect of software, systems, (parts of) enterprises and development environments. I'm seriously considering a paper entitled "How to Architect Anything" since the fundamental principles that underpin all (good) architecting are the same.

Enterprise Architecture (EA) and Technical Architecture (TA)

Every now again I come across something simple, yet profound. The most-recent is on Grady Booch's blog at http://www.handbookofsoftwarearchitecture.com/:

"EA attends to the architecture of a business that uses technology. TA attends to the architecture of the software-intensive systems that support the business".

This simple statement embraces several messages (such as the linkage of business and IT), but one, in particular, is worth emphasizing: "EA attends to the architecture of a business". This is a great one-liner that really crystallises the emphasis of EA as opposed to TA, especially given that enterprise architects and software architects each deal with applications, technology and data. And, yet, their focus is quite different - one is a system, the other is a business.

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!