There are a number of necessary skills for being an architect. Here's a list of four that occurred to me as I tried to piece together a coherent thought from a flurry of emails.
- Summarize.
- State A Goal.
- Know The Technology.
- Manage Your Investment In Learning.
These aren't sufficient skills. However, their necessity is what's important to jot down while I still think I understand it.
Summarize.
I think architecture is all about abstraction. You elide the useless details and keep the useful features -- particularly interface-related features. I find that some people don't do well with abstraction -- things always seem to involve a morass of details with no overall organizing principle.
Some people seem to wallow in the presence of details, as if knowing the details gives them power over the situation. They can use the presence of additional details as a trump card, derailing all conversations by throwing out yet another detail. No amount of begging seems to prevent this. A "let's just get all the details out on the table" side-bar conversation is usually fruitless. It's either impossible ("too busy") or unproductive ("I thought you wanted to talk about strategies, not details").
State A Goal.
I'm not saying it's important to have a goal. I'm saying it's important to state it. An unstated goal is not a measurable goal. It's elusive and malleable; you can't ever determine where you stand. Stating a goal can be hard for some people. In particular, the detail heads don't like a crisp goal, because it seems to steal their weapon of choice.
Once you have a goal, details can now be evaluated for relevance. Throwing out new, previously unknown details is no longer a power play, since some details aren't relevant to the stated goal. Since losing power is bad and stating a goal will reduce someone's power, it can be impossible to get a goal written down.
There are two common complaints. The first is "Everyone knows it, we don't need to waste time writing it down." This is often followed by the accusation: "You're supposed to be an expert, you should know this." This is universally false, but hard to convince people that I didn't create their organization conundrum, they did. The second complaint is that stating a goal too narrowly constrains people's thinking. Which is absurd, because with no goal to constrain thinking, solutions are impossible to find.
Know The Technology.
This is the most obvious skill. It's not first on the list because it isn't first. Many people know the technical details, but can't work abstractly or state a goal. Consequently, they never seem to actually solve any problems.
Surprisingly, some people seem blissfully ignorant of the rest of the world. Their highly-nuanced and carefully specified business requirements are rarely unique. Indeed, they're often pretty standard. The really common business problems have open source solutions. The slightly less common problems are often covered by several commercial packages.
Manage Your Investment In Learning.
This is -- to an extent -- a consequence of the previous skills. If you look at new technology from an outside-in perspective, you can get an appreciation for (1) what problem it solves, (2) how it works, (3) how it interfaces, (4) how you control it and (5) what it controls. You can then dive in to understand use cases, the logical structure, and the physical packaging for any of these areas.
This is also about the various orders of ignorance. Implementing new software always involves unknowns. If everything was known, we'd download the solution. Since we can't download a solution, there must be something unique (and unknown) about our unique problem.
Here's what frustrates me sometimes: you can't know it all. And yet, some people seem intent on trying to know it all. Rather than manage their time and learning relevant things first, they grab the first detail they can and pursue it down every twisty little rat-hole of irrelevant detail.
Learning has to be directed toward the actual problem-solving goal. If we take the time to state the goal, we can manage our learning to be sure that we actually achieve the goal. We can learn about non-viable solutions and solutions to problems we don't have. Or, we can manage our time and learn about things that are relevant to our problem.
End Of Rant.
Okay, that's off my chest now. However, I'll revise this posting as I catalog more of the confusing exchanges I have with people who don't seem able to summarize their problem, state their goal, discuss technology alternatives or manage their ignorance.