9 best practices for a solution & process architect

Recently, I participated in a survey where they asked: what are key best practices that a solution architect should remember. When I reread my answers, I found that my best practices actually also work fine for process architects.

Here they are:

1. Beware YAGNI (You are not going to use it): base your solution architecture on traceable requirements and no more

2. Mind the coupling of components: the less a component knows, the better

3. Beware TAGRI (They aren’t going to read it): travel light, document what’s necessary and translate/summarize to various stakeholder viewpoints to get buy-in (or at least understanding)
(TAGRI was defined by Scott Ambler, in a great essay: http://www.agilemodeling.com/essays/tagri.htm)

4. Business managers don’t care about SOA. They care about that customers are served, employees can do their job, cost, time to market and flexibility/agility

5. Have a clear conceptual model of the concepts that you will use (logical component, technical function, datamodel, etc) and how these concepts relate + trace back (and forward) to other artifacts

6. Talk to the system management people too – certain non-functionals (reliability, security, etc) will drive a lot of your architecture and these people need to become your friend too…

7. The sooner the people in your team start coding, the longer it’s going to take

8. Business analysts focus on the WHY and WHAT and represent demand, architects focus on the HOW (and WHY HOW) and represent supply, don’t get this mixed up

9. Focus on the complex scary stuff first, even though the simple stuff might make you seem to have a lot of progress