J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Application Architecture Guide 2.0 Final Release

    • 14 Comments

    We released our final release of the patterns & practices Application Architecture Guide 2.0 on Codeplex.  It's the "Microsoft playbook for application architecture."  This is our guide to help solution architects and developers make the most of the Microsoft platform.  It's a distillation of many lessons learned.  It’s principle-based and pattern-oriented to provide a durable, evolvable backdrop for application architecture.  It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.

    Key Links

    Key Changes Since Beta 2

    • Added a foreword by Scott Guthrie.
    • Incorporated feedback from internal and external reviewers.
    • Tuned and pruned the recommendations across the entire guide.

    Architecture Meta Frame (AMF)
    The Architecture Meta Frame integrates context, application types, architecture styles, and an architecture frame to help map out the application architecture space. 

    ArchitectureMetaFrame

    The Architecture Meta Frame serves as a durable, evolvable backdrop for the guidance in the patterns & practices Application Architecture Guide 2.0.

    Key Scenarios for the Guide

    • Choose the right architecture for your application.
    • Choose the right technologies.
    • Make more effective choices for key engineering decisions.
    • Map appropriate strategies and patterns.
    • Map relevant patterns & practices solution assets.

    Key Features of the Guide

    • Canonical Application Frame.  Describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer is described in terms of its focus, function, capabilities, common design patterns and technologies.
    • Application Types.  Canonical application archetypes to illustrate common application types.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype will be mapped to the canonical app frame. They are illustrative of common app types and not comprehensive or definitive.
    • Architecture Frame.  A common set of categories for hot spots for key engineering decisions.
    • Quality Attributes.  A set of qualities/abilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
    • Principles, patterns and practices.  Using the frames as backdrops, the guide overlays relevant principles, patterns, and practices.
    • Technologies and capabilities.  A description and overview of the Microsoft application development platform and the main technologies and capabilities within it.

    Team
    Here's the team that brought you this guide:

    • Core Dev Team: J.D. Meier , Alex Homer, David Hill, Jason Taylor , Prashant Bansode , Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
    • Test Team - Rohit Sharma, Praveen Rangarajan
    • Edit Team - Dennis Rea.

    Contributors / Reviewers
    One of our themes throughout the guide was "Stand on the shoulders of giants."  We leveraged a lot of experts inside and outside of Microsoft:

    • External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan
    • Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski
  • J.D. Meier's Blog

    App Arch Meta-Frame

    • 20 Comments

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

    AppArchMetaFrame

    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

  • J.D. Meier's Blog

    How To Reference Web Services and Databases During Development

    • 2 Comments

    One technique for pointing your Web services and database references to alternate locations during development is to use a user.config file.  Although you could change your app.config references directly, using a level of indirection keeps your production settings intact while carving out just the references to your Web services and database connections.

    To use this approach, you point your app.config file to a user.config file.  You then store your user.config file with production settings in source control.  Each user changes their user.config file to point to the dev or test locations, but they don't check this in.

    In .NET 1.1, you can use the approach outlined in "Managing Dependencies" from Team Development with Visual Studio .NET and Visual SourceSafe.

    In .NET 2.0, you can use configSource to redirect from your app.config to user.config.

    Referencing Web Services from WinForms
    In a WinForms application, you would do the following:
    1.  Add a Web service reference to your WinForm.  This will add an app.config file with settings for the Web service:
            <WindowsApplication1.Properties.Settings>
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
            </WindowsApplication1.Properties.Settings>
    2.  Add an application configuration file and name it user.config
    3.  Delete all the text in user.config
    4.  Copy the relevent settings from your app.config to your user.config
            <WindowsApplication1.Properties.Settings>
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
            </WindowsApplication1.Properties.Settings>
    Important  - Your user.config file should only the settings above.
    5.  In app.config, use configSource to redirect from app.config to user.config
            <WindowsApplication1.Properties.Settings configSource="user.config">
      <!--
                <setting name="WindowsApplication1_localhost_Service" serializeAs="String">
                    <value>http://localhost:8085/WebServiceTest/Service.asmx</value>
                </setting>
      -->
            </WindowsApplication1.Properties.Settings
    IImportant - comment out the settings, since you will now be using the settings in user.config
    6.  change the "Copy to Output Directory" property of the user.config file from "Do not copy" to "Copy if newer"

    Referencing Web Services from WebForms
    In an ASP.NET application, you would do the following:
    1.  add a Web services reference.  This would create settings in Web.config
     <appSettings>
     <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
     </appSettings>
    2.  Add a new web.config file and rename it to user.config
    3.  Delete all the text in the user.config file.
    4.  copy appSettings from web.config to user.config
     <appSettings>
     <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
     </appSettings>
    Important  - Your user.config file should strictly have only the settings above.
    5.  In web.config, use configSource to redirect from app.config to user.config
     <appSettings configSource="user.config">
      <!--
      <add key="localhost.Service" value="http://localhost:8085/WebServiceTest/Service.asmx"/>
      -->
     </appSettings>
    Important - comment out the settings, since you will now be using the settings in user.config

    Referencing Database Connections from WinForms
    To reference a database from a Winform application, you would do the following:
    1.  Add an application configuration file and name it app.config
    2.  Add a reference to the configuration dll (System.Configuration)
    3.  Add an application configuration and rename it to user.config file
    4.  Add your connection string in app.config
     <?xml version="1.0" encoding="utf-8" ?>
     <configuration>
      <connectionStrings>
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
      </connectionStrings>
     </configuration>
    5.  Test your connection string
               string connectionString = ConfigurationManager.ConnectionStrings["test"].ConnectionString;
               using (SqlConnection connection = new SqlConnection(connectionString))
                {
                    connection.Open();
               }
    6.  Copy your connectionStrings from app.config to user.config
      <connectionStrings>
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
      </connectionStrings>
    Important - this should be the only text in your user.config
    7.  In app.config, redirect to user.config using configSource
     <connectionStrings configSource="user.config">
      <!--
      <add name="test" connectionString="Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes" providerName="System.Data.SqlClient" />
       -->
      </connectionStrings>
    Important - comment out the settings, since you will now be using the settings in user.config 
    8.  On your user.config file, change the "Copy to Output Directory" property from "Do not copy" to "Copy if newer"

    For more information, take a look at Explained: Managing Source Control Dependencies in Visual Studio Team.

  • J.D. Meier's Blog

    Visual Model of Cloud Computing

    • 0 Comments

    “All models are wrong, some are useful.” – George Box

    This is a simple visual model we’re using on our patterns & practices Azure Security guidance team to dialogue around cloud computing concepts. 

    VisualModelOfCloudComputing 

     

    Here are the key things to know:

    1. Characteristics are simply the three key characteristics we defined for our working definition of cloud (see Cloud Defined.)
    2. Service models includes the options Software as a  Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) models.
    3. Deployment  includes the options on-premises, off-premises, and hybrid, which is a combination of on-premises and off-premises.

    Aside from providing a simple lens for looking at cloud computing, this model also helps us find important or interesting intersections across various cloud efforts in the industry.  For example, this can help us connect the dots to  NIST’s cloud computing work.  We can find useful intersections at a model level, without getting lost in the weeds.

  • J.D. Meier's Blog

    Test-Driven Guidance

    • 8 Comments

    When I last met with Rob Caron to walk him through Guidance Explorer, one of the concepts that peaked his interest was test-cases for content.   He suggested I blog it, since it's not common practice and could benefit others.  I agreed.

    If you're an author or a reviewer, this technique may help you.  You can create explicit test-cases for the content.  Simply put, these are the "tests for success" for a given piece of content.  Here's an example of a few test cases for a guideline:

    Test Cases for Guidelines

    Title

    • Does the title clearly state the action to take?
    • Does the title start with an action word (eg. Do something, Avoid something)?

    Applies To

    • Do you list technology and version? (e.g. ASP.NET 2.0)

    What to Do

    • Do you state the action to take?
    • Do you avoid stating more than the action to take?

    Why

    • Do you provide enough information for the user to make a decision?
    • Do you state the negative consequences of not following this guideline?

    When

    • Do you state when the guideline is applicable?
    • Do you state when not to use this guideline?

    How

    • Do you state enough information to take action?
    • Do you provide explicit steps that are repeatable?

    Problem Example

    • Do you show a real world example of the problem from experience?
    • If there are variations of the problem, do you show the most common?
    • If this is an implementation guideline, do you show code?

    Solution Example

    • Does the example show the resulting solution if the problem example is fixed?
    • If this is a design guideline is the example illustrated with images and text?
    • If this is an implementation guideline is the example in code?

    Additional Resources

    • Are the links from trusted sites?
    • Are the links correct in context of the guideline?

    Related Items

    • Are the correct items linked in the context of the guideline?

    Additional Tests to Consider When Writing a Guideline

    • Does the title clearly state the action to take?
    • Does the title start with an action word (eg. Do something, Avoid something)?
    • If the item is a MUST, meaning it is prevelant and high impact, is Priority = p1?
    • If the item is a SHOULD, meaning it has less impact or is only applicable in narrower circumstances, is Priority = p2?
    • If the item is a COULD, meaning it is nice to know about but isn't highly prevelant or impactful, is Priority = p3?
    • If this item will have cascading impact on application design, is Type = Design?
    • If this item should be followed just before deployment, is concerned with configuration details or runtime behavior, is Type = Deployment?
    • If this item is still in progress or not fully reviewed, is Status = Beta?

    Benefits to Authors and Reviewers
    The test-cases serve as checkpoints that help both authors and reviewers produce more effective guidance.  While you probably implicitly ask many of these questions, making them explicit makes them a repeatable practice for yourself or others.  I've found questions to be the best encapsulation of the test because they set the right frame of mind.  If you're an author, you can start writing guidance by addressing the questions.  If you're a reviewer, you can efficiently check for the most critical pieces of information.  How much developer guidance exists that does not answer the why or when?  Too much.  As I sift through the guidance I've produced over the years, I can't believe how many times I've missed making the why or when explicit.

    I'm a fan of the test-driven approach to guidance and here's my top reasons why:

    • I can tune the guidance across a team.  As I see patterns of problems in the quality, I can weed it out by making an explicit test case.
    • I can tailor test cases based on usage scenarios.  For example, in order to use our checklist items for tooling scenarios, our problem and solution examples need to have certain traits.  I can burn this into the test cases.
    • I can bound the information.  When is it done and what does "good enough" look like?  The test case sets a bar for the information.
    • I can improve the precision and accuracy of the information.  By precision, I mean filter out everything that's not relevant.  When it comes to technical information to do my job, I'm a fan of density (lots of useful information per square inch of text).  Verbosity is for story time.

    Examples of Test Cases for Guidance
    I've posted examples of our test-cases for guidance on Channel 9.

  • J.D. Meier's Blog

    Now Available: Windows Azure Security Notes PDF

    • 1 Comments

    Windows Azure Security Notes (PDF) is a collection of our notes and learnings from exploring the cloud security space and working through Windows Azure security scenarios.   Note that this is not a guide and it’s not a Microsoft patterns & practices deliverable.  It’s simply a way to package up, hand-off, and share what we learned during the exploration stage of our patterns & practices Windows Azure Security Guidance project.

    The key things you’ll want to explore in the notes are the various application scenarios, the cloud security threats and countermeasures, and the checklist.

    Download

    Contents at a Glance
    Here is a quick look at the Windows Azure Security Notes:

    • Ch 1 - Our Cloud Security Approach
    • Ch 2 - Cloud Security Threats and Countermeasures
    • Ch 3 - Design Guidelines for Improving Cloud Security
    • Ch 4 - Choosing Web Application Security Architectures
    • Ch 5 - Web App Security Scenarios
    • Ch 6 - Choosing Web Services Security Architectures
    • Ch 7 - Web Services Security Scenarios
    • Ch 8 - Choosing Data Security Architectures
    • Ch 9 - Data Security Scenarios

    Reference

    • Security Checklist for Cloud Applications
    • Visual Threats for Web Applications
    • Visual Threats for Web Services
    • Cheat Sheet - Web Application Security Threats and Countermeasures
    • Cheat Sheet - Web Services (SOAP) Security Threats and Countermeasures
    • Cheat Sheet - Web Services (REST) Security Threats and Countermeasures
    • Cheat Sheet - Data Security Threats and Countermeasures
    • How To - Use Forms Authentication with Azure Table Storage
    • How To - Use Forms Authentication with SQL Azure
    • How To - Enable SSL with a Self-Signed Certificate on Windows Azure

    Acknowledgements
    Many thanks to the following folks for sharing their time and expertise along the way:

    • External contributors and reviewers: Adam Grocholski; Andy Eunson; Bill Collette; Christopher Seary; Jason Taylor; John Daniels; Juval Lowy; Kevin Lam; Long Le; Michael Smith; Michael Stiefel; Michele Leroux Bustamante; Norman Headlam; Rockford Lhotka; Rudolph Araujo; Sarang Kulkarni; Steven Nagy; Terrance Snyder; Will Clevenger
    • Microsoft contributors and reviewers:  Akshay Aggarwal; Alik Levin; Andreas Fuchsberger; Babur Butter; Bharat Shyam; Dave Brankin; Danny Cohen; Diego Dagum; Don Willits; Eugenio Pace; Gabriel Morgan; Jeff Mueller; John Steer; Julian Gonzalez; Mark Curphey; Mohit Srivastava; Pat Filoteo; Rahul Verma; Raul Rojas; Scott Densmore; Sesha Mani; Serena Yeoh; Sriram Krishnan; Stefan Schackow; Steve Marx; Stuart Kwan; Terri Schmidt; Tobin Titus; Varun Sharma; Vidya Vrat Agarwal; Vikram Bhambri; Yale Li
  • J.D. Meier's Blog

    ITIL Stages, Processes, and Sub-Processes

    • 0 Comments

    Here is a map of the Information Technology Infrastructure Library (ITIL) v3.   ITIL v3 is organized by ITIL stages, processes, and sub-processes.  According to Wikipedia, “ITIL describes procedures, tasks and checklists that are not organization-specific, used by an organization for establishing a minimum level of competency.”   You can find an explanation of the ITIL processes at the ITIL Wiki.

    If you’re doing any sort of IT work, it helps to know the lay of the land.  What better way to know the lay of the land of the IT landscape that to know the map of the minimum competencies that IT is supposed to perform.

    Stages and Processes
    Here is a map of the ITIL Stages and the ITIL Processes within each.

    ITIL Stage

    Processes

    Service Strategy

    • Strategy Management for IT Services
    • Service Portfolio Management
    • Demand Management
    • Financial Management for IT Services
    • Business Relationships Management

    Service Design

    • Design Coordination
    • Service Catalogue Management
    • Service Level Management
    • Risk Management
    • Capacity Management
    • Availability Management
    • IT Service Continuity Management
    • Information Security Management
    • Compliance Management
    • Architecture Management
    • Supplier Management

    Service Transition

    • Change Management
    • Change Evaluation
    • Project Management (Transition Planning and Support)
    • Application Development
    • Release and Deployment Management
    • Service Validation and Testing
    • Service Asset and Configuration Management
    • Knowledge Management

    Service Operation

    • Event Management
    • Incident Management
    • Request Fulfillment
    • Access Management
    • Problem Management
    • IT Operations Control
    • Facilities Management
    • Application Management
    • Technical Management

    Continual Service Improvement

    • Service Review
    • Process Evaluation
    • Definition of CSI Initiatives
    • Monitoring of CSI Initiatives

    Processes and Sub-Processes
    Here are the core ITIL v3 Stages:

    • Service Strategy
    • Service Design
    • Service Transition
    • Service Operation
    • Continual Service Improvement

    Here is a map of the ITIL Processes and Sub-Processes organized by ITIL v3 stages:

    Stage

    Process

    Sub-Processes

    Service Strategy

    Strategy Management for IT Services

    • ·Strategic Service Assessment
    • Service Strategy Definition
    • Service Strategy Execution
     

    Service Portfolio Management

    • Define and Analyze new or changed Services
    • Approve new or changed Services
    • Service Portfolio Review
     

    Demand Management

     
     

    Financial Management for IT Services

    • Financial Management Support
    • Financial Planning
    • Financial Analysis and Reporting
    • Service Invoicing
     

    Business Relationships Management

    • Maintain Customer Relationships
    • Identify Service Requirements
    • Sign up Customers to Standard Services
    • Customer Satisfaction Survey
    • Complaints Management

    Service Design

    Design Coordination

    • Design Coordination Support
    • Service Design Planning
    • Service Design Coordination and Monitoring
    • Technical and Organizational Service Design
    • Service Design Review and RFC Submission
     

    Service Catalogue Management

     
     

    Service Level Management

    • Maintenance of the SLM Framework
    • Identification of Service Requirements
    • Agreements Sign-Off and Service Activation
    • Service Level Monitoring and Reporting
     

    Risk Management

    • Risk Management Support
    • Business Impact and Risk Analysis
    • Assessment of Required Risk Mitigation
    • Risk Monitoring
     

    Capacity Management

    • Business Capacity Management
    • Service Capacity Management
    • Component Capacity Management
    • Capacity Management Reporting
     

    Availability Management

    • Design Services for Availability
    • Availability Testing
    • Availability Monitoring and Reporting
     

    IT Service Continuity Management

    • ITSCM Support
    • Design Services for Continuity
    • ITSCM Training and Testing
    • ITSCM Review
     

    Information Security Management

    • Design of Security Controls
    • Security Testing
    • Management of Security Incidents
    • Security Review
     

    Compliance Management

    • Compliance Register
    • Compliance Review
    • Enterprise Policies and Regulations
     

    Architecture Management

    • Application Framework
    • Change Request to Enterprise Architecture
    • Enterprise Architecture (EA)
     

    Supplier Management

    • Providing the Supplier Management Framework
    • Evaluation of new Suppliers and Contracts
    • Establishing new Suppliers and Contracts
    • Processing of Standard Orders
    • Supplier and Contract Review
    • Contract Renewal or Termination

    Service Transition

    Change Management

    • Change Management Support
    • Assessment of Change Proposals
    • RFC Logging and Review
    • Assessment and Implementation of Emergency Changes
    • Change Assessment by the Change Manager
    • Change Assessment by the CAB
    • Change Scheduling and Build Authorization
    • Change Deployment Authorization
    • Minor Change Deployment
    • Post Implementation Review and Change Closure
     

    Change Evaluation

    • Change Evaluation prior to Planning
    • Change Evaluation prior to Build
    • Change Evaluation prior to Deployment
    • Change Evaluation after Deployment
     

    Project Management (Transition Planning and Support)

    • Project Initiation
    • Project Planning and Coordination
    • Project Control
    • Project Reporting and Communication
     

    Application Development

     
     

    Release and Deployment Management

    • Release Management Support
    • Release Planning
    • Release Build
    • Release Deployment
    • Early Life Support
    • Release Closure
     

    Service Validation and Testing

    • Test Model Definition
    • Release Component Acquisition
    • Release Test
    • Service Acceptance Testing
     

    Service Asset and Configuration Management

    • Configuration Identification
    • Configuration Control
    • Configuration Verification and Audit
     

    Knowledge Management

     

    Service Operation

    Event Management

    • Maintenance of Event Monitoring Mechanisms and Rules
    • Event Filtering and 1st Level Correlation
    • 2nd Level Correlation and Response Selection
    • Event Review and Closure
     

    Incident Management

    • Incident Management Support
    • Incident Logging and Categorization
    • Immediate Incident Resolution by 1st Level Support
    • Incident Resolution by 2nd Level Support
    • Handling of Major Incidents
    • Incident Monitoring and Escalation
    • Incident Closure and Evaluation
    • Pro-Active User Information
    • Incident Management Reporting
     

    Request Fulfillment

    • Request Fulfillment Support
    • Request Logging and Categorization
    • Request Model Execution
    • Request Monitoring and Escalation
    • Request Closure and Evaluation
     

    Access Management

    • Maintenance of Catalogue of User Roles and Access Profiles
    • Processing of User Access Requests
     

    Problem Management

    • Proactive Problem Identification
    • Problem Categorization and Prioritization
    • Problem Diagnosis and Resolution
    • Problem and Error Control
    • Problem Closure and Evaluation
    • Major Problem Review
    • Problem Management Reporting
     

    IT Operations Control

     
     

    Facilities Management

     
     

    Application Management

     
     

    Technical Management

     

    Continual Service Improvement

    Service Review

     
     

    Process Evaluation

    • Process Management Support
    • Process Benchmarking
    • Process Maturity Assessment
    • Process Audit
    • Process Control and Review
     

    Definition of CSI Initiatives

     
     

    Monitoring of CSI Initiatives

     

  • J.D. Meier's Blog

    10 Big Ideas from Getting Results the Agile Way

    • 0 Comments

    Are you using Getting Results the Agile Way to get ahead?   If you know the best ways to use your time and energy, you can get exponential results.   Agile Results, the system inside of Getting Results the Agile Way, is a synthesis of proven practices for motivation, time management, and productivity.

    It’s a simple system for meaningful results.

    Agile Results is flexible, so you can adapt it to work for you, and you can adapt it to any situation.   It’s flexible by design.   Darwin taught us that nature favors the flexible, and Agile Results is all about making things happen while thriving on change.   Change is a constant, so it’s a great launching pad for a time management system and personal productivity practices.

    While the system itself is simple, the ideas powerful.   You can use them to instantly change your approach and break through barriers or limits holding you back, or wearing you down.  People that read Getting Results the Agile Way use it to get better reviews, revamp their business, do better in school, etc.  To bottom line it – they use it to get better, faster, simpler results, and make the most of what they’ve got.

    The beauty of the system is that you can use it to do anything better.  Whether you use 30 Day Improvement Sprints, Timeboxing, The Rule of Three, or Monday Vision, Daily Outcomes, Friday Reflection, there is something for everyone to help you get ahead in our ever-changing world.

    Here is my roundup of 10 big ideas from Getting Results the Agile Way:

    1. Three Wins.   

    It's easy to spend a lot of time and yet not have anything to show for it, either for yourself or others.  You can change that quickly and easily simply by getting intentional about creating wins.  One of the big ideas in Getting Results the Agile Way is the idea of focusing on Three Wins or outcomes each day, each week, each month, and each year, as a way to focus and prioritize your time, energy, and effort.

    There's no shortage of things to do.  The key is to identify your wins and go for it.   You can use Three Wins to get clarity on meaningful results.   Simply identify Three Wins for the day, the week, the month, and the year, that you want to focus on.

    You can use Three Wins to highlight what you want to make happen in the future, and to highlight what you made happen in the past.  For example, what were your three wins for last week?  What were your three wins for last month?  What were your three wins from yesterday?

    More importantly, by carving out and identifying wins you want to achieve, you get intentional about creating compelling outcomes.  When you have compelling wins that you are aiming for, they can help lift you up and “pull” you through your day because they are your personal victories.

    2. Fresh Starts.

    Get a fresh start each day, each week, each month.  To do this, you shift from "backlog burndown" to "value up."  In other words, rather than worry about what you haven't finished, instead worry about what you want to achieve with the time and energy that you actually have.

    It works by "turning the page" each day, each week, each month, each year.  For example, instead of looking at today as a burden of yesterday's unfinished business, look at today as a new chance to create value.  Your "To Do" lists and "unfinished business" are input, but should not be your burden.

    If you take this forward-looking approach, over a backward-looking approach, you can approach each day with a beginner's mind.  This Fresh Start mindset will free you up to seize new opportunities in each day, each week, each month, each year.  It will also help you build momentum to make things happen.

    One simple way to implement a Fresh Start is to write a new "To Do" list each day and each week that reflects the three wins you wan to achieve.

    3. It's Outcomes, Not Activities.

    Don’t confuse activity with results.  It’s easy to spend time on things, but not actually achieve anything.   On the other hand, If you know what you want to accomplish,  in the form of an outcome, then you can focus on that.

    When you don’t know what the outcome or goal is, it’s easy to throw hours, activities, or meetings at something, and yet not actually produce any meaningful results.  On the other hand, if you get clear on the outcome, you can find short-cuts. 

    Using outcome is a simple way to “slow down to speed up.” 

    4. It's Value, Not Volume.    

    Less is often more, if you know what the value is.   And value is in the eye of the beholder.  Enough said?

    5. Energy is Your Force Multiplier.

    You don’t get more hours in a day.  But you can change your energy.   And, if you use your best energy, you can amplify your impact in powerful ways.

    How do you change your energy?  You can draw from your mind, body, or emotions.  For example, if you connect what you do with your passion, you can find your drive from the inside out.  If you link what you do to good feelings, you can create habits that your body will want to do.   You can use your thoughts to change your feelings, and operate at a higher level.

    6. Time is a First-Class Citizen.  

    Time is a great way to prioritize.  For example, there is only so much you can do in a day.   You can use different time horizons to plot out what you’d like to achieve within the time that you actually have.

    Time is also a great foundation to build your time management upon.   That’s why the backbone of Agile Results is the Monday Vision, Daily Outcomes, Friday Reflection pattern.   The days of the week are durable.  What you do with them is up to you.   In this way, time is your foundation and platform for results.

    The most important insight though, is that time changes what's important.  That’s why “To Do” lists get stale, and you can quickly find yourself buried in a mound of irrelevant burden.   The trick is to take a fresh look, each day, each week, each month, each year to see what matters now.  You can also use this to look ahead and anticipate value.   What will matter next month or next quarter or next year?   You can use time to better understand value, and to help you make trade-offs among where to spend your time.

    7. Be the Author of Your Life.

    With Agile Results, you “write your story forward”, one day at a time, one moment at a time, one story at a time.  You do this by choosing your wins to focus on, and by focusing on the change.   The challenge is in the change, and change is where the value is.  That’s also what stories are made of.   Stories are about the change.

    For example, you don’t just “call back a customer.”  You “win a raving fan.”   The one-liner story reflect a challenge, a change, and value for you and others.

    You can use Agile Results to live your values and to drive from your life style.  The big idea here is to connect what you do, with why you do it.   When you start with your “Why”, you kindle your fire and you make things more meaningful.  

    Using stories to drive your day, week, month, and year, helps you connect your purpose and your passion, while flowing value along the way.   In this way, not only are you the director of your life, but you are the author, writing your story forward.

    8. Weekly Rhythm of Results

    In Getting Results the Agile Way, the Monday Vision, Daily Outcomes, Friday Reflection pattern is a way to structure your time management and productivity by anchoring it to the week.  The days of the week won't change anytime soon, so you can use this simple pattern to structure and plan your time management and productivity.  It’s also a great way to create a simple learning loop of continuous improvement.

    On Mondays, identify three wins you want to achieve for the week.  Each day, identify three wins you want for the day.  On Fridays, identify three things going well, and three things to improve.  Each week, you will carry forward the insights that help you tune and improve your results.

    This weekly rhythm helps you establish a simple way to flow value.  You can chunk things down into your little wins each day, and overall add up to your bigger wins for the week.   This is also a simple way to create progress, while also enjoying the benefits of continuous learning.  Because it's anchored to days of the week, it's also easier to remember the structure.  For example, if you woke up today and it was Monday, you know to identify your three wins for the week as part of Monday Vision.

    If you adopt Monday Vision, Daily Outcomes, Friday Reflection, you instantly have a way to plan your results on a daily and weekly basis.

    9. Productive Hours and Creative Hours.

    One of the most powerful ways to unleash what you’re capable of is to use your Power Hours and Creative Hours more effectively.   Throughout the week, you have periods of time where you are either more productive or more creative.  You also have hours that really are your downtime.  For example, for many people I know, 3:00 P.M. is time for their afternoon break, myself included.  I know I wont be my most productive or my most creative so I work around that, instead of fight it.

    If you pay attention during the week, you’ll start to notice that there are recurring patterns of when you are at your creative best, and when you are your most productive.    The key is to identify these times and to better leverage them.   For example, I use my Power Hours as my most productive times of the day.   I can move mountains during these times.   On the other hand,  I use my Creative Hours for creative breakthroughs, to figure out what’s next, or to innovate in some way, shape or form.   It’s some of my best “think time” while I play with ideas.

    10. Productivity is a Personal Thing.

    It takes time and experimentation to find your flow and get your groove on.  Agile Results is a flexible system for meaningful results.  It’s designed to be “stretch to fit” and easily tailored.   Rather than a rigorous system of rules, it’s a system of principles, values, and a handful of practices.  It’s also designed to be inclusive of other systems.   Most importantly, it’s designed to be easily shaped based on personal preference and style.  Whether you want to be a productive artist or a highly-productive achiever, or simply savor more of life and achieve work-life balance, Agile Results flexes for you and with you.

    The key to any system is “just enough process” so that you can adapt it as situations and circumstances change.  The other key is to be rooted in principles, so that the system overall is durable and evolvable.   The principles provide the stable part, while letting you easily adapt to change.

    Agile Results embraces Bruce Lee’s philosophy:

    “Absorb what is useful, Discard what is not, Add what is uniquely your own.”

    Agile Results is there for you.  All you have to do is grab it and run with it.   The book, Getting Results the Agile Way, is the best way to get started, and you can use Getting Started with Agile Results as a quick start guide.

    You Might Also Like

  • J.D. Meier's Blog

    patterns and practices WCF Security Guidance Now Available

    • 20 Comments

    Our patterns & practices WCF Security Guidance Project is in progress on CodePlex.  This is our first release of prescriptive guidance modules for WCF Security. 

    How Tos
    Our How Tos give you step by step instructions for performing key tasks:

    Videos
    Our videos step you visually through key guidance:

    About WCF
    Windows Communication Foundation (WCF) is a service-oriented platform for building and consuming secure, reliable, and transacted services.  It unifies the programming models for ASMX, Enterprise services and .NET Remoting.  It supports multiple protocols including named pipes, TCP, HTTP, and MSMQ.  WCF promotes loose coupling, supports interoperability, and encapsulates the latest web service standards.  With WCF, you get flexibility in choosing protocol, message encoding formats, and hosting.   For more information, see the MSDN WCF Developer Center.

    About the Project
    WCF provides a lot of options and flexibility.  The goal of our patterns & practices WCF Security Guidance Project is to find the key combinations of security practices for WCF that work for customers and share them more broadly.  At a high-level, you can think of the project in terms of these main buckets:

    • Application Scenarios - These are whiteboard solutions for common end-to-end application scenarios.
    • How Tos - These are step-by-step instructions for performing key end-to-end tasks.
    • Building Codes - These are our sets of rules and practices.  This includes Guidelines, Checklists, and Practices at a Glance.
    • Reference - This includes Explained, Cheat Sheets, and Q&A guidance.

    The plan is to incrementally share our guidance modules on CodePlex as we go, then build a guide, then port the guidance to MSDN once it's baked.

  • J.D. Meier's Blog

    Agile Results in Evernote with One Notebook

    • 4 Comments

    imageAgile Results helps you achieve “Agile for Life”, which means flow value, while you learn, and adapt to change.

    I’ve written about how to use Agile Results with Evernote before, but some of you wanted a simplified version.  In this post, I’ll share an approach with you for using Agile Results with Evernote, using just one Notebook and six simple notes.   With this approach, you’ll have all of your vision, mission, and values at a glance, your daily and weekly goals, your list of work and personal projects, and all your ideas at a glance. 

    And you can set it all up in under three minutes.

    All of the information you need to master motivation, time management, and productivity will be at your fingertips, with one place to look.

    I’ll also share some new insights that I’ve learned around dealing with lists to help you manage them more effectively.  And I’ll also share some insights on how you can get a much better performance review, and compete in today’s world more effectively by focusing on higher-value things.

    What is Agile Results

    But first, let’s take a step back and recap what Agile Results is all about.  Agile Results is a simple system for meaningful results.  It helps you do less, but achieve more by combining proven practices for motivation, productivity, and time management.   It works by helping you focus your time, energy, and skills, using a few key concepts.  The big ideas are:  1) it’s outcomes, not activities, 2) it’s value, not volume, and 3) it’s energy, not time.  (Tip – Value is the short-cut in life.  If you know what’s valued, you can target your efforts.  Here is another tip – Value is in the eye of the beholder.)

    Agile Results helps you flow value to yourself and others, while responding to change, and taking the balcony view.  It helps you thrive in change.  It helps you learn new things.  It helps you adapt to our ever-changing world, and come out on top.  It helps you win, and it helps you go for the epic wins in life.

    Agile Results is not just a personal productivity system.  It works for teams, too (I’ve used it to lead high-performing, distributed teams around the world for more than ten years.)  That said, if you want to use it as your personal time management system, it does help you get the edge.  Part of the power is that it synthesizes many principles, patterns, and practices for high-performance, down into a small set of proven practices.

    The simplicity of the system is important.  It helps you spend more time doing, and less time planning.  The simplicity also helps you adapt the system to you and to any situation.  It also makes it easy to get started with Agile Results (you can use it right now, simply write down three wins that you want to achieve today.).

    You can find out more about Agile Results (and everything you need to know about mastering personal productivity, motivation, and time management) in my book, Getting Results the Agile Way.  It’s been an Amazon best seller for Time Management (it was #1 in Germany several time, and in the U.S. it’s been in the top 5, but floats around within the top 100.)

    Now, let’s see how to use Agile Results with Evernote in a simple, but highly effective way …

    Agile Results Notebook in Evernote

    Here is a look at Agile Results in Evernote:

    image

    As you can see, it’s one Notebook called “Agile Results”, and it contains six Notes.  The six notes are:

    1. Note #1 – Firm Foundation
    2. Note #2 – Monday Vision
    3. Note #3 – Daily Wins
    4. Note #4 – Friday Reflection
    5. Note #5 – Projects
    6. Note #6 – Ideas

    I’ll walk through each Note below, but first I’ll summarize the big ideas behind the notes.  The Firm Foundation is meant to give you a quick reminder of your vision, mission, and values at a glance, as well as your strengths.   It’s a way to help you get “on path” and stay on path.

    The Monday Vision, Daily Wins, and Friday Reflection will look familiar if you know Agile Results.   This is the little weekly rhythm of results.  The beauty is that this little combo helps you flow value on a daily and weekly basis, as well as continuously adapt and improve.  On Monday, you identify the three wins you want to achieve for the week (notice that I said “win”, not “tasks.”   A task might be “call a customer”, but the win would be “win a raving fan.”   Rather than just doing tasks, you focus on value and making a difference.  This is the secret to getting better performance reviews, flowing more value, moving up in the world, and getting off the treadmill of life.)

    Daily Wins is where you list your three wins that you want to accomplish for the day, and then all of your tasks or top of mind things.  While Monday Vision helped you set three priorities for the week, your Daily Wins helps you set three priorities for your day.  By keeping these three priorities front and center, you define your success for the day.  It also helps you focus and prioritize throughout the day.  If you have to keep changing these, then you will start to notice whether you are trading up, or just getting randomized.   You will also start to notice whether the tasks you do actually support meaningful goals.  You will also get better at defining three wins for your day.

    See the pattern so far?   Identify three wins for the week and identify three wins for the day.   By having two levels of wins, you can zoom out or zoom in.  Your little wins will add up each day, and your wins for the week will help you stay on track.  As you an imagine, by the end of the month, you have created significant momentum and impact.  Oh, and by the way, you will rapidly improve your personal productivity along the way.  How? … with Friday Reflection.

    Friday Reflection is just like how it sounds.  On Fridays, you reflect.  You review your results.  To do so, you simply ask yourself, “What are three things going well?”, and “What are three things to improve?”   Both question are important.  The one helps you identify your personal habits and practices that are working.  The other helps you identify specific areas you can improve.  For example, if you are not achieving your wins, are you biting off the right things?   Are you biting off too much?  Are you trading up for things or getting randomized?  You will see patterns and opportunities for improvement.  And the beauty is that you can take what you learn and apply it next week.  And you get to practice each day.  That’s the big idea in Agile Results … little wins with continuous improvement add up to big, bold changes in work and life.

    The Projects Note is simply a list of your work projects and your personal projects.  This is an important list.  If you can’t name the things you are working on, then you really can’t prioritize.  Worse, you can’t really focus.  Even worse, you won’t be very effective at telling or selling your work to others, whether that is your manage or your team or more.  When you have a list of what’s on your plate, you instantly have the bird’s-eye view.  You can now see whether you are splitting your time across too many things, or whether too many unimportant things are getting in the way.   As a sanity check, how would you rate the value on a scale of 1-10 of each of the items on your plate, where 10 is most awesome, and 1 is the pits?  This can be a real wake up call.  If all of the things on your plate are low-value items, your next win is to get high-value things on your plate, and squeeze out the low-value stuff, with more high-value stuff. 

    The Ideas Note is actually your Backlog, from an Agile Results perspective.  I’ve found that more people tend to prefer thinking in terms of “ideas” than “backlog”, although, the reality is many people actually have a Backlog of ideas.  That said, this is Agile Results, and it’s flexible, so whatever you want to call that works for you is fine.  What’s important is getting the concept right.  In the Ideas Note, you simply list your ideas for work, and your ideas for personal projects.  By getting things out of your head and down on to “paper”, you can free up your mind to do better things, and you can better analyze your lists of ideas, when you can see it right in front of you, versus swirling around in your mind.

    The big difference between the Ideas Note and the Projects Note is that the Projects Note is a list of your active projects.  It’s stuff that’s really on your plate.  The Ideas Note, on the other hand, is your list of things that are not yet active (That’s why I often refer to it as a Backlog.)

    One thing worth calling out is that it’s a good idea to make a list for each of your projects so that you have one place to look for all the work associated with each project.  What I’m showing here is the “master” list of your projects.  An additional step would be to have a list for each project, which contains the details.  I’m focusing on this master list of projects here because it’s where many people get lost among the sea of tasks, and lose sight of their bigger map.  If you can keep clarity of what’s on your plate, then this has a ripple effect that helps you better manage your time, energy, and focus to make things happen.

    All this might seem like a lot of work, but it’s actually pretty light-weight.  These are simple lists to help you focus, prioritize, and organize your work.   Each week, you simply refresh your Monday Vision.  Each day, you refresh your three wins.  Each Friday, you refresh your three things going well, and three things to improve.   It’s a simple habit, and if you fall off, simply pick up from wherever you are.   On any given day, simply ask yourself, “What are three things I want to accomplish today?”   Getting back on track is easy, and friction-free by design.

    Now, let’s take a quick, visual tour of each of the notes to help really make things concrete …

     

    Step 1.  Firm Foundation

    In the Firm Foundation Note, I simply write down my Vision, Mission, and Values, and my key strengths that help me differentiate and flow unique value.

    image

    It’s a simple list, but it helps me stay on path, and it helps remind and inspire me in all that I do.  Whenever I get off track, I simply go back to my Firm Foundation.  The process of thinking through my vision, mission, and values, also helps me take the balcony view of my life, and helps me head in a direction, even if I don’t know the exact target.  It gets me paving a path forward with skill.

     

    Step 2. Monday Vision

    In Monday Vision, I simply list my three wins for the week.  Below that, I create some whitespace, and then I list anything else that’s top of mind or pressing for the week.  The three wins are my most important.  After that is bonus. 

    image

    It’s my minimum list that helps carve out maximum value.   One thing to note is that I keep the list very simple and flat.  Also note that when I list things beyond my three wins, I list them in alphabetical (thus, the A-Z heading.)  I do this for a few reasons.  First, it forces me to name things better, and the better I name things, the better I can manage them, or tell my boss about them, or share them with my team or whoever.  Second, it makes it very easy to see if something is on the list, or not.   This becomes increasingly important, such as those weeks where I have 50+ items on the list.   Believe it or not, 50 items is actually very easy to deal with when it’s alphabetical and you name things in simple, friendly terms.

     

    Step 3. Daily Wins

    In Daily Wins, you write down the three wins you want to achieve for today.  It’s simple, but powerful.

    image

    As you can imagine, it’s easy to create an overwhelming list.  That’s the beauty of this approach, and why I actually like paper or any application that will let me create whitespace.  What I do is I list my three wins at the top, then I list all the other top of mind things or tasks or actions in an A-Z list below that.  This helps me keep my mind free and focused, while keeping my three wins front and center throughout the day.

    Here is the other beauty of this approach … It’s easy to add three wins to any existing “To Do” list.  No matter how you already track your daily “To Do” list, you don’t have to change it.  Simply add your three wins to the top.  I wanted Agile Results to be inclusive of existing systems, and to ride on top, without getting in the way, and ideally, help you make the most of any system that you already use.  It’s a way to amplify your results and help you get more out of the time you already spend.

     

    Step 4. Friday Reflection

    In Friday Reflection, you simply list three things going well and three things to improve.

    image

    What I do is add a recurring 20 minute appointment to my calendar on Friday mornings.  I used to take 20 minutes, now it’s closer to 10 minutes or less (you get faster, better, and deeper with practice.)  

    The power is in the process.  By asking yourself what’s going well, you take the time to identify and actually acknowledge what’s working for you.  This will help you see some things to keep doing, or potentially do more of.   It is also good for your motivation and momentum.  If you don’t take the time to call out what’s going well, you will more than likely beat yourself up for all the stuff going wrong, and that’s  just a downward spiral if you don’t balance it out. 

    The best way to balance is to first get clear on what you are really doing well, and take the moment or two to really acknowledge and appreciate that.  Maybe it’s as simple as doing what you said you would do.  Maybe it’s that you did a good job of starting your day with a  focus on three wins.  Maybe it’s that you are getting better at making time to execute.  Maybe it’s that you are doing a good job of working on high-value things.  Maybe you are getting better at finishing what you start.  It can be any number of things.  It’s personal.  It’s real.  It’s your chance to shine the spot light on your best performance, and to highlight your personal victories.  Soak it up.

    When you identify things to improve, try and get specific.  For example, if you know that when you write down one of your wins, you aren’t going to even come close, then your “challenge” and “improvement opportunity” is to choose a more achievable win, and to hold yourself to that.  Then you can practice that each day when you write down your Daily Wins.

     

    Step 5. Projects

    In Projects, you simply list your work projects and your personal projects.

    image

    In the ideal scenario, you never list more than five, top level projects.  The reason is this:  you want to use the 80/20 rule for maximum impact, and minimum effort.  You can reasonably spend 20% of your time, and achieve 80% results.  What you don’t want to do is spend less than 20% of your time on a bunch of things, where all you’re doing is administration and context switching.

    Name these things in a way that make sense to you, and ideally to others in YOUR world.  For example, find a good name to refer to your favorite project so that your manager knows how to refer to it (and even better, have them help you name it so that it’s sticky.)   If you have a maximum of five meaningful projects on your plate, and they are all high-value, you are setting yourself up for success.

    Personally, I try to go for three meaningful projects at any point in time, as well as an experiment.  The experiment is my wild card and potential game changer.  It can often lead to a breakthrough for me, either in what I create, or how I create things.  It’s how I keep improving my ability to flow value to myself and others.  Innovation is the key to sustainability, both for businesses, and for us, as individuals.

    Step 6. Ideas

    Ideas is where you simply list the ideas you have for work and personal.  If there is one list that can help you stay on track, this is the list.

    image

    It helps you stay on track, because it reminds you that these are “ideas.”  They are not your active projects.  This is your dumping ground of all the cool things you hope to do, and all your neat ideas on how things can be better.    By carving out all the ideas and potential projects into a separate list, you keep your other lists, simple and focused.  Your Projects Note is clean and crisp.  It only lists your active projects.  That’s important.

    Your Ideas list is your romping ground.  Feel free to dream up big, bold ideas.  But don’t confuse your dreaming with doing.  Use your weekly wins and daily wins in your Monday Vision and Daily Wins notes to stay grounded, and to stay focused on flowing value.  This will help you keep your head in the clouds, but feet on the ground … which is a beautiful blend of strategy + execution.

    It’s important to note that I keep my Ideas list in alphabetical order, and I bubble up the top 10 items to the top, and then add whitespace to break it up from the longer list.   This bubble up the vital few, and then list everything else is an important productivity pattern.  It will help you get better at focusing on value, not volume.  It will also help you deal with information overload and overwhelm by whacking lists down to size.

    You might be asking, how come you don’t put the list in just one big priority order?  Here’s the thing I’ve found.  It’s very easy to scan a list and know the priority.  But it’s very difficult to scan a list that’s not alphabetical.  Your eyes have to go up and down, again and again, checking to see if you already have it on the list.   When you have a simple, flat list of alphabetical items, you can very quickly add or remove things, and very quickly create priority lists, and quickly pluck the high-value items from it.   This was not obvious, but I learned this in having to deal with many, many extreme lists.

    That said, Agile Results is not rigid in the approach, so if the alphabetical does not work for you, then change it to find what does.  The goal with Agile Results is to shape the system to support you in a way that brings out your best.  It’s a flexible system for results, so feel free to bend it in ways that help you make the most of what you’ve got.

    Snippet View to Show Agile Results at a Glance

    It’s worth mentioning the “Snippet View” in the latest versions of Evernote.  You can find the “Snippet View” under the “View” menu.  Here is an example of the Snippet View and how it shows all of the notes under Agile Results “at a glance.”

    image

    What I like about the “Snippet View” is how it very compactly creates a narrative that I can easily scan.  I can quickly see my vision, mission, and values, as well as my Daily Wins and Weekly Wins, and my top Projects and Ideas.

    It’s a very powerful way to put the big rocks in my life, front and center.  It’s like the big picture view, but with enough of the details that bring it to life and make it real.   It’s effectively, “elegance in action.”

    Test Drive Agile Results

    Take Agile Results for a test-drive and see for yourself, if it helps you master motivation, time management, and personal productivity.  You can try it in three different sizes:

    1. Try it for the day.   Simply write down three wins that you want to accomplish today, and see if you improve your focus, motivation, and productivity.
    2. Try it for the week.  On Monday, write down three wins for the week.  Each day, write down three wins for the day.  On Friday, write down three things going well, and three things to improve.
    3. Try it for the month.  Use the practice of 30 Day Improvement Sprints (or Monthly Improvement Sprints) from Agile Results to test-drive Agile Results.  With this approach, you simply set a theme for the month, such as “Master time management” and then each day you do something small to help you towards this goal.  You then use the Monday Vision, Daily Wins, and Friday Reflection to support you.  (Tip – Agile Results is a powerful way to change habits or adopt new ones by using 30 Day Improvement Sprints.)

    If you want to try the 30 day challenge, I have 30 Days of Getting Results, which is a free collection of thirty little lessons that you can do at your own pace.  Each lesson includes an outcome, a lesson, and exercises.   If you commit taking this, you will learn some of the most advanced practices for rapidly and radically improving your personal performance, your motivation, your time management, and your personal productivity skills.

    I love what you’re capable of when you know how to make the most of what you’ve got.   Dig in and really make some thunder with your knowledge, skills, and experience.   The world is ready for you to flourish.   Rise and shine.

    By the way, I should mention that even though I showcased how to use Agile Results in Evernote, it’s a platform agnostic time management system.  I know lots of people that use pen and paper or Outlook or One Note or you name it.   (My favorite tool of choice for a while was my whiteboard.)    I should also mention that Agile Results was originally born as a way to organize your mind so that you didn’t need any tools or applications … just your mind.   That’s why The Rule of Three was important … it was a simple way to organize the most important things, and keep them top of mind.

    Best wishes on making a difference … for yourself, for others, for the world … in your way.

    You Might Also Like

  • J.D. Meier's Blog

    The Microsoft Story

    • 2 Comments

    “The best way to predict your future is to create it.” – Peter Drucker

    What is the Microsoft story? 

    Is there more to the story, than a “lost decade”?  (BTW – if you were a developer during the time, you probably experienced some of the most intense transformations … *wild ride*, feels more like it.)

    I was listening to one of our gifted storytellers at Microsoft a while back.   Sometimes, story tellers are about making up a bunch of stuff that never happened.  In this case, this storyteller was doing the opposite.  He was putting together the bigger picture, and putting things in context, to help us fully appreciate the story of Microsoft.

    It’s always different when you know the story.  The story changes everything.  People remember stories.  When people know what you are about, and why you do what you do, you are more predictable, more understandable, more believable.

    And in the absence of a story, people make up stories.  (And fiction is often more fun than fact.)

    I took a lot of notes as the story teller worked his magic, but I had lost them.  I found them, and I may have lost some things in the translation, but I figure now is a good time to share my notes.

    The storyteller framed the Microsoft story around three key things:

    1. Who are we?
    2. What drives us?
    3. What is our unique approach?

    Story Pillar #1.  Who Are We
    Who are the people behind Microsoft?  It’s not just who you see in the news.  It’s the people you don’t see. 

    Who don’t you see?  The diverse community of several thousand employees spread over 190 countries.

    There are computer scientists, engineers, teachers, ethnographers, musicians, designers, and even rocket scientists (Ironically, I had one on my last team.)

    The beauty here is the "Breadth of Experience.”  It’s different points of view coming together to reflect the communities.  On one hand, it’s a global view.  On the other, it’s a very localized view.  For example, if you want to make something as Norwegian as possible, it helps to have a presence in Norway.

    Another beautiful thing at Microsoft is the ecosystem.   It’s about being a part of something bigger than yourself.   The power of having a diverse presence makes it possible to build out local software ecosystems, and local partner ecosystems that really know and live the culture.

    But what is is that brings everyone to the table? 

    Compelling missions … and in this case, “power to the people.”

    The Mission at Microsoft
    The mission at Microsoft, simply put is:

    Help people and businesses throughout the world realize their full potential.

    Values at Microsoft
    Values bring people together.  They are the lightening rod that binds us.  Here are the values at Microsoft:

    • Accountability
    • Big Challenges
    • Constructive Criticism (Bring it)
    • Continual Self-Improvement
    • Customer and Partner focus
    • Execution (See things through.)
    • Honesty
    • Integrity
    • Openness
    • Passion for Technology
    • Personal Excellence
    • Quality
    • Results

    Diversity is a big deal.  Check out the “diversity” vision and mission statements:

    • Diversity and Inclusion Mission - Microsoft’s global diversity and inclusion mission is to be the world’s #1 provider of innovative technology solutions that help realize the full potential of its diverse customers and partners around the world.
    • Diversity and Inclusion Vision - To be led by a globally diverse workforce that consistently delivers outstanding business results, understands the various cultural demands of a global marketplace, is passionate about technology and the promise it holds to tap human potential, and thrives in a corporate culture where inclusive behaviors are valued.

    In my experience, Microsoft is bunch of people with a passion for more from life who want to change the world.

    Story Pillar #2. What Drives Us
    Is it fame?  Is it fortune?  No.  It’s impact.

    Actually, it’s three things:

    1. Big, bold goals.
    2. A PC on every desk.
    3. Empowering everyone.

    "I'm here because I think I can change the world."

    "Even when we were small we dreamed big."

    The PC on every desktop was a moonshot.

    "Empowerment for everyone." (around the world)

    It’s not just people who can afford technology

    BUT -- it's no longer a PC on every desktop ...

    "It's devices connected to services to do what they want, when they want around the world."

    Actually, I think of this as personal computing at your finger tips -- a machine to do your dirty work so you can innovate and create more wonderful things for the world.  We now live in a world where a developer can spin up a datacenter at their fingertips and create the next best service the world has ever known.

    Story Pillar #3.  What is our unique approach?
    What makes us different

    1. Personal – People are at the center.  It’s a people-centered approach.  It’s not a one-size fits all.
    2. Partnerships – It’s an ecosystem of ecosystems.
    3. Persistence – Microsoft is a learning company.

    It’s about the ecosystems:

    1. Software ecosystem (Writing code, developing solutions)
    2. Hardware ecosystem
    3. Partner ecosystem

    There is power in persistence.  After all, if you take on big problems, you have to be persistent.  For example, take Xbox.  Nobody would connect a game device to the Internet, right?  And let’s take scalability.  Microsoft doesn’t get scalability the way  a few Oracle, Sun, or IBM does, right?

    And how ironic.   When you succeed, the focus changes.

    OK – so now you're an Enterprise company – but you don't understand the consumer.

    Ah, it smells like another learning opportunity and a chance for the power of persistence to rise and shine.

    Where are We Going?
    You’ve seen XBox SmartGlass.   You’ve seen Microsoft Surface.   You’ve seen Windows Azure.   You’ve seen Outlook.com.   You’ve seen Office 365.  You’ve seen Windows 8.  You’ve seen Kinect (But have you heard the stories of how doctors are using it?)

    Getting the user experience right is a big deal.   You don’t want big Windows on a little device -- that’s how Windows CE happened.

    You’ve seen where things are going with the user experience and the UI.  (How many people like to play with their tiles, when nobody is looking?)

    Just think “3 Screens and a Cloud” … connected to services.  At the end of the day, you can keep things really simple when you think of three screens and a cloud … little screens, medium screens, and big screens.  Screens change things, and that’s where user experience can make or break the day.

    Think “The Right Cloud for the Job” -- Public Cloud, Private Cloud, Hybrid Cloud -- It’s great to have choices.  The power of choice means you can put the processing where it makes the most sense – and that’s a timeless principle.   Choice means customers can choose the Cloud approach that works for them, not a “one-size fits all” option.

    When you have passionate people and that kind of power of the platform on your side, from the software to the ecosystem, you can’t help but to think in a Dr. Seuss way, and imagine … Oh, the Places You’ll Go.

    Now, I can’t help but to ask …

    Where do YOU want to go today?

    You have a tribe of many thousands of Softies strong on your side, with a passion for more from life, and ready to change the world with you.

  • J.D. Meier's Blog

    New Release: patterns & practices App Arch Guide 2.0 Beta 1

    • 16 Comments
    AppArchGuidev2

    Today we released our patterns & practices App Arch Guide 2.0 Beta 1.  This is our guide to help solution architects and developers make the most of the Microsoft platform.  It's a distillation of many lessons learned.  It’s principle-based and pattern-oriented to provide a durable, evolvable backdrop for application architecture.  It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.  Keep in mind it’s Beta so there’s still moving parts and we’re processing quite a bit of feedback across the guide.  Now’s the time to bang on it.

    5 Parts

    • Part I, “Fundamentals”
    • Part II, “Design”
    • Part III, “Layers”
    • Part IV, “Quality Attributes”
    • Part V, “Archetypes – Design and Patterns”

    Chapters

    • Chapter 1 - Fundamentals of Application Architecture
    • Chapter 2 - .NET Platform Overview
    • Chapter 3 - Application Archetypes
    • Chapter 4 - Deployment Patterns
    • Chapter 5 - Arch Styles
    • Chapter 6 - Quality Attributes
    • Chapter 7 - Layers and Tiers
    • Chapter 8 - Designing Your Architecture
    • Chapter 9 - Architecture and Design Guidelines
    • Chapter 10 - Designing Services
    • Chapter 11 - Communication Guidelines 
    • Chapter 12 - Presentation Layer Guidelines
    • Chapter 13 - Business Layer Guidelines
    • Chapter 14 - Data Access Layer Guidelines
    • Chapter 15 - Service Layer Guidelines
    • Chapter 16 - Performance Engineering
    • Chapter 17 - Security Engineering
    • Chapter 18 - Mobile Application
    • Chapter 19 - Office Business Application (OBA)
    • Chapter 20 - Rich Client Application
    • Chapter 21 - Rich Internet Application (RIA)
    • Chapter 22 - Service Archetype
    • Chapter 23 - SharePoint LOB Application
    • Chapter 24 - Web Application

    Key Scenarios
    The guide helps you address the following scenarios:

    • Choose the right architecture for your application.
    • Choose the right technologies
    • Make more effective choices for key engineering decisions.
    • Map appropriate strategies and patterns.
    • Map relevant patterns & practices solution assets.

    Key Features

    • Canonical app frame - describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer is described in terms of its focus, function, capabilities, common design patterns and technologies.
    • App Types.  Canonical application archetypes to illustrate common application types.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype will be mapped to the canonical app frame. They are illustrative of common app types and not comprehensive or definitive.
    • Arch Frame - a common set of categories for hot spots for key engineering decisions.
    • Quality Attributes - a set of qualities/abilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
    • Principles, patterns and practices - Using the frames as backdrops, the guide overlays relevant principles, patterns, and practices.
    • Technologies and capabilities - a description/overview of the Microsoft custom app dev platform and the main technologies and capabilities within it.

    Conceptual Framework
    At a high level, the guide is based on the following conceptual framework for application architecture:

    ArchMetaFrame2

    Reference Application Architecture
    We used the following reference application architecture as a backdrop for explaining how to design effective layers and components:

    RefAppArch

    Key Links

    Core Dev Team

    • J.D. Meier , Alex Homer, David Hill, Jason Taylor, Prashant Bansode , Lonnie Wall, Rob Boucher, Akshay Bogawat
    Contributors / Reviewers
    • Test team: Rohit Sharma, Praveen Rangarajan
    • Edit team: Dennis Rea.
    • External Contributors/Reviewers. Adwait Ullal; Andy Eunson; Christian Weyer; David Guimbellot; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; Kent Corley; Mark Baker; Paul Ballard; Norman Headlam; Ryan Plant; Sam Gentile; Udi Dahan
    • Microsoft Contributors / Reviewers. Ade Miller; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Mehran Nikoo; Michael Puleio; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Serena Yeoh; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

    My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • App Arch Guide 2.0 Overview Slides
  • Abstract for Application Architecture Guide 2.0
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Components
  • Key Software Trends
  • Cheat Sheet: patterns & practices Catalog at a Glance Posted to CodePlex
  • Cheat Sheet: patterns & practices Pattern Catalog Posted to CodePlex
  • J.D. Meier's Blog

    ASP.NET Developer Guidance Map

    • 2 Comments

    image

    If you’re an ASP.NET developer or you need to learn ASP.NET, this map is for you.   Microsoft has an extensive collection of developer guidance available in the form of Code Samples, How Tos, Videos, and Training.  The challenge is -- how do you find all of the various content collections? … and part of that challenge is knowing *exactly* where to look.  This is where the map comes in.  It helps you find your way around the online jungle and gives you short-cuts to the treasure troves of available content. 

    The ASP.NET Developer Guidance Map helps you kill two birds with one stone:

    1. It show you the key sources of ASP.NET content and where to look (“teach you how to fish”)
    2. It gives you an index of the main content collections (Code Samples, How Tos, Videos, and Training)

    You can also use the map as a model for creating your own map of developer guidance.

    Download the ASP.NET Developer Guidance Map

    Contents at a Glance

    • Introduction
    • Sources of ASP.NET Developer Guidance
    • Topics and Features Map (a “Lens” for Finding ASP.NET Content)
    • Summary Table of Topics
    • How The Map is Organized (Organizing the “Content Collections”)
    • Getting Started
    • Architecture and Design
    • Code Samples
    • How Tos
    • Videos
    • Training

    Mental Model of the Map
    The map is a simple collection of content types from multiple sources, organized by common tasks, common topics, and ASP.NET features:

    image

    Special Thanks …
    Special thanks to Joe Stagner, Paul Enfield, Rick Anderson, Scott Hanselman, Tim Teebken, and Wade Pickett for helping me find and round up our various content collections.

    Enjoy.  Share the map with a friend.

  • J.D. Meier's Blog

    Kanban: The Secret of High-Performing Teams at Microsoft

    • 4 Comments

    If you are a project manager or a program manager, or aspiring to be, one of the best project management tools you can add to your toolbox is the Kanban. In fact, if somebody were to ask me, what’s the single best way to exponentially improve project execution, I would probably say, the answer is Kanban. (Well, I might first say, get my book, Getting Results the Agile Way, and adopt Agile Results

    A Kanban is a simple project management tool. It enables you to visualize your workflow, limit your work in progress, and optimize your “cycle time” (the time it takes to complete one item.) For software development projects, this is a big deal. It helps you find bottlenecks and push quality upstream. Ultimately, you shape your process to flow more value as efficiently and effectively as possible, “just in time.” Another way to think of it is, your users “pull” value through your development chain, while you streamline your process.

    I first got introduced to Kanbans, several years ago, by one of the best and brightest in software engineering, Corey Ladas (author of Scrumban.) My introduction was a “learn by doing” exercise.

    Identify State Changes in Your Workflow

    We went to the whiteboard and Corey has me identify the main states of my project workflow. While it was iterative, and a lot of work was done in parallel, the main stages were:

    Analysis, Design, Development, Test, and Release. It looked something like this:

    image

    Identify Work Items

    Next, Corey asked me to identify the “things” or “items” that I would show on my Kanban. I had a hard time breaking things down into useful units until I used a simple test. What’s the smallest, most useful thing I could demo to users? For simplicity, let’s just say I broke things down into features and user stories. In this case, a user story was simply a persona-based scenario with a goal. In my case, I also needed some “system” stories. The bottom line was that each of these was a “chunk” of value that I would ship to users. Corey had me name some of these items and write them down on stickies. He then had me place them wherever they were currently at on my Kanban. It looked something like this:

    image

    What surprised me was that he didn’t ask me to change our team’s process. The goal was simply to reflect whatever process we were already using. The most important thing was really to identify the most meaningful state changes in our workflow, and to identify the work items that flow through it. He said the power of the Kanban is that we would tune our process over time, with real data and real results. It’s a living thing. And it’s a visual thing.

    Set Limits for Work in Progress

    The next thing Corey had me do was to set a limit for how many items should be actively in development at any given time. I struggled here at first because I was used to having a lot of work in flight. He pointed out the problem with a lot of work in flight is that there’s thrashing, and more time spent context switching than actually finishing the work. Worse, if we’re not closing things down, then we aren’t flowing value. He said, to keep it simple, as an experiment, set the limit at 3. Find out what your team can do. For example, with focus, how quickly can we close down an item? Where does the bottleneck happen? Which resources are idle? Could idle developers pair up with testers and unblock test, for example? He got me thinking.

    image

    Push Quality Upstream

    This is where the magic happened. Corey asked me to identify some of the most common issues found during Test. I rattled off a few common problems. He then asked me what I could check for before entering test. We then repeated this process a few times until we had a few simple checks before we leave Analysis, and before we leave Design, and before we leave Development.

    It sounds so simple, and it is,   But the big deal was having it all at a glance, on the whiteboard.  We could now easily get the right people at the board, having the right conversations.

    A Living Process

    The beauty is that we ended up with a unique process for our team -- built by us, built for us, and optimized by us. As a team, we could now all visualize our process. We could easily see our bottlenecks. We could easily add quality checks. We could easily add more states to our Kanban if we needed more fine-grained visibility. We basically achieved a highly-flexible, highly relevant process that struck a balance between self-organization and workflow specialization.

    Kanban for Execution Excellence

    That was the start of my Kanban adventures, long ago. In the years since, I’ve experimented with Kanbans, personal kanbans, Kanban tools, and various approaches. The Kanban has proven itself time and again for me as one of my most effective project management tools. It really is “just enough process” combined with a focus on flowing value and improving quality. It’s one of the best tools I’ve used for driving execution excellence across people and teams in an empowering and self-directed way.

    When the question is, “How do we improve our execution?” … even if Kanban is not the answer, it’s very often as good place to start. After all, if you can show somebody your Kanban with current activity, chances are you can find the bottlenecks and optimization opportunities. At the minimum, you’ll have a shared frame of reference, the visualization of your process, which is a great way to dive deeper to troubleshoot any execution issues.

    You Might Also Like

  • J.D. Meier's Blog

    Stephen Covey Speaks at Microsoft

    • 17 Comments

    Dr. Stephen Covey presented at Microsoft today.  It’s one thing to know the information; it’s another to experience the delivery live. 

    StephenCovey 

    This post is a bit longer than usual, but hey, it’s not every day that Covey is in the house.  Here are some of my highlights from today’s session.

    The Lighthouse Story
    Covey opened with a story of Captain Horatio Hornblower.  As the story goes, one night at sea, Horatio awakens to find that a ship is in his sea-lane about 20 miles away and refuses to move.  Horatio commands the other ship to move starboard, 20 degrees at once.  The other ship refuses and tells Horatio that he should move his ship starboard, 20 degrees at once.  Next, Horatio tries to pull rank and size on the other ship, stating that he’s a captain and that he’s on a large battle ship.  The other ship replies, and it turns out it’s not actually a ship, but a lighthouse.

    The take away from the story is, there are lighthouse principles.  You don’t break them.  You only break yourself against them.  Don’t break yourself against lighthouse principles.

    Values and Principles
    Covey distinguished values from principles:

    • Values drive behavior.
    • Principles drive the consequences of behavior.

    The key take aways are:

    • If you take the short cuts in life, you pay the price of confidence and trust.
    • Build your personal value system on principles.

    Personal Mission Statement
    Covey asked us whether we had personal mission statements?  Some folks raised their hands.  He then asked us how many have them written down.  A lot less kept their hands raised.  I kept my hand raised because I happen to have my personal mission statement written down.  My personal mission statement is, “To find the best way for any person to succeed in any situation.”    I tie this back at work, where I try to help customers be as effective as possible, building on the Microsoft platform.

    Family Mission Statement
    Covey then challenged the audience whether we had mission statements for our families?  That one made me think.  He then challenged, if you asked your loved ones, would they know it?  Now there’s a good test! 

    He challenged us to go home and ask, “What’s the purpose of our family?”  He warned us though, that our families will know that we’ve been seminar’ed!

    Write and Visualize to Imprint on Your Subconscious
    Covey reminded us that writing down your mission imprints it in the subconscious mind.  He added that visualizing also imprints on the sub-concsious mind. 

    The take away is that you should write and visualize your mission statements.

    Keys to a Mission Statement
    Covey put it succinctly that a good mission statement is:

    • Memorizable.
    • Short.
    • Follows the natural laws of principles.

    Why a Mission Statement
    Covey told us that the power of a mission statement is that it governs every other decision.

    Sean Covey
    Covey introduced his son, Sean Covey.  Sean wrote The 7 Habits of Highly Effective Teenagers and The 6 Most Important Decisions You Will Ever Make.   When Covey introduced Sean, he also mentioned a 49th grand-child on the way.  49 … WOW!  That’s quite the impressive team.

    Point to True North
    Covey had us close our eyes and point to true North.  When we opened our eyes, it was obvious there was little consistency.  He said he gets similar results when he asks any department, group, or team – “what’s your purpose?”

    Urgent But Not Important
    Covey asked us how many struggle with work/life balance.  Many hands went up.  He then asked us what we think is the percentage of time we spend on things that are urgent, but not important. 

    He said people often report they feel they spend 50% of their time on urgent, but not important tasks.  Why is that?  Covey stated it’s because everybody defines purpose differently.

    Office Politics and Dysfunctional Activities
    Covey asked us how much time people spend in office politics.    By office politics, he meant, reading the tea leaves, dealing with hidden agendas, fighting cross-group conflict, … etc.  The data says that 75% of people claim they spend 25% of their time on these things.  25% say that 50% of their time is spent in dysfunctional activities.  Urgency replaces important activities.

    The key take away is that people feel they spend a lot of time on dysfunctional activities.

    Six Metastasizing Cancers (Victimism)
    Covey showed us a slide that listed what he called the Six Metastasizing Cancers:

    • Criticizing
    • Complaining
    • Comparing
    • Competing
    • Contending
    • Cynicism

    The take away here is that these are ineffective behaviors and you end up acting like a victim.

    Are You Utilized to Your Full Potential
    Covey asked us whether we can use our full talent and capacity in our organization.   He then asked us whether we feel the pressure to produce more for less.   The point here was to emphasize how there’s a demand for greater results, but that we’re not necessarily utilized to our full potential.

    It’s Not Behavior, It’s Not Attitude … It’s a Bad Map
    Covey gave us a scenario where somebody gets a map of Seattle.  The problem is, the map maker made a mistake.  It’s not really a map of Seattle.  It’s a map of Oregon.  With this map, you can’t even make it out of the airport.  There isn’t one corresponding point.

    Trying harder isn’t the answer.  If you double your speed, now you’re lost twice as fast.  Thinking negatively isn’t the problem.  Covey said some people might try to use a PMA (Positive Mental Attitude.)  Well, that doesn’t help either.  Now you’re all psyched up, but really you are just happy and contented in a lost state.

    The take away here is that it’s not behavior and it’s not attitude.  It’s a bad map.

    Self-Educating
    Covey told us that we need to be self-educating.  School taught us how to learn, but we need to continue to learn.  He said we need to be willing to pay the price to be self-educating, which includes being systematic and disciplined.

    Industrial Age vs. Knowledge Worker Age
    Covey points out that 20 years ago, it was about goods and services.  Today, it’s about knowledge workers.

    - Industrial Age Knowledge Worker Age
    Overall Philosophy Kind Control Unleash Talent
    Leadership Position (Formal Authority) Choice (Moral Authority)
    Culture Boss Centered Complementary Team, Servant Leadership
    People Expense Asset
    Motivation External Internal (Inspiration)
    Management The Boss owns responsibility for results, therefore manages and motivates. The culture owns responsibility for results, therefore self manages.

     

    Expenses and Assets
    Covey asked us what we are called in spreadsheets.   He said that in spreadsheet and financial accounting, people are called expenses and cost centers, while things like microphones, tools, and machines are called assets.  He said this is left-over from the industrial age.

    Finding Your Voice
    Covey asked how do you help people find their voice?  You ask them what are they good at?  What do they love doing?  What is your greatest unique contribution?

    The key is finding a voice that meets a human need.

    Inspiration Over Jackass Theory
    The Jackass Theory refers to the carrot and the stick.  Covey asked us what kind of supervisor do you need when you have a job that you are passionate about and is using your talents and you feel you are appreciated.

    People are volunteers.  You want them to contribute their greatest, unique contribution.

    Keys to Effective Large Team
    Covey outlined the keys for effective large teams::

    • Psychologically committed.
    • Accountable to the team / everybody.
    • Culture of results.

    One person may represent the group, but accountability is to the team versus the boss.  Accountability to the team versus an individual is a knowledge worker concept.

    How To Find the Win / Win Performance Agreement
    Covey suggested an approach for finding the Win/Win for teams and organizations in terms of performance:

    1. Help them find their voice.
    2. Find out what individuals are good at and like doing and serves the needs of the business.

    When you have that, you have a win-win.  The key is to have a win/win performance agreement where it is mutually beneficial between the individual and the organization.  The individual should be able to use their full talent and passion (there voice.)

    Information is the Knowledge Worker's Disinfectant
    Covey mentioned that light is the greatest disinfectant in nature.  For the knowledge worker, it’s information.  For a knowledge worker to be effective in a team, they need information, they need the criteria for success and they need to be accountable to the group.

    The Whole Person
    According to Covey, the whole person includes four parts:

    • Body
    • Mind
    • Heart
    • Spirit

    Control-Paradigm to a Whole Person Paradigm
    Covey reminded us that today’s workforce is about directed autonomy.  You manage (things) that can’t choose.  You lead people.  People have the ability to choose.

    The key take aways are:

    • Today’s world is about breaking away from a control paradigm and shifting to one of directed autonomy.  
    • Help people find their voice.
    • You can’t buy the mind, body, heart, and spirit – they are volunteered. 
    • Use all four parts of your nature.  If you take one away, then you’re treating a person as a “thing” that you control and manage.

    Keeping Top Talent
    Covey told us about how Admirals in the Pacific were losing people to better paying jobs.  There was an exception.  Covey got to meet the group that kept their top talent.  The keys to a committed group included:

    • The culture was committed in hearts and minds.
    • The job was fulfilling and meaningful.

    Indian Talking Stick Communication
    Covey shared a technique for improving empathic listening.  It’s the Indian Talking Stick:

    • You give the stick to the other person first. 
    • You don’t get the stick back until the other person feels they are understood.
    • The purpose is not to agree, or disagree, but only to understand the speaker.

    You don’t need to use an Indian talking stick.  You can use any object.  The value of the object is that you don’t get it back until the other person feels understood.

    Industrial Age Concepts
    Throughout the session, Covey made reference to some "industrial age concepts":

    • People are an expense, tools and machines are assets.
    • Supervision is an industrial age concept.
    • One-on-one accountability to a boss.
    • Comparison systems for the basis of collaboration.

    Lighthouse Principles
    Throughout the presentation, Covey referred to some lighthouse principles that govern behavior:

    • Cultivate an abundance mentality.
    • There are four parts to our nature: body, mind, heart, and spirit
    • The whole is greater than the parts
    • Develop integrity; avoid duplicity (Don’t say one thing, but do another and if you make a promise, keep it.)

    Continuum of Communication
    Covey showed us a continuum of communication that moves from hostility and transaction-based communication to transformation:

    1. Hostility
    2. Defensive Communication (Transaction)
    3. Respectful Communication (Transaction)
    4. Synergy, Third Alternative (Transformation)

    Empathic Listening is the No. 1 Communication Skill
    Covey stated that communication is the number one skill in life.  He went on to say that empathic listening is the number one communication skill.   Covey explained that empathic listening is listening within the other person’s frame of skills.   Listening empathically is listening with the other person’s frame of reference.  The key is to listen until the other person feels heard and understood. 

    Empathic Listening Over Telling and Selling
    A satisfied need, no longer motivates.  Covey used the example of air – it’s a satisfied need.  When the other person feels heard and understood, it’s more likely they will listen to you and that you can seek a better solution, that’s mutually beneficial.  You are no longer telling and selling.

    Our Experience is the Lens We Use to Interpret Life
    Covey showed the audience three pictures.   One half of the audience looked at the first picture.  Next, the other half of the audience looked at the second picture.  Then the full audience looked at a third slide which was a composite of the first two slides.  Depending on which of the pictures you saw first, influenced what you saw in this third picture.

    The key take away here was that what you saw was influenced by your experience and that rather that impose your view, first understand the other person’s perspective – there’s a good chance, you’re both right! (This is a good case where the Indian Talking Stick could come in handy.)

    Resolving Conflict By Finding the Third Alternative
    Covey shared a technique for resolving conflict that works for him in 95% of the cases he runs into around the world.  Here’s the key steps:

    1. Put up the two points.
    2. Ask the question, “would you be willing to search for a solution that would be better than what either of us has proposed?”

    The key here is to listen to the other person first and listen empathically.  The proactive part here is that you can choose to listen to the other person first (seek first to understand, then to be understood.)

    Listening to Loved Ones
    One of the audience members asked for advice on counseling a loved one.  Covey responded with the following solution:

    1. Start by saying, “Honey, I have not spent the time to listen to you, all I’ve done is tell you and evaluate.”
    2. Listen in depth; restate to their satisfaction. (Empathic listening)
    3. After they feel understood, you ask, “Have I listened to you?  Are you willing to listen to me, as I have listened to you?”
    4. Find a 3rd alternative.

    The key here that Covey mentioned is that most people will not pay the price of listening empathically.

    7 Habits of Highly Effective People
    Covey shared a slide that framed out the seven habits of highly effective people in terms of private victory, public victory, dependence, independence, and interdependence.

    1. Be proactive.
    2. Begin with the end in mind.
    3. Put first things first.
    4. Think win-win.
    5. Seek first to understand, then to be understood.
    6. Synergize.
    7. Sharpen the saw.

    Habits 1,2,and 3 are the foundation for private victories and integrity.  Habits 4, 5, and 6 are the keys to public victories.

    Peace of Conscience Over Peace of Mind
    Covey made a distinction between peace of mind and peace of conscience.  He explained that integrity is more than honesty.  Integrity means that if you make a promise, you keep it.  If you’re honest, you might have peace of mind, but if you don’t have integrity, then you won’t have peace of conscience.  You have peace of conscience by avoiding duplicity.

    Loyalty to the Absent
    Covey made his point very simply – only talk about people as if they are there.  You can be critical, but speak as if they were there in front of you.  Don’t bad mouth them behind their back and then sweet talk them to their face.  This is a lack of integrity and creates deep duplicity inside you.  This inhibits your ability to have peace of conscience.

    Use I Messages Over You Messages
    Meet with the people you have a problem with directly.  Practice the following:

    1. Let me listen to you first.
    2. Use “I” messages vs. “you” messages.  I messages are “It’s my perception,” “in my experience,” … etc.  You messages are “you are …”

    Genuine Happiness
    Covey said the key to genuine happiness is to develop integrity.  The key to developing integrity is the first three habits (your Private Victories):

    1. Be proactive
    2. Begin with the end in mind
    3. Put first things first.

    Greek Philosophy of Influence
    Covey shared the three parts of the Greek philosophy of influence:

    1. Ethos – credibility, model trust.
    2. Pathos – restate the point of view.  (Seek first to understand …)
    3. Logos – Make your presentation. (… Then to be understood.)

    You Are the Creative Force of Your Life
    Covey challenged us to be a creative force:
    1.     Get out of victimism – You’re not a victim of your circumstances.
    2.    You are the creative force of your life.

    Empathize first.  Grow your circle of influence.  Make tremendous impact.

    The Most Important Thing You’ll Ever Do
    Covey closed with a powerful message we could take away:

    The most important thing you’ll ever do is in the four walls of your own home.

    My Favorite Part of the Session
    While I enjoyed the entire session, my favorite part was getting to meet Dr. Covey.  I shook his hand, I thanked him for helping people find their voice and he signed my post it note (sadly, I didn’t think to bring my Covey books, and all I had was my post it notes.)

    Key Actions
    After the session, I met with Srinath.  We learned a lot so we tried to turn our insights into a small set of key actions.  Here’s what we came up with:
    1. Develop personal / family mission statements and help others to do the same.
    2. Develop empathic listening and help others to do the same.
    3. Find our voices and help others find theirs. 

    Personally, I want to make more use of the Indian Talking Stick Communication technique, particularly at some of my more vibrant meetings.

    More Information

  • J.D. Meier's Blog

    New Prescriptive Guidance for Visual Studio Team System

    • 20 Comments

    Our patterns and practices team has just released new prescriptive guidance for Visual Studio Team System!

    Since my previous post we've made significant updates with the addition of the following content:

    This puts us on course to deliver on these main outcomes we have in mind for our Visual Studio Team System Guidance Project

    • The single best repository of Visual Studio Team System guidance
    • Practical and insightful scenario-based guidance for roles (PMs, developers, architects, testers ... etc.)
    • Thoroughly engineered and tested set of recommendations
    • Great entry point through videos, roadmaps, and task-based How Tos
    • Breadth and depth coverage

    Project Overview
    While Visual Studio Team System provides powerful new tools, customers are asking "where's the guidance?" ... "where do I start?" ... "how do I make the most of the tools?"  In response, our team is building a definitive Body of Guidance (BOG) for Team System. This includes How Tos, Guidelines, Practices, Q&A, video-based guidance, and more.

    We’re helping customers walk before they run, so we’re starting with the foundation.  On the code side (for developers) – this includes source control, building your dev and test environments and setting up a build process.  On the project side (for PMs) – this includes work items and reporting.  Once we have the foundation in place, we can move up the stack to making the most out of Team System for the various roles (tester, architect, developer … etc.)
     
    We're framing out the tough problems using Scenario Frames (for an example see Source Control Scenario Frame).  We then identify where we need guidance and perform solution engineering.  This involves building out reproducible customer scenarios, vetting potential solutions, and sharing the ones we can generalize enough to be broadly useful, yet still specific enough to be actionable.
     
    We're partnering with customers, product teams, support, field, MVPs, and subject matter experts.  We’re working closely with Jeff Beehler to synchronize efforts with the VSTS Rangers, such as the Branching Guidance.

    Related Posts

  • J.D. Meier's Blog

    Application Architecture Videos

    • 6 Comments

    As part of our patterns & practices Application Architecture Guide 2.0 project, we created sets of videos to help get you up to speed fast.  We have a train the trainer video, step-by-step How To videos, Explained videos, and some videos About the Guide.

    Index of Videos

    Train the Trainer

    About the Guide

    How Tos

    Explained

  • J.D. Meier's Blog

    Timebox Your Day

    • 5 Comments

    Grigori Melnik joined our team recently.  He's new to Microsoft so I shared some tips for effectiveness.  Potentially, the most important advice I gave him was to timebox his day.  If you keep time a constant (by ending your day at a certain time), it helps with a lot of things:

    • Worklife balance (days can chew into nights can chew into weekends)
    • Figuring our where to optimize your day
    • Prioritizing (time is a great forcing function)

    To start, I think it helps to carve up your day into big buckets (e.g. administration, work time, think time, connect time), and then figure out how much time you're willing to give them.  If you're not getting the throughput you want, you can ask yourself:

    • are you working on the right things?
    • are you spending too much time on lesser things?
    • are there some things you can do more efficiently or effectively?

    To make the point hit home, I pointed out that without a timebox, you can easily spend all day reading mails, blogs, aliases, doing self-training, ... etc. and then wonder where your day went.  Microsoft is a technical playground with lots of potential distractions for curious minds that want to grow.  Using timeboxes helps strike balance.  Timeboxes also help with pacing.  If I only have so many hours to produce results, I'm very careful to spend my high energy hours on the right things.

    My Related Posts

  • J.D. Meier's Blog

    Clearing Your Inbox

    • 9 Comments

    Today I helped a colleague clear their inbox.  I've kept a zero mail inbox for a few years.  I forgot this wasn't common practice until a colleague said to me, "wow, your inbox doesn't scroll."

    I didn't learn the zen of the zero mail inbox over night.  As pathetic as this sounds, I've actually compared email practices over the years with several people to find some of the best practices that work over time.  The last thing I wanted to do was waste time in email, if there were better ways.  Some of my early managers also instilled in me that to be effective, I needed to master the basics.  Put it another way, don't let administration get in the way of results.

    Key Steps for a Clear Inbox
    My overall approach is to turn actions into next steps, and keep stuff I've seen, out of the way of my incoming mail.  Here's the key steps: 

    1. Filter out everything that's not directly to you.  To do so, create an inbox rule to remove everything that's not directly To or CC you.  As an exception, I do let my immediate team aliases fall through.
    2. Create a folder for everything that's read.  I have a folder to move everything I read and act on.  This is how I make way for incoming.
    3. Create a list for your actions.  Having a separate list means you can list the actions in the sequence that makes sense for you, versus let the sequence in your inbox drive you.

    Part of the key is acting on mail versus shuffling it.  For a given mail, if I can act on it immediately, I do.  If now's not the time, I add it to my list of actions.  If it will take a bit of time, then I drag it to my calendar and schedule the time.

    Anti-Patterns
    I think it's important to note the anti-patterns:

    1. Using your inbox as a large collection of action and semi-action items with varying priorities
    2. Using your inbox as a pool of interspersed action and reference items
    3. Adopting complicated mail and task management systems

    My Related Posts

    1. Scannable Outcome Lists
    2. Using Scannable Outcomes with My Results Approach
  • J.D. Meier's Blog

    Web Application Architecture Pocket Guide

    • 12 Comments
    Web Architecture Pocket Guide
    We posted our Web Application Architecture Pocket Guide to our Application Architecture Guidance KB.  This is in response to customers who expressed interest in more modular guides as a supplement to our Application Architecture Guide 2.0.

    Chapters At a Glance
    Here’s the chapters at a glance:

    • Ch 01 – Web Application Architecture
    • Ch 02 - Design Guidelines
    • Ch 03 - Presentation Layer Guidelines
    • Ch 04 - Business Layer Guidelines
    • Ch 05 - Data Access Layer Guidelines
    • Ch 06 - Service Layer Guidelines
    • Ch 07 - Communication Guidelines
    • Ch 08 - Deployment Patterns

    Download

    My Related Posts

  • J.D. Meier's Blog

    Security Principles

    • 5 Comments

    If you know the underlying principles for security, you can be more effective in your security design.  While working on Improving Web Application Security: Threats and Countermeasures, my team focused on creating a durable set of security principles.  The challenge was to make the principles more useful.  It's one thing to know the principles, but another to turn it into action. 

    Turning Insights Into Action

    To make the principles more useful, we organized them using our Security Frame.  Our Security Frame is a set of actionable, relevant categories that shape your key engineering and deployment decisions.  With the Security Frame we could quickly find principles related to authentication, or authorization or input validation ... etc. 

    Once we had these principles and this organizing frame, we could then evaluate technologies against it to find effective, principle-based techniques.  For example, when we analyzed doing input and data validation in ASP.NET, we focused on finding the best ways to constrain, reject, and sanitize input.  For constraining input, we focused on checking for length, range, format and type.  Using these strategies both shortened our learning curve and improved our results.

    Core Security Principles

    We started with a firm foundation of core security principles.  These influenced the rest of our security design principles.  Here's the core security principles we started with:

    • Adopt the principle of least privilege - Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised
    • Use defense in depth.   Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
    • Don't trust user input.  Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters.
    • Use secure defaults.   If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change
    • Don't rely on security by obscurity.   Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it's better to use platform features or proven techniques for securing your data.
    • Check at the gate.   Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.
    • Assume external systems are insecure.  If you don't own it, don't assume security is taken care of for you.
    • Reduce Surface Area   Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don't expose any more information than is required when returning an error message to the end user.
    • Fail to a secure mode.   your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don't include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
    • Security is a concern across all of your application layers and tiers.   Remember you are only as secure as your weakest link.
    • If you don't use it, disable it.   You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn't use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

    Frame for Organizing Security Design Principles

    Rather than a laundry list of security principles, you can use the Security Frame as a way to organize and share security principles:

    • Auditing and Logging
    • Authentication
    • Authorization
    • Configuration Management
    • Cryptography
    • Exception Management
    • Input / Data Validation
    • Sensitive Data
    • Session Management

    Auditing and Logging

    Here's our security design principles for auditing and logging:

    • Audit and log access across application tiers.   Audit and log access across the tiers of your application for non-repudiation. Use a combination of application-level logging and platform auditing features, such as Windows, IIS, and SQL Server auditing.
    • Consider identity flow.   You have two basic choices. You can flow the caller's identity at the operating system level or you can flow the caller's identity at the application level and use trusted identities to access back-end resources.
    • Log key events.   The types of events that should be logged include successful and failed logon attempts, modification of data, retrieval of data, network communications, and administrative functions such as the enabling or disabling of logging. Logs should include the time of the event, the location of the event including the machine name, the identity of the current user, the identity of the process initiating the event, and a detailed description of the event
    • Protect log files.   Protect log files using  access control lists and restrict access to the log files. This makes it more difficult for attackers to tamper with log files to cover their tracks. Minimize the number of individuals who can manipulate the log files. Authorize access only to highly trusted accounts such as administrators.
    • Back up and analyze log files regularly.   There's no point in logging activity if the log files are never analyzed. Log files should be removed from production servers on a regular basis. The frequency of removal is dependent upon your application's level of activity. Your design should consider the way that log files will be retrieved and moved to offline servers for analysis. Any additional protocols and ports opened on the Web server for this purpose must be securely locked down.

    Authentication

    Here's our security design principles for authentication:

    • Separate public and restricted areas.   A public area of your site can be accessed by any user anonymously. Restricted areas can be accessed only by specific individuals and the users must authenticate with the site.  By partitioning your site into public and restricted access areas, you can apply separate authentication and authorization rules across the site.
    • Use account lockout policies for end-user accounts.   Disable end-user accounts or write events to a log after a set number of failed logon attempts. With Forms authentication, these policies are the responsibility of the application and must be incorporated into the application design. Be careful that account lockout policies cannot be abused in denial of service attacks.
    • Support password expiration periods. Passwords should not be static and should be changed as part of routine password maintenance through password expiration periods. Consider providing this type of facility during application design.
    • Be able to disable accounts.  If the system is compromised, being able to deliberately invalidate credentials or disable accounts can prevent additional attacks.
    • Do not store passwords in user stores.  If you must verify passwords, it is not necessary to actually store the passwords. Instead, store a one way hash value and then re-compute the hash using the user-supplied passwords. To mitigate the threat of dictionary attacks against the user store, use strong passwords and incorporate a random salt value with the password.
    • Require strong passwords.   Do not make it easy for attackers to crack passwords. There are many guidelines available, but a general practice is to require a minimum of eight characters and a mixture of uppercase and lowercase characters, numbers, and special characters. Whether you are using the platform to enforce these for you, or you are developing your own validation, this step is necessary to counter brute-force attacks where an attacker tries to crack a password through systematic trial and error. Use regular expressions to help with strong password validation.
    • Do not send passwords over the wire in plaintext.   Plaintext passwords sent over a network are vulnerable to eavesdropping. To address this threat, secure the communication channel, for example, by using SSL to encrypt the traffic.
    • Protect authentication cookies.   A stolen authentication cookie is a stolen logon. Protect authentication tickets using encryption and secure communication channels. Also limit the time interval in which an authentication ticket remains valid, to counter the spoofing threat that can result from replay attacks, where an attacker captures the cookie and uses it to gain illicit access to your site. Reducing the cookie timeout does not prevent replay attacks but it does limit the amount of time the attacker has to access the site using the stolen cookie.

    Authorization

    Here's our security design principles for authorization:

    • Use multiple gatekeepers.   By combining multiple gatekeepers across layers and tiers, you can develop an effective authorization strategy.
    • Restrict user access to system-level resources.   System level resources include files, folders, registry keys, Active Directory objects, database objects, event logs, and so on. Use access control lists to restrict which users can access what resources and the types of operations that they can perform. Pay particular attention to anonymous Internet user accounts; lock these down on resources that explicitly deny access to anonymous users.
    • Consider authorization granularity.   There are three common authorization models, each with varying degrees of granularity and scalability: (1.) the impersonation model providing per end user authorization granularity, (2.) the trusted subsystem model uses the application's process identity for resource access, and (3.) the hybrid model uses multiple trusted service identities for downstream resource access. The most granular approach relies on impersonation. The impersonation model provides per end user authorization granularity.

    Configuration Management

    Here's our security design principles for configuration management:

    • Protect your administration interfaces.   It is important that configuration management functionality is accessible only by authorized operators and administrators. A key part is to enforce strong authentication over your administration interfaces, for example, by using certificates. If possible, limit or avoid the use of remote administration and require administrators to log on locally. If you need to support remote administration, use encrypted channels, for example, with SSL or VPN technology, because of the sensitive nature of the data passed over administrative interfaces.
    • Protect your configuration store. Text-based configuration files, the registry, and databases are common options for storing application configuration data. If possible, avoid using configuration files in the application's Web space to prevent possible server configuration vulnerabilities resulting in the download of configuration files. Whatever approach you use, secure access to the configuration store, for example, by using access control lists or database permissions. Also avoid storing plaintext secrets such as database connection strings or account credentials. Secure these items using encryption and then restrict access to the registry key, file, or table that contains the encrypted data.
    • Maintain separate administration privileges.   If the functionality supported by the features of your application's configuration management varies based on the role of the administrator, consider authorizing each role separately by using role-based authorization. For example, the person responsible for updating a site's static content should not necessarily be allowed to change a customer's credit limit.
    • Use least privileged process and service accounts.  An important aspect of your application's configuration is the process accounts used to run the Web server process and the service accounts used to access downstream resources and systems. Make sure these accounts are set up as least privileged. If an attacker manages to take control of a process, the process identity should have very restricted access to the file system and other system resources to limit the damage that can be done.

    Cryptography

    Here's our security design principles for cryptography:

    • Do not develop your own cryptography.   Cryptographic algorithms and routines are notoriously difficult to develop successfully. As a result, you should use the tried and tested cryptographic services provided by the platform.
    • Keep unencrypted data close to the algorithm.   When passing plaintext to an algorithm, do not obtain the data until you are ready to use it, and store it in as few variables as possible.
    • Use the correct algorithm and correct key size.   It is important to make sure you choose the right algorithm for the right job and to make sure you use a key size that provides a sufficient degree of security. Larger key sizes generally increase security. The following list summarizes the major algorithms together with the key sizes that each uses: Data Encryption Standard (DES) 64-bit key (8 bytes) , TripleDES 128-bit key or 192-bit key (16 or 24 bytes) , Rijndael 128–256 bit keys (16–32 bytes) , RSA 384–16,384 bit keys (48–2,048 bytes) .  For large data encryption, use the TripleDES symmetric encryption algorithm. For slower and stronger encryption of large data, use Rijndael. To encrypt data that is to be stored for short periods of time, you can consider using a faster but weaker algorithm such as DES. For digital signatures, use Rivest, Shamir, and Adleman (RSA) or Digital Signature Algorithm (DSA). For hashing, use the Secure Hash Algorithm (SHA)1.0. For keyed hashes, use the Hash-based Message Authentication Code (HMAC) SHA1.0.
    • Protect your encryption keys.   An encryption key is a secret number used as input to the encryption and decryption processes. For encrypted data to remain secure, the key must be protected. If an attacker compromises the decryption key, your encrypted data is no longer secure.  Avoid key management when you can, and when you do need to store encryption keys, cycle your keys periodically.

    Exception Management

    Here's our security design principles for exception management:

    • Do not leak information to the client.   In the event of a failure, do not expose information that could lead to information disclosure. For example, do not expose stack trace details that include function names and line numbers in the case of debug builds (which should not be used on production servers). Instead, return generic error messages to the client.
    • Log detailed error messages.   Send detailed error messages to the error log. Send minimal information to the consumer of your service or application, such as a generic error message and custom error log ID that can subsequently be mapped to detailed message in the event logs. Make sure that you do not log passwords or other sensitive data.
    • Catch exceptions.  Use structured exception handling and catch exception conditions. Doing so avoids leaving your application in an inconsistent state that may lead to information disclosure. It also helps protect your application from denial of service attacks. Decide how to propagate exceptions internally in your application and give special consideration to what occurs at the application boundary.

    Input / Data Validation

    Here's our security design principles for input and data validation:

    • Assume all input is malicious.  Input validation starts with a fundamental supposition that all input is malicious until proven otherwise. Whether input comes from a service, a file share, a user, or a database, validate your input if the source is outside your trust boundary.
    • Centralize your approach.  Make your input validation strategy a core element of your application design. Consider a centralized approach to validation, for example, by using common validation and filtering code in shared libraries. This ensures that validation rules are applied consistently. It also reduces development effort and helps with future maintenance.  In many cases, individual fields require specific validation, for example, with specifically developed regular expressions. However, you can frequently factor out common routines to validate regularly used fields such as e-mail addresses, titles, names, postal addresses including ZIP or postal codes, and so on.
    • Do not rely on client-side validation.   Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security. This is an example of defense in depth.
    • Be careful with canonicalization issues.   Data in canonical form is in its most standard or simplest form. Canonicalization is the process of converting data to its canonical form. File paths and URLs are particularly prone to canonicalization issues and many well-known exploits are a direct result of canonicalization bugs.  You should generally try to avoid designing applications that accept input file names from the user to avoid canonicalization issues.
    • Constrain, reject, and sanitize your input.   The preferred approach to validating input is to constrain what you allow from the beginning. It is much easier to validate data for known valid types, patterns, and ranges than it is to validate data by looking for known bad characters. When you design your application, you know what your application expects. The range of valid data is generally a more finite set than potentially malicious input. However, for defense in depth you may also want to reject known bad input and then sanitize the input.
    • Encrypt sensitive cookie state.  Cookies may contain sensitive data such as session identifiers or data that is used as part of the server-side authorization process. To protect this type of data from unauthorized manipulation, use cryptography to encrypt the contents of the cookie.
    • Make sure that users do not bypass your checks.   Make sure that users do not bypass your checks by manipulating parameters. URL parameters can be manipulated by end users through the browser address text box. For example, the URL http://www.<YourSite>/<YourApp>/sessionId=10 has a value of 10 that can be changed to some random number to receive different output. Make sure that you check this in server-side code, not in client-side JavaScript, which can be disabled in the browser.
    • Validate all values sent from the client.   Restrict the fields that the user can enter and modify and validate all values coming from the client. If you have predefined values in your form fields, users can change them and post them back to receive different results. Permit only known good values wherever possible. For example, if the input field is for a state, only inputs matching a state postal code should be permitted.
    • Do not trust HTTP header information.   HTTP headers are sent at the start of HTTP requests and HTTP responses. Your Web application should make sure it does not base any security decision on information in the HTTP headers because it is easy for an attacker to manipulate the header. For example, the referrer field in the header contains the URL of the Web page from where the request originated. Do not make any security decisions based on the value of the referrer field, for example, to check whether the request originated from a page generated by the Web application, because the field is easily falsified.

    Sensitive Data

    Here's our security design principles for sensitive data:

    • Do not store secrets if you can avoid it.   Storing secrets in software in a completely secure fashion is not possible. An administrator, who has physical access to the server, can access the data. For example, it is not necessary to store a secret when all you need to do is verify whether a user knows the secret. In this case, you can store a hash value that represents the secret and compute the hash using the user-supplied value to verify whether the user knows the secret.
    • Do not store secrets in code.  Do not hard code secrets in code. Even if the source code is not exposed on the Web server, it is possible to extract string constants from compiled executable files. A configuration vulnerability may allow an attacker to retrieve the executable.
    • Do not store database connections, passwords, or keys in plaintext.   Avoid storing secrets such as database connection strings, passwords, and keys in plaintext. Use encryption and store encrypted strings.
    • Avoid storing secrets in the Local Security Authority (LSA).   Avoid the LSA because your application requires administration privileges to access it. This violates the core security principle of running with least privilege. Also, the LSA can store secrets in only a restricted number of slots. A better approach is to use DPAPI.
    • Use Data Protection API (DPAPI) for encrypting secrets.   To store secrets such as database connection strings or service account credentials, use DPAPI. The main advantage to using DPAPI is that the platform system manages the encryption/decryption key and it is not an issue for the application. The key is either tied to a Windows user account or to a specific computer, depending on flags passed to the DPAPI functions.   DPAPI is best suited for encrypting information that can be manually recreated when the master keys are lost, for example, because a damaged server requires an operating system re-install. Data that cannot be recovered because you do not know the plaintext value, for example, customer credit card details, require an alternate approach that uses traditional symmetric key-based cryptography such as the use of triple-DES.
    • Retrieve sensitive data on demand.   The preferred approach is to retrieve sensitive data on demand when it is needed instead of persisting or caching it in memory. For example, retrieve the encrypted secret when it is needed, decrypt it, use it, and then clear the memory (variable) used to hold the plaintext secret. If performance becomes an issue, consider caching along with potential security implications.
    • Encrypt the data or secure the communication channel.   If you are sending sensitive data over the network to the client, encrypt the data or secure the channel. A common practice is to use SSL between the client and Web server. Between servers, an increasingly common approach is to use IPSec. For securing sensitive data that flows through several intermediaries, for example, Web service Simple Object Access Protocol (SOAP) messages, use message level encryption.
    • Do not store sensitive data in persistent cookies.  Avoid storing sensitive data in persistent cookies. If you store plaintext data, the end user is able to see and modify the data. If you encrypt the data, key management can be a problem. For example, if the key used to encrypt the data in the cookie has expired and been recycled, the new key cannot decrypt the persistent cookie passed by the browser from the client.
    • Do not pass sensitive data using the HTTP-GET protocol.   You should avoid storing sensitive data using the HTTP-GET protocol because the protocol uses query strings to pass data. Sensitive data cannot be secured using query strings and query strings are often logged by the server

    Session Management

    Here's our security design principles for session management:

    • Use SSL to protect session authentication cookies.   Do not pass authentication cookies over HTTP connections. Set the secure cookie property within authentication cookies, which instructs browsers to send cookies back to the server only over HTTPS connections.
    • Encrypt the contents of the authentication cookies.   Encrypt the cookie contents even if you are using SSL. This prevents an attacker viewing or modifying the cookie if he manages to steal it through an XSS attack. In this event, the attacker could still use the cookie to access your application, but only while the cookie remains valid.
    • Limit session lifetime.   Reduce the lifetime of sessions to mitigate the risk of session hijacking and replay attacks. The shorter the session, the less time an attacker has to capture a session cookie and use it to access your application.
    • Protect session state from unauthorized access.   Consider how session state is to be stored. For optimum performance, you can store session state in the Web application's process address space. However, this approach has limited scalability and implications in Web farm scenarios, where requests from the same user cannot be guaranteed to be handled by the same server. You should secure the network link from the Web application to state store using IPSec or SSL to mitigate the risk of eavesdropping. Also consider how the Web application is to be authenticated by the state store. Use Windows authentication where possible to avoid passing plaintext authentication credentials across the network and to benefit from secure Windows account policies.

    Using the Security Design Principles

    This is simply a baseline set of principles so that you don't have to start from scratch.  You can build on this set and tailor for your specific context.  I find that while having a set of principles helps, that you can't stop there.  To share the knowledge and help others use the information, it's important to encapsulate the principles in patterns as well as show concrete examples and create precise, actionable guidelines for developers.  Personally, I've found Wikis to be the most effective way to share and manage the information.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Tags vs. Categories

    • 5 Comments

    What's the difference between tags vs. categories in your blog?  A lot.  Knowing the difference between tags and categories can help you better structure your blog for browsing and SEO.  Personally, I hadn't noticed the issue before because I only have tags on my MSDN blog.  As part of my research on effective blogging practices, I hit the issue.  Now that I've experimented with a few blogging platforms, the difference between tags and categories is more obvious.  For example, WordPress 2.3 supports tags in addition to categories.

    Categories, Internal Tags and External Tags

    • Categories. Categories are your high-level buckets.  You should be able to chunk up your blog by a small, mutually exclusive set of categories.  Imagine a user trying to browse the broad themes of your blog.  Categories can also become part of your URL.
    • Internal tags.  Internal tags are for finer-grained slicing and dicing and hopping across your categories.
    • External tags.  External tags, such as Technorati and del.icio.us are for showing your conent in the relevant topics and niches at Technorati and del.icio.us.

    Tag Clouds
    I think the big benefit of tags is creating browsable tag clouds where you can discover related content.  Whereas categories are just one topic, you can use tags to find related content.  For example, you might browse a "security" tag and then browse a "performance" tag to find the intersection of content tagged both "security" and "performance".

    Notes from Lorell
    In Categories versus Tags - What’s the Difference and Which One?, Lorelle makes the following points:

    • "Categories help visitors find related information on your site. Tags help visitors find related information on your site and on other sites."
    • "Categories generate a page of posts on your site. Tags can, too, but often generate a page of off-site posts on an off-site website".
    • "Tagging gives you topical search capabilities for your site that are a middle ground between categories and all-out search, but it shouldn’t replace categories entirely."
    • "Should tags replace categories? Absolutely not."
    • "I use categories as broad groups of posts and tags as micro-groups of posts, helping narrow down the interest."
    • "Tags shouldn’t replace categories, but they can help the user and search engines and directories find and catalog related information on your site."

    Notes from Problogger
    In Using Categories and Tags Effectively on Your Blog, Michael Martin makes the following points:

    • "The number of categories should be small."
    • "Each post goes into one category."
    • "Use the same tags over and over again."
    • "The tag cloud is easy to scan."

    The End in Mind
    In the ideal scenario, to use tags and categories more effectively (assuming your blogging platform supports it), you would have the following in place:

    • A small set of categories for browsing the key themes of your site and for helping SEO (by having relevant category names in the full URL.)
    • A nice tag cloud that helps users browser your site more like a topical search -- using words that your users would know and be looking for.
    • Posts tagged with Technorati and del.icio.us tags that match the most relevant niches.

    Turning It Into Action

    • Use categories to divide your blog into a small set of mutually exclusive buckets.
    • Use internal tags for slicing your content in more granular ways and to create tag clouds for your users.
    • Tag your posts with external tags for Technorati and del.icio.us to reach the relevant social circles.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Code Sharing in Team Foundation Server

    • 4 Comments

    How do you share code in Team Foundation Server?  That's what our team is working through at the moment.  We're looking at what's working, what's not working, and what should customers be doing.

    Here's how we're basically thinking about it so far:

    • There's two main code sharing paths: source and binary.
    • Within source code sharing, there's two approaches:  workspace mapping on the client and branching on the server.
    • The key issues are how to deal with parallel development and how to share across projects

    Here's what seems to be our emerging guidance:

    • If you're coding in parallel, and you need real-time updates, start with workspace mapping.
    • If you need periodic snapshots, or if you need isolation from the changes, then consider a branching approach.
    • If the source you need to reference is relatively stable, then consider using the binary.

    The problem with workspace mappings is that they're developer specific.  Each developer will need their own mapping.  You'll also need to lock down permissions to avoid accidental changes.  Branching has the advantage that you can be explicit about taking changes, so you have stable builds but with the overhead of merging.  You can branch within the same project or cross-project.  A separate project might make sense if you have multiple projects consuming the code.

    I need to still look across more customer sets, but so far I mostly see binary reuse.

    I'm particularly curious in any lessons or insights those of you would like to share.  I think this is an important area for effective source control practices.

  • J.D. Meier's Blog

    Layers and Tiers

    • 2 Comments

    As part of the patterns & practices App Arch Guide 2.0 project, we needed to nail down layers and tiers.   

    Layers vs. Tiers
    The original App Arch Guide distinguished between layers and tiers:

    "This guide uses the term layer to refer to a component type and uses the term tier to refer to physical distribution patterns."

    In other words, layers are logical and tiers are physical (two-tier, three-tier, N-tier).  This distinction is helpful, particularly when you want to talk about where you run your layers (which tier).

    Presentation Layer, Business Layer and Data Layer
    While there's some variations in layer terms, many people that build application will identify with presentation, business, and data layers.  Here's an example:

    Layers 

    • Presentation Layer - provides interactive access to the application.  (You could argue that user interaction layer might be more appropriate.)
    • Business Layer - the logical grouping of components and services that provide the business functionality in your application.
    • Data Layer - the logical grouping of the components and services that provide data access functionality in your application.  (You could argue to call it your resource access layer.)

    Two-Tier, Three-Tier, and N-Tier
    As mentioned earlier, you can think of tiers as physical distribution patterns.   Here are some visual examples:

    Two-Tier

    2Tier

    Three-Tier

    3Tier 

    N-Tier

    NTier

    Additional Resources
    Here's some links you might find useful:

    My Related Posts

  • J.D. Meier's Blog

    Why Do You Do What You Do?

    • 1 Comments

    One of the keys to making impact is knowing "why" you do what you do?  Chasing the "what" can be a red herring.  It's living your"why" and "how" that helps you be your best and it's where your inner strength comes from.  Most importantly, it's where you give your best where you have your best to give.  One of the tools for figuring out why you do what you do is the Golden Circle.  You can watch this video interview with Simon Sinek on the Golden Circle for an overview.   I also shared my Golden Circle results in my post, Why Do You Do What You Do? on Sources of Insight as both a reminder and inspiration.  Enjoy!

  • Page 2 of 44 (1,089 items) 12345»