J.D. Meier's Blog : Frames

Arch Frame Posted to CodePlex

J.D. Meier — Thu, 25 Sep 2008 00:59:08 GMT

Today we posted our Arch Frame to CodePlex. Wednesdays are ship days (I don't ship on Fridays.) The App Arch Frame is a collection of hot spots you hit when building line of business (LOB) applications. The key to the buckets is that they organize actionable principles, patterns, and practices. They also help us overlay patterns & practices solution assets. You give feedback either in the comments here, or on the CodePlex page:

Application Architecture Frame (CodePlex)

My Related Posts

patterns & practices App Arch Guide 2.0 Project

Abstract for Application Architecture Guide 2.0

Layers and Components

Services Layer

Scenario Frames for Presentation, Business, Data and Services

patterns & practices Security Engineering

patterns & practices Performance Engineering

Key Software Trends

Architecture Frame

J.D. Meier — Mon, 22 Sep 2008 22:21:45 GMT

As part of our patterns & practices App Arch Guide 2.0 project, we've put together an arch frame. The arch frame is simply a collection of hot spots. These aren't just any hot spot though. These hot spots represent key engineering decisions, anti-patterns, and opportunities for improved designs for more effective technical architectures. This Arch Frame is part of the larger App Arch Meta Frame. Think of it as an important branch off the main tree. It serves as a lens to cut through a lot of information to get to the most meaningful and actionable guidance.

Categories
The following categories are the "hot spots" in the architecture frame:

Authentication and Authorization
Caching and State
Communication
Composition
Concurrency and Transactions
Configuration Management
Coupling and Cohesion
Data Access
Exception Management
Logging and Instrumentation
User Experience
Validation
Workflow

What you might notice about the hot spots is that they map to common cross-cutting concerns when building applications. You also might notice that the hot spots map to various patterns & practices solution assets. For example, Enterprise Library includes blocks for caching, data access, exception management, logging, validation ... etc. The categories also map to very actionable decisions where you there's relevant principles, patterns, and practices. These buckets also contain many anti-patterns. The worst anti-patterns are the "do overs." Nobody wants a "do over" architecture.

Key Engineering Decisions
This table summarizes the key engineering decisions within each hot spot:

Category	Key Engineering Decisions
Authentication and Authorization	How to store user identities. How to authenticate callers. How to authorize callers. How to flow identity across layers and tiers.
Caching and State	How to choose effective caching strategies. How to improve performance with caching. How to improve security with caching. How to improve availability with caching. How to keep the cached data up to date. How to determine when and why to use a custom cache. How to determine what data to cache. How to determine where to cache the data. How to determine the expiration policy and scavenging mechanism. How to load the cache data. How to monitor a cache. How to synchronize caches across a farm. How to determine which caching technique provides the best performance and scalability for a specific scenario and configuration. How to determine which caching technology complies with the application's requirements for security, monitoring, and management.
Communication	How to communicate between layers / tiers. How to perform asynchronous communication. How to pass sensitive data.
Composition	How do design for composition. How to design loose coupling between modules. How to handle dependencies in a loosely coupled way.
Concurrency and Transactions	How to handle concurrency between threads. How to choose between optimistic and pessimistic concurrency. How to handle distributed transactions. How to handle long running transactions. How to determine appropriate transaction isolation levels. How to determine when compensating transactions are required.
Configuration Management	How to determine which information needs to be configurable. How to determine where and how to store configuration information. How to handle sensitive information. How to handle configuration information in a farm/cluster.
Coupling and Cohesion	How to separate concerns How to structure the application. How to choose an appropriate layering strategy. How to establish boundaries.
Data Access	How to manage database connections. How to handle exceptions. How to improve performance. How to improve manageability. How to handle blobs. How to page records. How to perform transactions.
Exception Management	How to handle exceptions. How to log exceptions.
Logging and Instrumentation	How to determine which information to log. How to make the logging configurable
User Experience	How to improve task efficiency and effectiveness. How to improve responsiveness. How to improve user empowerment. How to improve look and feel.
Validation	How to determine where and how to perform validation. How to validate for length, range, format, and type. How to constrain and reject input. How to sanitize output.
Workflow	How to handle concurrency issues within a workflow How to handle task failure within a workflow How to orchestrate processes within a workflow

Key Issues
This table summarizes the key issues within each hot spot:

Category	Key Issues
Authentication and Authorization	Clear text credentials in configuration files Passing clear text credentials over the network Over-privileged accounts Long sessions Mixing personalization with authentication Reliance on a single gatekeeper Failing to lock down system resources against application identities Failing to limit database access to specified stored procedures Inadequate separation of privileges
Caching and State	Cache misses. Failure to expire items Poor cache design Lack of a cache synchronization mechanism for scaling out.
Communication	Increased network traffic and latency due to chatty calls between layers. Inappropriate transport protocols and wire formats. Large data volumes over limited bandwidth networks.
Composition	Tightly coupled modules Duplication of code
Concurrency and Transactions	Blocking calls Nongranular locks Misuing threads Holding onto locks longer than necessary Inappropriate isolation levels
Configuration Management	Insecure administration interfaces Insecure configuration stores Clear text configuration data Too many administrators Over-privileged process accounts and service accounts
Coupling and Cohesion	Limited scalability due to server and resource affinity. Mixed presentation and business logic, which limits your options for scaling out your application. Lifetime issues due to tight coupling.
Data Access	Per user authentication and authorization when not required. Chatty calls to database Intersperse of business logic
Exception Management	Leaving system / application in unstable state Revealing sensitive information to end users. Using exceptions for logic Not logging enough details about the exception.
Logging and Instrumentation	Lack of logging and instrumentation Too fine grained logging and instrumentation Not making logging and instrumentation configurable option at runtime Failure to log business critical functionality.
User Experience	Inefficient or ineffective task support. Poor responsiveness. Disempowered users.
Validation	Application-only filters for malicious input Non-validated input in the Hypertext Markup Language (HTML) output stream Non-validated input used to generate SQL queries Reliance on client-side validation Use of input file names, URLs, or user names for security decisions
Workflow	Tight coupling Inflexible processes Race and deadlock issues

Key Guidelines
This table summarizes the key guidelines within each hot spot:

Category	Key Guidelines
Authentication and Authorization	Consider single-sign on requirements. Separate public and restricted areas. Use account lockout policies for end-user accounts. Support password expiration periods. Be able to disable accounts. Do not store passwords in user stores. Require strong passwords. Do not send passwords over the wire in plaintext. Protect authentication cookies. Use multiple gatekeepers. Restrict user access to system-level resources. Consider authorization granularity.
Caching and State	Avoid caching per-user data. Avoid caching volatile data which is required by the user to be accurate and updated in real time. Cache data that does not change very frequently or is completely static. Do not cache shared expensive resources. Cache transformed data, keeping in mind the data use. Evaluate stateful versus stateless design. Consider your state store options. Minimize session data. Free session resources as soon as possible. Avoid accessing session variables from business logic.
Communication	Choose the appropriate remote communication mechanism. Design chunky interfaces. Consider how to pass data between layers. Minimize the amount of data sent across the wire. Batch work to reduce calls over the network. Reduce transitions across boundaries. Consider asynchronous communication. Consider message queuing. Consider a "fire and forget" invocation model. Cut call chains with queues and caches as much as possible. Doing so will enhance the scalability and availability of the overall solution. Push out asynchronous boundaries close to the user, service interfaces, and service agents, to isolate your service from external dependencies. If you need to expose functionality as a synchronous operation, evaluate whether you can wrap an internally asynchronous operation as described in the following discussion
Composition	Avoid using dynamic layouts that are difficult to load and maintain. Be careful with dependencies between components. Use abstraction patterns when possible to avoid issues with maintainability. Consider creating templates with placeholders. For example use the Template View pattern to compose dynamic web pages to ensure reuse and consistency. Consider composing views from reusable modular parts. For example use the Composite View pattern to build a view from modular, atomic component parts. Use well-known design patterns to implement a composite interface containing separate modules or user controls where appropriate. Modules should not directly reference one another or the application that loaded them. Modules should use services to communicate with the application or with other modules. Modules should not be responsible for managing their dependencies. Modules should support being added and removed from the system in a pluggable fashion.
Concurrency and Transactions	Treat threads as a shared resource. Pool shared or scarce resources. Acquire late, release early. Consider efficient object creation and destruction. Consider resource throttling. Reduce contention by minimizing lock times. Balance between coarse- and fine-grained locks. Choose an appropriate transaction isolation level. Avoid long-running atomic transactions.
Configuration Management	Protect your administration interfaces. Protect your configuration store. Maintain separate administration privileges. Use least privileged process and service accounts.
Coupling and Cohesion	Partition application functionality into logical layers. Choose the proper locality for your objects based on your reliability, performance, and scalability needs. Design for loose coupling. Design for high cohesion. Use early binding where possible. Evaluate resource affinity.
Data Access	If your application uses a single database, use the database-specific data provider. If you need to support multiple databases, you generally need to have an abstraction layer, which helps you transparently connect to the currently configured store. Consider resource throttling. Consider the identities you flow to the database. Separate read-only and transactional requests. Avoid unnecessary data returns.
Exception Management	Avoid revealing sensitive data to users. Do not use exceptions to control application flow. Use validation code to avoid unnecessary exceptions. Do not catch exceptions that you cannot handle. Be aware that rethrowing is expensive. Preserve as much diagnostic information as possible in your exception handlers.
Logging and Instrumentation	Instrument your code up front. Make your logging configurable.
User Experience	Measure effectiveness against scenarios. Improve user responsiveness where possible. Model from effective user design.
Validation	Validate for length, range, format, and type. Constrain and reject input. Sanitize output. Don’t rely on client-side validation.
Workflow	Determine management requirements. If a business user needs to manage the workflow, you’ll need a solution that provides an interface that the business user can understand. Determine how exceptions will be handled. With human workflow, you need to consider the un-deterministic nature of humans. In other words, you can’t determine when a task will be completed, or if it will be completed correctly. Use service interfaces to interact with external workflow providers. If supported, use designers and metadata to define the workflow instead of code to define the workflow.

How To Provide Feedback
We're still banging through the frame. There's some rough spots. We want to make sure we can map problems, principles, patterns, assets, and technologies to the right hot spots. We want a prioritized list over a laundry list so we're still deciding what's in and what's out. We'll add it to CodePlex shortly. You can either comment here on my blog or wait until the frame is on CodePlex, and then provide comments in the Wiki.

Additional Resources

patterns & practices App Arch Guide 2.0 Project (CodePlex)
Guidance Share Wiki (GuidanceShare.com)
ShapingSoftware Blog (ShapingSoftware.com)

My Related Posts

The Story of the Engineering Practices Frame

J.D. Meier — Tue, 16 Sep 2008 23:59:29 GMT

I shared the story of our patterns & practices Engineering Practices Frame on Shaping Software. In a nutshell, the Engineering Practices Frame is a set of categories to organize software development knowledge. The idea behind the frame is to help collect and share principles, patterns, and practices for life cycle activities and artifacts. It's meant to play well with SWEBOK, various Microsoft efforts around life cycle practices, and our customers and field in the trenches. The Engineering Practices Frame is also the foundation for our ALM Frame.

Scenario Frames for Presentation, Business, Data, and Services

J.D. Meier — Thu, 04 Sep 2008 21:20:01 GMT

As part of our App Arch Guide 2.0 project, we're creating scenario frames to organize customer problems into meaningful lists. These particular frames are an elaboration of our App Arch Meta Model. This helps scope our guidance. We also use them to test effectiveness. The value of the guidance is the value of the problems solved.

Scenario Frames on CodePlex
You can review and contribute to our scenario frames on CodePlex:

Scenario Frames Index

Presentation Layer Scenarios Frame
Heres' the key hot spots for our presentation layer frame:

Caching
Composition
Exception Management
Input
Layout
Navigation
Presentation Entities
UI Components
UI Process Components
Validation

Business Layer Scenarios Frame
Here's the key hot spots for our business layer frame:

Authentication
Authorization
Business Components
Business Entities
Caching
Concurrency and Transactions
Data Access
Exception Management
Logging
Service Interface
Validation
Workflow

Data Access Layer Scenarios Frame
Here's the key hot spots for our data access layer frame:

General
BLOB
Batching
Connections
Data Format
Exception Management
Security Considerations
Stored Procedures
SQL Commands
Validation
XML

Services Layer
Heres's the key hot spots for our services layer frame:

General
Authentication
Authorization
Communication
Exception Management
Messaging Channels
Message Construction
Message Endpoint
Message Protection
Message Routing
Message Transformation
Message Exchange Patterns
REST
SOAP
Validation

My Related Posts

App Arch Meta-Frame

J.D. Meier — Wed, 03 Sep 2008 23:55:18 GMT

As part of the App Arch Guidance project, we've created an organizing frame to help think about application architecture:

Anatomy of the App Arch Meta Frame
You can see from the figure, we have a few parts that work together:

Scenarios - You can't evaluate an architecture in a vacuum. Scenarios are the backdrop and the context.
Quality Attributes / Qualities - This is your classic set of reliability, security, performance, flexibility, maintainability ... etc.
Requirements / Constraints - These are the user, business, and technical rules that shape your architecture.
App Types - This is your overall shape. This includes Web app, Rich Client, Mobile, ... etc. While the line may blur, there's important distinctions among application types.
Architecture Styles - This includes architectural patterns such as N-tier, client-server, SOA, ... etc. You can see shifts in styles over the years such as from object-orientation to message-orientation.
Architecture Frame - These are the architectural "hot spots." This is where your key engineering decisions happen.

How We Use the Frame
We use the frame to explore and gain insight into different aspects of application architecture. App arch is a big space. We'll be using the frame to catalog and organize our various principles, patterns, practices, and assets.

Keep in mind that this is a meta-frame (so it's a frame of frames.) We'll have a collection of frames that shine the spotlight on more focused areas.

Feedback
What do you think? ...

Additional Resources

Requirements Types (ShapingSoftware.com)
Quality Attributes Frame (ShapingSoftware.com)
Architectural Styles, Patterns, and Metaphors (ShapingSoftware.com)
Architectural Patterns vs. System Metaphors (ShapingSoftware.com)

Web Services Security Frame

J.D. Meier — Wed, 04 Jun 2008 21:27:00 GMT

The key to making principles, patterns, and practices more effective is to have an organizing frame. While working on our patterns & practices WCF Security Guidance Project, we created the Web Services Security Frame for just such a purpose. We use the frame throughout the guidance to organize threats, attacks, vulnerabilities and countermeasures, as well as to organize principles, patterns, and practices.

Web Services Security Frame

Here's a snapshot of the frame (the power of the frame is that it's a durable, evolvable backdrop -- in other words, you can shape it to your own purposes.) You'll see this frame used throughout our upcoming guide. Notice that the categories serve as a pivot that we can hang other viewpoints (threats/attacks, vulnerabilities, countermeasures.)

Category	Description
Auditing and Logging	Auditing and logging refers to how security-related events are recorded, monitored, and audited.
Authentication	Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.
Authorization	Authorization is how your service provides access controls for resources and operations.
Configuration Management	Configuration management refers to how your service handles database connections, administration and other configuration settings.
Exception Management	Exception management refers to how you handle exceptions within your application, including fault contracts.
Impersonation/Delegation	Impersonation and delegation refers to how your service impersonates users and passes identity information downstream for authorization purposes.
Message Encryption	Message encryption refers to protecting a message by converting the contents to cipher-text using cryptographic methods.
Message Replay Detection	Message replay detection refers to identifying and rejecting messages that are re-submitted.
Message Signing	Message signing refers to signing a message with a digital signature using cryptographic methods, to confirm the source of the message and detect if the contents have been tampered with (i.e. authentication and integrity of the message.)
Message Validation	Message validation refers to how you verify the message payload against schema, as well as message size, content and character sets. This includes how your service filters, scrubs and rejects input and output before additional processing. Input and output includes input from clients consuming the service as well as file-system input, as well as input from network resources, such as databases. Output typically includes the return values from your service or disk / database writes among others.
Sensitive Data	Sensitive data includes data integrity and confidentiality of your user and application data that you need to protect. This includes how you protect sensitive data from being stolen from memory, from configuration files or when transmitted over the network.
Session Management	A session refers to a series of related interactions between a client and your service.

Threats / Attacks Organized By the Web Services Security Frame

Category	Threats / Attacks
Auditing and Logging	Repudiation Denial of services Disclosure of confidential information
Authentication	Network eavesdropping Brute force attacks Dictionary attacks Cookie replay attack Credential theft
Authorization	Elevation of privilege Disclosure of confidential data Data tampering Luring attacks Token stealing
Configuration Management	Unauthorized access to configuration stores Retrieval of clear text configuration secrets
Exception Management	Information disclosure Denial of service Elevation of privilege
Impersonation/Delegation	Elevation of privilege Disclosure of confidential information
Message Encryption	Stealing sensitive data. Theft of encryption keys. Man in the middle attack.
Message Replay Detection	Session replay
Message Singing	Data tampering.
Message Validation	XPath injection XML Bombs Canonicalization issues Cross-site scripting SQL injection
Sensitive Data	Memory dumping Network eavesdropping Configuration file sniffing
Session Management	Session hijacking Session replay Man in the middle attack Inability to logout successfully Cross-site request forgery Session fixation Load balancing and session affinity

Vulnerabilities Organized by the Web Services Security Frame

Category	Vulnerabilities
Auditing and Logging	Failing to audit failed logons Failing to secure log files Storing sensitive information in log files Failing to audit across application tiers Failure to throttle log files
Authentication	Using weak passwords Storing clear text credentials in configuration files Passing clear text credentials over the network Permitting prolonged session lifetime Mixing personalization with authentication Using weak authentication mechanisms (For example, using basic authentication over an untrusted network.)
Authorization	Relying on a single gatekeeper (e.g. relying on client-side validation only) Failing to lock down system resources against application identities Failing to limit database access to specified stored procedures Using inadequate separation of privileges Permitting over-privileged accounts
Configuration Management	Using insecure custom administration interfaces Failing to secure configuration files on the server Storing sensitive information in the clear text Having too many administrators Using over-privileged process accounts and service accounts
Exception Management	Failing to use structured exception handling (try/catch) Revealing too much information to the client Failure to specify fault contracts with the client Failure to use a global exception handler
Impersonation / Delegation	Failure to revert to a lower privilege after using impersonation Improper use of global impersonation across the entire service
Message Encryption	Failure to encrypt messages Using custom cryptography Distributing keys insecurely Managing or storing keys insecurely
Message Replay Detection	Failure to implement message replay detection feature
Message Signing	Unsigned messages that don't confirm the source Unsigned messages that don't detect tampering
Message Validation	Using non-validated input used to generate SQL queries Relying only on client-side validation Using input file names, URLs, or user names for security decisions Using application-only filters for malicious input Looking for known bad patterns of input Trusting data read from databases, file shares, and other network resources Failing to validate input from all sources including cookies, SOAP headers, SOAP parameters, databases, and network resources
Session Management	Passing session identifiers over unencrypted channels Permitting prolonged session lifetime Having insecure session state stores Placing session identifiers in query strings

Countermeasures Organized by the Web Services Security Frame

Category	Countermeasures
Auditing and Logging	Identify malicious behavior. Know your baseline (know what good traffic looks like) Use application instrumentation to expose behavior that can be monitored Throttle logging Strip sensitive data before logging
Authentication	Use strong password policies Do not store credentials in an insecure manner Use authentication mechanisms that do not require clear text credentials to be passed over the network Encrypt communication channels to secure authentication tokens Use HTTPS only with forms authentication cookies Separate anonymous from authenticated pages Using cryptographic random number generators to generate session IDs
Authorization	Use least privilege accounts. Authentication tied to authorization on the same tier Consider granularity of access Enforce separation of privileges Use multiple gatekeepers Secure system resources against system identities
Configuration Management	Use ACLs. Encrypt sensitive sections of configuration files Use secure settings for various operations of web services using configuration files
Exception Management	Use structured exception handling (by using try/catch blocks) Catch and wrap exceptions only if the operation adds value/information Do not reveal sensitive system or application information Implement a global exception handler Do not log private data such as passwords
Impersonation / Delegation	Use Using statement to automatically revert impersonation Granularly impersonate only those operations that need it
Message Encryption	Use message security or transport security to encrypt your messages Use platform-provided cryptography Use platform features for key management Periodically change your keys
Message Replay Detection	Cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache
Message Signing	verify messages have not been tampered with in transit (data integrity) verify messages originate from the expected sender (authenticity)
Message Validation	verify the message payload against schema verify the message message size, content and character sets filter, scrub and reject input and output before additional processing
Sensitive Data	Do not store secrets in software Encrypt sensitive data over the network Secure the channel Encrypt sensitive data in configuration files
Session Management	Partition site by anonymous, identified, and authenticated users Reduce session timeouts Avoid storing sensitive data in session stores Secure the channel to the session store Authenticate and authorize access to the session store

Thanks
Special thanks to Rudy Araujo and ACE Team members, Richard Lewis and John Steer for their contribution toward helping shape a better frame.

My Related Posts

Life Frame

J.D. Meier — Thu, 20 Mar 2008 19:53:00 GMT

What is your life frame? What are the key buckets in your life that you need to balance across? If you have a frame, you can balance your life through thick and through thin. If you have a life frame, you can more thoughtfully allocate your time and energy for maximum results. More importantly, when things aren't going well, you have a tool to help you spot where you are not investing enough.

Life Frame
This is a baseline of your personal portfolio of your most important assets:

Mind
Body
Emotions
Career
Financial
Relationships
Adventure

Note - if those buckets don't work for you, change them. It's a starter set.

I've been sharing this life frame with those I coach, and some colleagues and they've found it helpful, so now I'm sharing it more broadly. It's a great starting point when you're not getting what you want out of life.

Spread Your Energy and Time Across Your Buckets
Spread your energy and time across them. If your current investment's not working, turn up the dial on some. If your stuck in one area, then try turning up another. For example, if you're not getting the results you want at work, then crank up your relationships dial. Remember that with this portfolio, the sum is more than the parts. It's the net effect.

What Can Happen When You Don't Use the Frame
When I first got to Microsoft years ago, I didn't have this frame. Sure I knew about these areas of my life, but I didn't have the mental model of a portfolio. Instead, all I knew was that I would throw all my energy and hours at my career bucket. To put that in perspective, 80, 90, 100+ hours a week. The problem is I consistently got rated highly and produced results. But at what cost? Well, if you spend 100+ hours in one bucket, guess how much energy you're spending in others? Granted some buckets overlap, but I'm talking about when you really shine the spotlight on them.

Improve Your Approach Over Spend More Time
Time is a limited resources. So is your energy. Interestingly, while working on performance modeling, the light bulb went off. If I carve out a minimum for some buckets and a maximum for others, it would be a forcing function. What's the maximum I would throw at my career bucket? 60? 50? 40? Timeboxing my career bucket forced me to identify the real value of all my work and to heavily prioritize. It also forced me to find the most effective principles, patterns and practices for project management, personal productivity, running high-performance teams, ... etc. Which is better ... more time at the problem? ... or better techniques, more value, and a sustainable pace?

Set Boundaries (Minimums and Maximums)
The real lesson is that if you don't first set your boundaries, then you never really have a way to prioritize. For example, if you allocate fifty hours to your career bucket weekly, now you know how much to bite off at a time. Otherwise, you'll just work until everything's done, but there's always something more to do. Priorities, focus, and value are your friends.

As another example, I now continuously invest in my relationships bucket. For example, each week I have lunch with an old friend, and lunch with someone new. At Microsoft, and in life, it's what you know and who you know.

How To Use This
To get started, just put these categories on your whiteboard or a pad of paper. Take a look across your portfolio and figure out your current investments in time and energy. Look at your results. How well are you balancing? If you're on track, great. If not, try increasing your investment is some areas and lowering another. The goal is to improve the quality of your life. If you want to really put some focus in an area, try a 30 Day Improvement Sprint.

My Related Posts

The Change Frame

J.D. Meier — Mon, 04 Feb 2008 19:00:15 GMT

How do you improve your results? How do you consistently increase your success? Have you ever wondered why somebody's *advice* was useless for you at the time? Maybe, they were giving you ideas to change your thinking when what you really needed was better techniques. Have you ever spun your wheels and churned all your energy, only to realize later that you needed to think differently about the problem and change your approach? The first thing to figure out is where you need to change. Here's a simple frame I've been using to help colleagues understand where to change, so they play their best game.

The Change Frame
You

Thinking - do you need to change your strategies, thinking, or thought patterns?
Feeling - do you need to change how you feel?
Doing - do you need more effective techniques or take more action?

Situation

Adapt - do you need to change yourself for the situation?
Adjust - do you need to change or tailor the situation to set yourself up for success?
Avoid - do you need to avoid the situation (if it's not right for you)?

How To Use the Frame
As simple as this frame looks, it's very powerful. If somebody gives you advice and you feel a tug in your gut that it's not helpful, there's a good chance that it's not the advice itself, but it's at the wrong level. Telling you how to think about a problem won't help when you really need a technique and action for the problem. You can use this frame as a vantage point and to analyze your approach to be more effective.

Changing You
The fastest and most effective thing you can change is yourself. You should also know that changing your thinking, changes your feelings, changes your actions. If you know this, it's a powerful concept. If you don't have the energy you need to get results, then you might have to start with changing how you're thinking about it. If you're stuck in analysis paralysis, then you might just need to start taking action and tuning your results.

Changing the Situation
Some people spend too much time trying to change for the situation that's not right for them. They ultimately change, but at the expense of their strengths or passion. Another approach is to get better at figuring out up front where you can play to your strengths.

While you want to be flexible and adaptable, you also need to be self-aware. If you know your strengths and weaknesses, you can either avoid situations where you won't be successful or you can set situations up for your success. If you know your strengths and weaknesses, you can also be more deliberate about how you change for the situation and whether you are giving up your strengths.

Adapting, Adjusting or Avoiding
For example, if you are used to position authority for getting results, then you'll want to either find those situations where it works or you'll want to avoid them. If you want to be more effective across a wider range of projects, situations and roles, then you'll want to learn how to influence without authority. The key to remember is that it's not a question of can you change for the situation -- of course you can. It's really a question of should you, or is there a way to set the situation up for your success, or is another situation a better fit for you.

Scenario Frames for Team Foundation Server

J.D. Meier — Mon, 10 Sep 2007 21:52:00 GMT

Our Scenario Frames for Team Foundation Server are available on CodePlex. We have Scenario Frames for the following:

We use scenario frames for several things:

Mapping out the problem space
Performing scenario evaluations to evaluate platform, tools, and guidance
Designing products
Scoping work

The real power of a scenario frame is that's it's a shared frame of reference. Personally, because I've seen so much benefit from scenario frames time and again, I couldn't imagine doing guidance or building a product without using scenario frames.

My Related Posts

Improvement Frame

J.D. Meier — Mon, 06 Aug 2007 01:26:00 GMT

As a mentor at work, I like to checkpoint results. While I can do area-specific coaching, I tend to take a more holistic approach. For me, it's more rewarding to find ways to unleash somebody's full potential and improve their overall effectiveness at Microsoft. Aside from checking against specific goals, I use the following frame to gauge progress.

Improvement Frame

Area	Prompts
Thinking / Feeling	Do you find your work rewarding? Are you passionate about what you do? Are you spending more time feeling good? What thoughts dominate your mind now? Is your general outlook more positive or negative? Do you have more energy or less in general? Are you still worried about the same things? Are you excited about anything? Have you changed your self-talk from inner-critic to coach?
Situation	Are you spending more time working on what you enjoy? What would you rather be spending more time doing? Do you have the manager you want? Do you have the job you want? Are you moving toward or away from your career goals? If your situation was never going to change, what one skill would you need to make the most of it?
Time / Task Management	Are you driving your day or being driven? Are you spending less time on administration? Are you getting your "MUSTs" done? Are you dropping the ball on anything important? Do you have a task management system you trust? Are you avoiding using your head as a collection point? How are you avoiding biting off more than you can chew? How are you delivering incremental value?
Domain Knowledge	Have you learned new skills? Have you sharpened your key strengths? Have you reduced your key liabilities? What are you the go-to person for? What could you learn that would make your more valuable to your team?
Strategies / Approaches	What are you approaching differently than the past? How are you more resourceful? How are you finding lessons in everything you do? How are you learning from everybody that you can? How are you improving your effectiveness? How are you modeling the success of others? How are you tailoring advice to make it work for you?
Relationships	Are you managing up effectively? Are your priorities in sync with your manager's? Has your support network grown or shrunk? How are you participating in new circles of influence? How are you spending more time with people that catalyze you? How are you working more effectively with people that drain you? How are you leveraging more mentors and area specific coaches?

I've found this frame very effective for quickly finding areas that need work or to find sticking points. It's also very revealing in terms of how much dramatic change there can be. While situations or circumstances may not change much, I find that changes in strategies and approaches can have a profound impact. My take on this is that while you can't always control what's on your plate, you can control how you eat it.

Perspectives Frame

J.D. Meier — Sun, 18 Mar 2007 07:04:00 GMT

Building software involves a lot of communication. Behind this communication, lies perspectives. These perspectives often get lost somewhere between initial goals and final product, which can lead to failed software. I found that by using a simple Perspectives Frame, I improve my chances for success.

Perspectives Frame

Industry Perspective - industry constraints and standards
Business Perspective - business goals and constraints
Technical Perspective - technological requirements, technical standards and practices
User Perspective - User experiences and goals

In Practice
I could easily over-engineer it, but in meetings and hallways, this quick, memorable frame of four categories helps. OK, so it looks simple enough, but how do I use it? Here's how I use it in practice:

Understanding goals - First things first, I want to know goals and drivers from the different perspectives. Knowing which bucket they fall in, helps more than a random collection of requirements.
Understanding priorities - Which perspectives take precedence? For example, corporate line of business applications tend to optimize around industry and business at the expense of the user experience, since users don't have much choice. On the other hand, an emerging breed of social software applications, puts the user front and center. In another case, e-commerce applications have to get the user experience right, since users do have choices.
Checkpointing representation - Is my customer representing the user, business, technical or industry perspective? Do I have the different perspectives represented?
Rationalizing decisions - If I know that for a scenario, user experience take precedence, I can make more effective decisions, moving towards the goal.
Rationalizing feedback - If I know which perspective feedback is coming from, I can have a more meaningful prioritization discussion. If the team knows that for this case, the success of the user experience is key to the business success, that's a different story than if we
Choosing the right techniques and tools - Some techniques tend to be optimized for a particular perspective. That's a good thing. The trick is to know that and explicitly decide if it's the right tool. For example, performing Kano Analysis can help you identify user satisfiers and dissatisfiers. On the other hand Taguchi methods will optimize around technical perspectives.

This perspectives frame becomes even more powerful when you combine it with MUST vs. SHOULD vs. COULD and What Are You Optimizing.

Scenario Frames for Guidance

J.D. Meier — Thu, 22 Feb 2007 10:26:00 GMT

When I tackle a problem domain, I first frame out the space. To do this, I list out scenarios and sub-scenarios. I group the scenarios under categories. Sometimes categories come first, sometimes scenarios do. I call the result, a Scenario Frame.

I use Scenario Frames to evaluate platform, tools, and guidance. I also use them for product design, innovation, competitive assessments, subject matter expert reviews, arch and design reviews, and as a way to build shared understanding of a problem space.

Here's a Scenario Frame Example my team is creating to enumerate and evaluate Source Control scenarios in VSTS 2005:

What's your favorite tool for framing out problem spaces?