Are You Sure?

It is a pretty normal day for me when a friend says they want to accomplish something and yet they have no idea how to go about it. They want to start a business, but aren't sure what kind of business. They want to make more money, but aren't sure how. They want to get certified/learn new technology/become famous/[insert random goal here]. In all cases, they have an ambiguous idea but not a specific agenda.

A man with a watch knows what time it is. A man with two watches is never sure. -- Segal's Law

In our era of The Paradox of Choice, it is the amazing potential we all have to stand on the shoulders of giants and achieve greatness that is most often our downfall.

We have to choose every day as engineers which technologies to support, which languages to learn, which certifications to pursue. We are bombarded with choices for what social networks to participate in, which email system to rely on, and should we use an Mac or PC? Is it IPhone or Windows Mobile?

As an architect, the most valuable thing you can do is be deliberate in your choices. The hard part is being deliberate quickly. Digesting the massive amounts of ambiguity at a breathtaking pace to synthesize answers and clarity as and when they are needed, usually well before the obvious answers have become apparent. If being an architect was just about picking the obvious when it became obvious, then everyone could do it. (Which probably explains why everyone thinks they can do it.)

If you want to get out there and do something, first narrow down what that something might be. Perhaps start by writing down what it isn't. Then start writing down the attributes or identifying characteristics for what it is. If you can describe what the world looks like when you've achieved your goal, you'll be a good way towards deciding what road will get you there.

Or don't.

It's your choice.

Mirror in Motion

In the last few days I've had to spend a much larger than average percentage of time explaining how to design a system.  More specifically how to perform tasks of software architecture in a high-velocity way that is consumable by individual contributors.  Whenever I have a challenge of how to explain something complicated, I generally look for examples of how others have addressed similar opportunities.  Sometimes, what they have written mirrors aspects of my own thoughts which helps give me ideas for how to communicate my own ideas.

One such reading lately is about Microsoft Motion, which is an architecture approach being bandied about at Microsoft. I found the conclusion to be the clearest statement of the overlap with my own thinking:

This paper describes three rules for success in a partitioned-iteration strategy. They are as follows:

1. Start with the low-hanging fruit, focusing on quick time-to-value.
2. Leverage economy of small scale, focusing on agile processes.
3. Centralize interoperability and decentralize implementation, focusing on reduced complexity through partitioning, and faster iteration through agility.

You can find out more about Motion Lite on MSDN. You can also check out some podcasts on Channel 9 here and here.  And lastly the Architecture Journal has an article about it here.

Watch for some upcoming posts on other overlapping subjects from the Architecture Journal coming soon.

How I Do Design

This past week I spent some time working with some guys doing design work.  As we ping-ponged ideas and styles back and forth, I had opportunity to express my quick list of questions I ask when doing design. It turns out someone took notes so I've provided them here.  Maybe you will find them interesting...

Do I have enough information to design what I am trying to design?

1. What kinds of data?
• Hard types or not? Using classes vs. datasets or xml vs. text
• Comprehensive or not? Is the data normalized, are the options well-known and relatively static.
• Calculated or not? Does it require staging, heavy calculations, is volatile?
• What's the lifecycle? Where does it come from, where does it go? What determines the states it has?
2. What kind of process are you designing?
• Displaying information? How rich is the interface?
• Collecting information? What speed is the collection? How controlled is the interaction?
• Business Rule Processing? Where does context come from? What is the rate of change (ROC) for the rules?
• Transforming Data? Are the schemas well-defined? What is the ROC for the logic? 
• A Workflow? Does it interact with user? How complex is the state machine?
• Others – specialties? Hybrids?
3. What patterns already implement similar behavior?
• Ex: ui - > validator - > access server -> data contract
• Framework provides the patterns.
• Consume others as appropriate.
• If you can’t define it using patterns, define it using prose.
• Patterns are succinct, you only have to call out the exceptions.
4. What is unique about the behavior being implemented?
• Start with prose – write it out, follow the Design Considerations template.
• Move to formalizing your design – use patterns/practices to describe processes.
• Break it out and keep the scope of each component small and isolated.
5. What are the operational considerations?
• Security? How much or little trust? How controlled, and managed?
• Retention? Lifecycle of data and the artifacts from processing.
• Performance?
• These data points go into the Requirements Map.
6. What specific services are to be consumed?
• Using particular APIs? Controls? Schemas?
  
• Whatever specifics you know (typically filled in detailed design)
• If you know it, put it in the Design Considerations document

 These were just my off-the-top list, so keep the flames low, eh?