J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Agile Methodology in Microsoft patterns & practices

    • 0 Comments

    “I put my heart and my soul into my work, and have lost my mind in the process.” -- Vincent Van Gogh

    I find myself mentoring on Agile practices and Agile methodology on a regular basis.  More and more teams are needing to stay connected with customers, respond to change, and flow value along the way.   I find that if you know what Agile methodology looks like, it’s easier to get started.   In this post, I’ll share what an implementation of Agile methodology looks like.

    When I was on the Microsoft patterns & practices team, we used a combination of XP/Scrum for executing projects.  We called our agile methodology, "Customer-Connected Engineering"or CCE.  The following table is an overlay of customer-connected activities on top of the agile methodology:

    Phase Core Activities Customer-Connected Engineering Activities
    Exploration
    • Go / No Go
    • Business Case
    • Product Backlog
    • Release Planning
    • Team Role Assignments
    • Vision Scope
    • Broad Customer Surveys
    • Customer Advisory Board Setup
    • Stories / Scenarios
    • Prioritization
    Iteration 0
    • Clarification of process, responsibilities, and roles
    • Infrastructure setup
     
    Iteration N
    • Iteration Planning
    • Daily Stand-Up
    • Mid-Iteration Checkpoint
      Review
    • Retrospective
    • Internal Release (Optional)
    • Customer Release (Optional)
    • Stories / Scenarios
    • Prioritization
    • Demos
    • Product Drops
    • Feedback
    Stabilization
    • Remaining Work Completed
    • Outstanding Bugs Resolved
     
    Release
    • Documentation Updates
    • Incomplete Stories Removed
    • Final Test
    • Remaining Bugs Resolved
    • Release Bar Met
     

    The activities on the left-side of the table are core activities in patterns & practices projects.  If you’re familiar with XP/Scrum, you’ll be familiar with the activities.  On the right-hand side are customer-connected activities.

    10 Highlights of the Agile Methodology and Customer-Connected Engineering
    Here are some of the most important points and distinctions:

    1. 40 Hour Work Week.   In my experience, a 40 hour work week is a benchmark of the most effective teams.  They have work-life balance.  They have buffer to respond to opportunity and to deal with crunches.  They have processes in place, they invest in their learning and growth, and they move up the stack instead of always solving the basics.  Instead of perpetual fire-fighting, they are more deliberate about planning and strategy and they anticipate their customers and the market (through empathy and staying connected to customers.)  They learn and respond and can turn on a dime.  They have a dashboard, they know the score, and they can change their approach.   See 40 Hour Work Week at Microsoft.
    2. Exploration and Execution.   One of the best moves we did was introduce the idea of an “Exploration” phase.    This is where we would explore and test customer value, while also exploring technical risk.  By doing architectural spikes we could very quickly identify potential technical risks that would impact the project, long before we even started the project.  In general, our exploration phase was anywhere from 4 – 8 weeks.  It was also a practical way to drive innovation and explore new opportunities.  We reduced risk by setting a limit on time and budget.  This gave creative freedom within the box, but constrained risk and cost for the business, while exploring high potential opportunities.
    3. Demos.   Demos are the key to product success, if you do them early enough.  Demos actually serve two functions.  First, they force you to put together that you’ve got into a presentable form.  What looks good on paper, or sounds good in your mind, might not be that good when you actually present it.   So, the demo is a great forcing function for you to identify what’s actually valuable and how to package and showcase that value in a presentable way.    Second, the value of the demo is the actual feedback.  As a rule, I like to Demos on Thursdays each week, as a way to bring work together into a package.  It helps people show off their stuff and feel acknowledge and appreciated.  If it’s an internal demo, then it helps people on the team get real feedback from their peers before going more broadly.  If it’s a public demo, then it’s a great chance to get real feedback from actual users.  I’m a fan of failing fast and failing often.   You get better through failure than you do from success because you learn *why* and *how* to improve.   As Tony Robbins puts it, when you succeed you party and when you fail you ponder.  My guiding principle is to carry the good forward and to turn failure into feedback.
    4. Iterations.   Iterations are a wonderful thing.  They help you set a cadence for shipping stuff, doing demos, and executing your work.   In patterns & practices, the most common pattern was two-week iterations.  I originally used three-week iterations, and then moved to two-week iterations, and eventually moved to one-week iterations, for a variety of reasons.  The one-week iterations reduced my iteration planning time from one or two hours down to 30 minutes max.  It also helped people on the team feel more connected to their results and to drive a great week.   It also meant people had to spend less time estimating their work, and it meant that estimates were more accurate.  In simple terms, it meant that the team could plan a great week, and on Friday reflect on their results without bleeding things into the net week … bite off a weeks’ worth of work, and finish a week’s worth of work.   This radically improved our agility and our ability to execute in a more predictable and streamlined way.   This also set the stage for more lean practices, and on my projects, I was a fan of using a Kanban to visualize the work, reduce open work, and to improve our flow.  I also liked that Kanban is a very customer-connected approach to development in that it is “pull” vs. “push.”  It’s the ultimate in “demand-driven” development.
    5. Product Backlogs and Sprint Backlogs.   Your “Product” backlog is everything that needs to get built.  The “Sprint” backlog is simply the chunk you are biting off for this particular iteration.   This distinction is an important one.   It’s great to have one place to look for everything that makes up the possibilities, the pains, and the needs of your potential product.   It’s also great to be able to grab a meaningful chunk for execution.   The real trick with biting off a meaningful chunk is knowing the dependencies and being able to sequence in a way that flows value while reducing risk.  This is also another reason why user stories are helpful.  They are a collection of customer value at your finger tips.
    6. Prioritization.   To prioritize our user stories and backlog items, we’ve used surveys extensively.   A proven practice is to play a game of “spend a $100.” (See Enterprise Library 5.0 Product Backlog Prioritization Survey.)   An important point is that the prioritization surveys are input into your prioritization planning.  They help you balance perspective and identify actual demand.  In a best case example, they help you find the surprises or disconnects.  Customers usually know what they want, but they don’t always know what they need, and there is often an awareness issue.   If you’re familiar with marketing, this is specifically about finding, surfacing, and addressing latent needs.   Customers may want the “cheaper” bridge, but as the engineer, you need to make sure they know the trade-offs, and that a “safer” bridge might be a better bet.  What’s important is that you create an opportunity for customers to voice their priorities and that you keep an open mind to being surprised.
    7. Project cycles and product cycles.  Having a distinction between the project and product cycle help you optimize and use the right tool for the job.  For a simple example, Scrum is more of a project process, while XP is more of a product development process.  The project cycle is important at the business level.  It’s the cadence of the projects.  It’s where the vital few milestones are established in terms of start, key checks, ship, and post-mortem.  Product cycles on the other hand, are geared towards the product development.   The real key here is that if you have multiple teams, you can standardize on the project cycle, while you let each team choose it’s most effective product cycle or development methodology.  The product cycle would simply feed into the agreed milestones at the project cycle level to support the rhythm at the business level.
    8. Release Planning.    Release planning is a significant body of work.   One of the most important features of release planning in patterns & practices was determining the Minimum Credible Release (MCR.)  This was the minimum product we could ship that would actually be worth it.   To illustrate this to management, we simply drew a cut-line in terms of scenarios.
    9. Scenarios and Stories.   In many ways, scenarios and user stories are the backbone of the product.   They are one of the best ways to set scope.   Scenarios and stories are also a great way to capture and share requirements in a more contextual way.   You get customers to tell you their specific goals and tasks.   If you want to build a better product, then focus on building a great set of scenarios and stories.   These are the backbone of your product.   They set the tests for success.   They are your tool for prioritizing.   To stay customer connected, your customers directly contribute the stories and scenarios, and they help prioritize the stories and scenarios with you.   This is how you build empathy for the customer’s pains and needs.   For examples, see WCF Security Scenarios in Azure and WCF Scenarios Map.
    10. User, Business, and Technical Perspective.   Maintaining and balancing perspectives and points of view is key to successful product development.   You’ll find that a lot of conflict and arguments happen because everybody is “right”, but they are “right” only from their perspective, and you need to know which perspective they are arguing.  The perspectives that you will most often bump up against in product development are user, business, and technical.   If you keep those in mind, then whenever there is an argument or a conflict, then you can do a quick sanity check to figure out what perspective are they arguing from.   When you know this, it is a lot easier to build bridges too or speak the right language.   When speaking to the business, talk about value and cost, budget, and quality.  Or talk about cycle time and efficiency or effectiveness.   Or focus on the “What” or the “Why.”  When speaking to the technical, it’s fine to elaborate on trade-offs, the “How”, and implementation details.  Tech is a great perspective to elaborate on system concerns or quality attributes like security, performance, or reliability.  When talking tech, it’s a great perspective to speak about features and specifics.   When speaking to the customer perspective, here is where you want to talk about persona, roles, and goals.  Or it’s a great place to talk about pains and needs.   A great rule of thumb that has served me well is to speak in terms of “persona-based goals with scenarios.”  See Perspectives Frame and User Experience, Tech Feasibility, and Business Value.

    There is a lot more I could say, and a lot more I could share, and I will.   For example, I learned a lot from doing Retrospectives for various product teams around Microsoft.    I also learned a lot on building more effective business cases.   I’ve also learned a lot about doing effective daily standups with distributed teams around the world.  The most important thing though that I learned, at least in terms of helping teams get up and running with Agile, is how to show and share end-to-end life-cycles.   For example, I have a simple model now of the Project Cycle + Product Cycle and the workstreams below each, now in my head.  In a future post, I’ll share what that looks like, if there is interest.

    My Related Posts

  • J.D. Meier's Blog

    Using Scannable Outcomes with My Results Approach

    • 15 Comments

    Some readers asked to hear more on how I use my Scannable Outcome Lists in conjunction with My Personal Approach for Daily Results.  Here's the work flow in a nutshell ...

    Mondays
    On Mondays, I figure out my key outcomes for the week.  To do this:

    • I remind myself what I learned from last Friday's reflections.
    • I scan my calendar
    • I scan my inbox for new information
    • I scan my Scannable Outcome List for each category

    I keep my inbox completely empty, so the only items are what comes in over the weekend.  The empty inbox is particularly important for me.  I get ~150 mails directly to me each day, and I send about that, so I can't be a paper shuffler.  For my Scannable Outcome Lists, I use a flat list of posts in Outlook.  I name each post according to category: Body, Career, Mind, Project X, Project Y .. etc.

    As I scan, I use four guiding questions:

    1. What must be done? ... what should be done? ... what could be done?
    2. What customer value am I delivering? (I measure in value delivered vs. activity performed)
    3. How am I improving myself in key areas: career, mind, body, financial, relationships?
    4. What are the things that if I don't get done ... I'm screwed?  (By using the principle of contrast, I paint a picture of where I don't want to be.)

    As I scan, I also do some quick shuffling:

    I get a few outcomes from this

    • Most importantly, I have a mental picture for the week's outcomes (notice outcomes vs. activity)
    • I know my big risks for the week
    • I know my MUSTs vs. SHOULDs vs. COULDs
    • I have my list of outcomes for the day -- my Daily Outcomes.

    I have weekly iteration meetings with my team on Mondays, so this information helps me shape the outcomes with my team.

    Daily
    Each day, I construct my Daily Outcomes list.  Since I did the bulk of the work on Monday for identifying key priorities, this is a fast exercise.  In fact, it's usually 5 minutes.  It's as fast as it takes me to open a new post in Outlook, name it the current day (e.g. 02-25-07) and write the key outcomes down.  Throughout the day, I add to this.  I fish my email stream throughout the day for relevant actions and I add these to the current day's daily outcome.  If it's a longer team outcome, I list it under the relevant Scannable Outcome List.

    Fridays
    This is the day where I do more reflection.  To do this:

    • I scan my Daily Outcomes for the past week.  (This is fast because, for each day, I have a single post named by date.  For example: 02-19-07, 02-20-07, 02-21-07, 02-22-07, 02-23-07)   
    • I scan accomplishments
    • I scan my backlog

    As I scan, I ask some guiding questions:

    • If something's not getting done, then why not? ... Is there a habbit or practice I need to change for efficiency or effectiveness?
    • Do I need to change my approach for myself or the team?
    • What key lessons learned need to carry forward?

    I'll note that underlying my approach is my belief that important things should float to the top, less important should slough off, and I should be able to deal with change.  Having my Scannable Outcomes keeps me grounded in what's important vs. urgent.  This to me is the key to driving versus reacting.  If an area is slipping that I want to improve, I narrow my focus and concentrate on that.  There's few problems that withstand sustained focus.

    Well, that's the heart of the approach.  What I like most about this approach is that it's low-overhead and it works.  I've done away with over-engineered approaches, where you die the death of a 1000 paper cuts in administration.  I also like this approach because it's systematic, yet holistic and flexible.  Basically, it's designed for getting real results, in real life.

  • J.D. Meier's Blog

    Ten Steps for Structured Project Management

    • 1 Comments

    In the book "How to Run Successful Projects III, The Silver Bullet", Fergus O'Connell identifies ten steps to structured project management:

    1. Visualize the goal
    2. Make a list of jobs
    3. There must be one leader
    4. Assign people to jobs
    5. Manage expectations, allow a margin of error, have a fallback position
    6. Use an appropriate leadership style
    7. Know what's going on
    8. Tell people what's going on
    9. Repeat steps 1-8 until step 10
    10. The Prize

    These ten steps help make project management consistent, predictable, and repeatable.  The first five steps are about planning your project.  The last five are about implementing the plan and achieving the goal.  These steps are based on 25 years of research into why some projects fail and others succeed.

    I like to checkpoint any project I do against these steps.  I find that when a project is off track, I can quickly pinpoint it to one of the steps above and correct course.

  • J.D. Meier's Blog

    Now Available: Final PDF of the Microsoft Application Architecture Guide, Second Edition

    • 8 Comments

    A final PDF is now available for our patterns & practices Application Architecture Guide, second edition.  This is our platform playbook for the Microsoft application platform.

    Here are the relevant links:

    Here are some of my related posts:

  • J.D. Meier's Blog

    Security Code Examples Project

    • 2 Comments

    I'm working with the infamous Frank Heidt, George Gal and Jonathan Bailey to create a suite of modular, task-based security code examples.  They happen to be experts at finding mistakes in code.  Part of making good code is knowing what bad code looks like and more importantly what makes it bad, or what the trade-offs are.  I've also pulled in Prashant Bansode from my core security team to help push the envelope on making the examples consumable.  Prashant doesn't hold back when it comes to critical analysis and that's what we like about him.

    For this exercise, I'm time-boxing the effort to see what value we produce within the time-box.  We carved out a set of candidate code examples by identifying common mistakes in key buckets, including input/data validation, authentication, authorization, auditing and logging, exception management and a few others.  We then prioritized the list and do daily drops of code.  The outcome should be some useful examples and an approach for others to contribute examples.

    Sharing a chunk of code is easy.  We quickly learned that sharing insights with the code is not.  Exposing the thinking behind the code is the real value.  We want to make that repeatable.  I think the key is a schema with test cases.

    Here's our emerging schema and test cases ....

    Code Example Schema (Short Form)

    • Title
    • Summary
    • Applies To
    • Objectives
    • Solution Example
    • Problem Example
    • Test Case
    • Expected Results
    • More Information
    • Additional Resources

    For more information on the schema and test cases, see Code Example Schema for Sharing Code Insights.

    Today we had a deeply insightful review with Tom Hollander, Jason Taylor, and Paul Saitta.  Jason and Paul are on site while we're solving another class of problems for customers.  They each brought a lot to the table and collectively I think we have a much better understanding of what makes a good, reusable piece of code. 

    We made an important decision to optimize around "show me the code" and then explain it, versus a lot of build up and then the code.  Our emerging schema has its limits and does not take the place of a How To or guidelines or a larger resuable block of code, but it will definitely help as we try to share more modular code examples that demonstrate proven practices.

  • J.D. Meier's Blog

    Key Software Trends

    • 7 Comments

    What you don’t know can hurt you. Sometimes the world can change under your feet and you never saw it coming.  I like to anticipate and stay ahead of the curve where I can. As part of our patterns & practices Application Architecture Guide 2.0 project, I’ve been hunting and gathering trends that influence software development. Rather than make this exhaustive, I wanted to share "good enough" for now, and leave you room to tell me what I've missed and share what you’re seeing in your world.

    Key Notes On Trends

    • Trends aren’t fads.  Trends tend to have depth and staying power, whereas fads tend to be short-lived.
    • Some fads are future trends in disguise.
    • In my experience, consumer trends influence Enterprise trends.
    • Use trends to help you avoid surprises and to sound hip at the water cooler when you too can speak the buzz.

    Trend "Hot Spots"
    Rather than distinguish between trends and fads, I decided to focus on “hot spots” and simply identify the topics that keep showing up in various contexts with customers, in Microsoft, in the industry, … etc.

    Applications
  • Business Process Management (BPM)
  • Composite / Mash Ups (Server-side, Client-side)
  • Dynamic Languages
  • Functional Programming
  • Health
  • Model-Driven
  • Representational State Transfer (REST)
  • Software plus Services / Software as a Service / Platform as a Service (S+S / SaaS / PaaS)
  • Service Oriented Architecture (SOA)
  • Rich Internet Applications (RIA)
  • Testability
  • User Empowerment (shift in power from business and tech to the user)
  • User Experience (not to be confused with UI)
  • Infrastructure
  • Cloud Computing
  • Green IT
  • Virtualization
  • Very Large Databases
  • Performance
  • Grid
  • High Performance Computing (HPC)
  • Many-core / Multi-core
  • Parallel Computing
  • Software Development
  • Application Life-Cycle Management (ALM)
  • Distributed Teams
  • Lean
  • Scrum
  • User-Lead
  • XP
  • I know the list looks simple enough, but it actually took a bit of vetting to spiral down on the ones that have wood behind the arrow and have signs of a trajectory.

    David Chou on Trends ...
    In this post, Cloud Computing and Microsoft, David Chou identifies the following trends:

    • Consumerization of the Web, and use of browsers
    • Application development efforts shifting towards thin clients and server-side programming
    • Improvements in network bandwidth, anywhere wireless access, etc.
    • Increased maturity in open source software
    • Proliferation and advancement of mobile devices
    • Service Oriented Architecture
    • Software-as-a-Service
    • Utility/Grid Computing

    Simon Guest on Trends ...
    In his talk, An Architectural Overview of Software + Services, Simon Guest outlines the following industry trends:

    • Trend 1: Service Oriented Architecture (SOA)
    • Trend 2: Software as a Service (SaaS)
    • Trend 3: Web 2.0
    • Trend 4: Rich Internet Applications (RIA)
    • Trend 4: Cloud Computing

    Simon connects the dots from the trends to how they support Software + Services:

    • SOA - Reuse and agility
    • RIA: Rich Internet Applications - Experience
    • SaaS: Software as a Service - Flexible pricing and delivery
    • Cloud Computing - Service Utility
    • Web 2.0 - Network Effect

    Phillip Winslow on Trends …
    In an Interop Keynote Panel on Current Software Trends, Phillip Winslow responded to the to please predict the biggest IT story for 2008 as follows:

    “ … decoupling of the end user platform. Virtualization and desktop virtualization and layering on SAAS… Salesforce.com, gmail, etc how we think about the desktop sitting on our desk will be much different.”

    TrendWatching.com on Trends ...
    Here's a snapshot of interesting tidbits from a an earlier version of this trend report page on TrendWatching.com:

    • HappyNomics - In fact, this year may be a good time to move 'HAPPYNOMICS' from the academic world to your ideation team.
    • 12 Themes - The 20+ trends covered in the report are part of bigger themes:
      'REAL', 'BEST', 'STORY', 'UNREAL', 'UNFIXED', 'TIME', 'GREEN', 'DOMAIN', 'ONLINE', '(R)ETAIL', 'ASSIST' and 'PARTICIPATE'.   These themes are all about what will EXCITE consumers in the near future, and can be read/presented independently, or as a coherent 'story'.

    Here's the cool part.  I saw GREEN on their page well before I noticed any of the Green IT initiatives show up.  It struck me as an example of consumer influencing Enterprise.

    Key Posts
    Here's some of the posts that I found to be useful for understanding the impact and influences behind some of the trends:

    Additional Resources
    I know this looks like a laundry list of links but these are actually helpful to quickly get what some of the topics are about:

    My Related Posts

  • J.D. Meier's Blog

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

    • 15 Comments

    Today we released our patterns & practices Application Architecture Guide 2.0 Beta 2.  This is our Microsoft playbook for the application platform.  It's 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.  This is the guide that helps you understand our platform, choose among the technologies, and build applications based on lessons learned and proven practices.

    Key Changes in Beta 2
    Beta 2 is a significant overhaul of the entire guide.  We carried the good forward.  We made some key additions:

    • Added a foreword by S. Somasegar.
    • Added technology considerations throughout the guide.
    • Added technology matrixes for choosing technologies, including Presentation, Data Access, Workflow, and Integration technologies.
    • Added a new Agile Architecture Method (see chapter 4.)
    • Tuned and pruned the recommendations across the entire guide.
    • Restructured the guide for simpler parts – fundamentals, design, layers and archetypes.

    4 Parts

    • Part I, “Fundamentals”
    • Part II, “Design”
    • Part III, “Layers”
    • Part IV, “Archetypes"

    Chapters

    Appendix

    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; 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; 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; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Manish Prabhu; Meghan Perez; 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 Beta 1 Release
  • 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

    Project Management Body of Knowledge (PMBOK) Framework

    • 0 Comments

    Here is a quick map of the process groups, knowledge areas, and processes in the PMBOK (Project Management Body of Knowledge).  Regardless of the PMI certification, I think it’s useful to know how the knowledge for project management is organized by experts and professionals.   This will help you more effectively navigate the space, and learn project management at a faster pace, because you can better organize the information in your mind.

    If you are a program manager or a project manager, the categories are especially helpful for checking your knowledge and for thinking of projects more holistically.   You can also use the knowledge areas to grow your skills by exploring each area and building your catalog of principles, patterns, and practices.

    Process Groups and Knowledge Areas
    Here is a quick map of the process groups and knowledge areas in the Project Management Body of Knowledge:

    Category

    Items

    Process Groups

    1. Initiating
    2. Planning
    3. Executing
    4. Monitoring and Controlling
    5. Closing

    Knowledge Areas

    1. Project Integration Management
    2. Project Scope Management
    3. Project Time Management
    4. Project Cost Management
    5. Project Quality Management
    6. Project Human Resource Management
    7. Project Communications Management
    8. Project Risk Management
    9. Project Procurement Management

    Knowledge Areas and Processes
    Here is a quick topology view of the Knowledge Areas and the processes:

    Knowledge Area

    Processes

    Project Integration Management

    • Develop Project Charter
    • Develop Primary Project Scope Statement
    • Develop Project Management Plan
    • Direct and Manage Project Execution
    • Monitor and Control Project Work
    • Integrated Change Control
    • Close Project

    Project Scope Management

    • Scope Planning
    • Scope Definition
    • Create WBS
    • Scope Verification
    • Scope Control

    Project Time Management

    • Activity Definition
    • Activity Sequencing
    • Activity Resource Planning
    • Activity Duration Estimating
    • Schedule Development
    • Schedule Control

    Project Cost Management

    • Cost Estimating
    • Cost Budgeting
    • Cost Control

    Project Quality Management

    • Quality Planning
    • Perform Quality Assurance
    • Perform Quality Control

    Project Human Resource Management

    • Human Resource Planning
    • Acquire Project Team
    • Develop Project Team
    • Manage Project Team

    Project Communication Management

    • Communication Planning
    • Information Distribution
    • Performance Reporting
    • Manage Stakeholders

    Project Risk Management

    • Risk Management Planning
    • Risk Identification
    • Qualitative Risk Analysis
    • Quantitative Risk Analysis
    • Risk Response Planning
    • Risk Monitoring and Control

    Project Procurement Management

    • Plan Purchase and Acquisition
    • Plan Contracting
    • Request Seller Responses
    • Select Sellers
    • Contract Administration
    • Contract Closure

  • J.D. Meier's Blog

    Windows Azure Code Samples Collection

    • 0 Comments

    image

    The Microsoft Windows Azure Code Samples Collection is a roundup and map of Windows Azure code samples from  various sources including the MSDN library, Code Gallery, CodePlex, and Microsoft Support.

    You can add to the Windows Azure code examples collection by sharing in the comments or emailing me atFeedbackAndThoughts at live.com.

    Common Categories for Windows Azure Code Samples
    The Windows Azure Code Samples Collection is organized using the following categories:

    image

    Windows Azure Code Samples Map

    Category

    Items

    Sample Apps

    DPE

    Windows Azure Training Kit

    Architecture and Design

    Code Gallery

    DPE

    patterns & practices

    Claims / Identity

    patterns & practices

    Windows Azure Training Kit

    Configuration

    Data Access and Storage

    MSDN Magazine

    Windows Azure Training Kit

    Deployment

    patterns & practices

    General

    Windows Azure Training Kit

    Logging and Instrumentation

    Migration

    patterns & practices

    Service Bus

    All-in-One Code Framework

    MSDN Magazine

    Service Management API

    · Windows Azure Service Management CmdLets from http://code.msdn.microsoft.com/azurecmdlets

    SQL Azure

    Code Gallery

    Microsoft Support

    WCF

    Code Gallery

    All-in-One Code Framework

    Windows Azure Storage

    Code Gallery

    All-in-One Code Framework

    Windows Azure UE Team Code Samples
    The Windows Azure UE team now has an organized collection of code samples available at:


    My Related Posts

  • J.D. Meier's Blog

    Windows Azure Developer Guidance Map

    • 5 Comments

    image

    If you’re a Windows Azure developer or you want to learn Windows Azure, 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 Windows Azure Developer Guidance Map helps you kill a few birds with one stone:

    1. It show you the key sources of Windows Azure 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)
    3. You can also use the map as a model for creating your own map of developer guidance.

    Download the Windows Azure Developer Guidance Map

    Contents at a Glance

    • Introduction
    • Sources of Windows Azure Developer Guidance
    • Topics and Features Map (a “Lens” for Finding Windows Azure 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 Windows Azure features:

    image

    Special Thanks …
    Special thanks to David Aiken, James Conard, Mike Tillman, Paul Enfield, Rob Boucher, Ryan Dunn, Steve Marx, Terri Schmidt, and Tobin Titus for helping me find and round up our various content collections.

    Enjoy and share the map with a friend.

  • J.D. Meier's Blog

    New Release: patterns & practices WCF Security Guide

    • 9 Comments

    Today we released our patterns & practices Improving Web Service security: Scenarios and Implementation Guidance for WCF on MSDN.  Using end-to-end application scenarios, this guide shows you how to design and implement authentication and authorization in WCF. You'll learn how to improve the security of your WCF services through prescriptive guidance including guidelines, a Q&A, practices at a glance, and step-by-step how to articles. The guide is the result of a collaborative effort between patterns & practices, WCF team members, and industry experts.

    Key Scenarios
    Here's the key scenarios:

    • A development team that wants to adopt WCF.
    • A software architect or developer looking to get the most out of WCF, with regard to designing their application security.
    • Interested parties investigating the use of WCF but don’t know how well it would work for their deployment scenarios and constraints.
    • Individuals tasked with learning WCF security.
    • Authentication, authorization, and communication design for your services
    • Solution patterns for common distributed application scenarios using WCF
    • Principles, patterns, and practices for improving key security aspects in services

    Contents at a Glance

    • Part I: Security Fundamentals for Web Services
    • Part II: Fundamentals of WCF Security
    • Part III: Intranet Application Scenarios
    • Part IV: Internet Application Scenarios

    Chapters

    • Foreword by Nicholas Allen
    • Foreword by Rockford Lhotka
    • Chapter 1: Security Fundamentals for Web Services
    • Chapter 2: Threats and Countermeasures for Web Services
    • Chapter 3: Security Design Guidelines for Web Services
    • Chapter 4: WCF Security Fundamentals
    • Chapter 5: Authentication, Authorization, and Identities in WCF
    • Chapter 6: Impersonation and Delegation in WCF
    • Chapter 7: Message and Transport Security
    • Chapter 8: Bindings
    • Chapter 9: Intranet - Web to Remote WCF Using Transport Security (Original Caller, TCP)
    • Chapter 10: Intranet - Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
    • Chapter 11: Intranet - Web to Remote WCF Using Transport Security (Trusted Subsystem, TCP)
    • Chapter 12: Intranet - Windows Forms to Remote WCF Using Transport Security (Original Caller, TCP)
    • Chapter 13: Internet - WCF and ASMX Client to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
    • Chapter 14: Internet - Web to Remote WCF Using Transport Security (Trusted Subsystem, TCP)
    • Chapter 15: Internet – Windows Forms Client to Remote WCF Using Message Security (Original Caller, HTTP)

    Our Team

    • J.D. Meier
    • Carlos Farre
    • Jason Taylor
    • Prashant Bansode
    • Steve Gregersen
    • Madhu Sundararajan
    • Rob Boucher

    Contributors / Reviewers

    • External Contributors / Reviewers: Andy Eunson; Anil John; Anu Rajendra; Brandon Bohling; Chaitanya Bijwe; Daniel Root; David P. Romig, Sr.; Dennis Rea; Kevin Lam; Michele Leroux Bustamante; Parameswaran Vaideeswaran; Rockford Lhotka; Rudolph Araujo; Santosh Bejugam
    • Microsoft Contributors / Reviewers: Alik Levin; Brandon Blazer; Brent Schmaltz; Curt Smith; David Bradley; Dmitri Ossipov; Jan Alexander; Jason Hogg; Jason Pang; John Steer; Marc Goodner; Mark Fussell; Martin Gudgin; Martin Petersen-Frey; Mike de Libero; Mohammad Al-Sabt; Nobuyuki Akama; Ralph Squillace; Richard Lewis; Rick Saling; Rohit Sharma; Scott Mason; Sidd Shenoy; Sidney Higa; Stuart Kwan; Suwat Chitphakdibodin; T.R. Vishwanath; Todd Kutzke; Todd West; Vijay Gajjala; Vittorio Bertocci; Wenlong Dong; Yann Christensen; Yavor Georgiev
  • J.D. Meier's Blog

    Patterns and Practices for Distributed Teams

    • 4 Comments

    This post is a summary of my lessons learned from leading distributed teams.  I've managed distributed project teams since 2001, spanning the UK, Argentina, India, and other parts of the world.  While I preferred having everybody together on site around a whiteboard to simplify and improve communication,  flexibility with distributed teams gave me access to the right talent, wherever it may be.

    Key Challenges
    These are some of the most common challenges I faced:

    • Trust
    • Time zone differences
    • Sharing state
    • Changes in direction that have a ripple effect
    • Communication overhead
    • Keeping everybody on the same page
    • Sharing knowledge across the team
    • Partitioning work for enough autonomy but to keep checks and balances
    • Lack of a whiteboard

    Distance didn’t matter as much as differences in time zones.  If the time zone differences were too much, it meant  a lot more information, knowledge and state had to be packaged up and handed over.  However, when you leverage time zone differences, the experience can feel like you carry the baton forward, or, it’s like “The Elves and the Shoemaker,” where you make progress around the clock.

    Success Patterns for Distributed Teams
    The following success patterns helped improve distributed team effectiveness:

    • Forming, storming, norming and performing.   The forming, storming, norming and performing lens helps remind everybody to expect that things smooth out over time.  It’s a simple maturity model for explaining how a team gels.
    • Proxy / On Point.  One of the most helpful patterns for cross-site communication is to have somebody act as the proxy or person on point to funnel key communication.  This is especially important when their are major time zone differences.  The additional patterns, such as the show and tell, and the Monday iterations and daily stand-ups, keep this from being a single point of failure.  Instead, it’s a focal point with some accountability when key information needs to be shared across time zones.
    • Rhythm of results.  Daily, Weekly, and Monthly Results.   While the team might ship every two weeks, thinking in terms of daily, weekly, and monthly results helps set the right mindset.  It creates a bias for action, and it helps get the kinks out of execution.
    • Monday Vision, Daily Outcomes, and Friday Reflection.   This is a simple, high-level pattern to drive results each week.   The approach is to identify 3 key outcomes for the week, as well as 3 key outcomes each day, and to use Friday for learning and reflecting. 
    • Stories.  By focusing on stories, it makes it easy for everybody on the team to think in terms of end-to-end stories over, features or discipline-focused activities.  It’s a great way to balance the customer, technical and business perspectives, as well as help the team converge around common goals.
    • Monday Iteration plans.  Doing iteration plans on Mondays helps set the goals for the week, as well as include everybody’s input.  We keep these to 30 minutes or less.  The outcome is the prioritized set of stories for the week.
    • Daily stand-ups.    Everybody calls in and we go around the team asking 3 questions: 1) what did you get done? 2) what are you getting done today? and 3) where do you need help?  We keep these to 10 minutes or less.  It sets the pace and prevents getting side-tracked.
    • Invoke a teammate.  One goal up front is to make it easy for everybody on the team to reach whoever they need in an ad-hoc way.  Everybody identifies their preferred email, phone number, Skype account, and instant message information, as well as their main working hours.
    • Show and Tell.  I use weekly show and tells as a forcing function.  It gives people on the team a chance to show off their work.  More importantly it’s a simple way to dog food results as well as use the team as a sounding board.  It’s one thing to build something, it’s another to show it to other people and get honest feedback.
    • Wiki Knowledge Bases (KBs.)   Using Wikis helps simplify sharing information.  It keeps people from over-engineering and it’s easy to keep updated.
    • Experience Step-Throughs.   These are simply short slide decks that mock up the experience.  Each deck walks through one story or scenario visually.  We test the experience with customers, and then we walk through as a team, from a technical perspective.  We do this for high-risk stories.   See Experience-Driven Development and Experience Step-Throughs.
    • Distributed pairing.   I’ve found the fastest way to hand over information is to pair people up.  Pairing can also help people get unblocked or keep pace.  It’s not always obvious who pairs up well, so we test different combinations to find what works best for people.  Sometimes it helps to compliment skills.  For example, one person might be great technically, while another might be great with customer experience.
    • Mentoring and buddies.   Helping new people on the team ramp up is a priority.  I’ve found the most effective way is to have people pair on things together.  For metaphors, we call it either “co-pilot” or a “student-driver” model.
    • Email Triage.  As simple as it sounds, it’s been helpful to include “triage” in the title of some emails.  This tells the team that this email thread may be a drill-down or discussion on a topic.  It’s also a quick way for anybody on the team to ask for help, since they may not know who on the team has the answer.
    • One mail.   This is a simple burn down list.  Whenever we’re pushing for a key milestone, it’s helpful to summarize the open work that everybody can see and comment on in a shared way.  To do so, we simply send out an email that lists the current open work to the team and everybody chimes in.  It helps everybody see a tangible finish line.
    • Team project site.   It’s important that the team has one place to look for all the shared information.  The most important information here is the schedule, the deliverables, status, and any key information related to either the deliverables or the project.
    • Lessons Learned.   I’m a fan of sharing lessons learned on the team.  To bootstrap these, we usually just start an email thread and dump our lessons learned.  We then port the lessons into the Wiki for easy reference.  We list the lessons as one-liners in the form of “do’s” and “don’ts".”  It’s a tickler list that provides a backdrop for richer conversations, dialogues, and discussions.
    • Checklists.  Checklists for common tasks have been the best and simplest way to share information across the team.   They help reduce mistakes and carry lessons forward.
    • Best Practices Repository.   We store our best practices for each project in a project-level repository.  At the end of the project, we port the best practices to a shared repository across projects.  This way each project is focused on “best practices,” and these are very specific and detailed.  The all up best practices are more generalized to be useful across projects, and as a starting point for new projects.
    • Reduce friction in the process.   This is a shared goal on the team to get the kinks out of any sticking points in any of the processes.  We try to innovate in the process to save cost or time or improve effectiveness.  This helps us avoid death by a 1000 paper cuts.
    • Video nuggets.   We’ve found that sharing short-videos can help share knowledge on the team very quickly.  These are throw-away videos, but they help capture a snapshot whenever somebody does research in a particular area.

    No single pattern is a silver bullet.  Instead, it’s the composition of these patterns and practices that help improve distributed team communication and overall effectiveness.

    Tools of the Trade
    The following are some common tools of the trade:

    • Email.  This is helpful for sharing technical details, state, and general asynchronous communication.
    • Conference calls.  This is important for Monday iterations, daily stand-ups, Show and Tells, and any other team meetings.
    • Microsoft Shared view.  This is helpful for distributed pairing as well as Show and Tells, so that everybody can see a shared desktop.
    • Slides.  Slideware is a great way to share visuals and consolidate key information or to demo ideas and concepts.
    • Mind Maps.   Mind maps are a great way to pair and map out what the team knows about a given topic.  We’ve also found them useful for creating Work Breakdown Structures, as a team.  This way everybody gets to see the big picture  as a simple map.
    • Instant Messenger.  This is especially helpful for simply knowing when people on the team are around and for ad-hoc synch ups.
    • Skype.   This has gradually replaced setting up conference calls.  In fact, we’ve started having better luck with Skype than conference calls in terms of clarity in some cases.
    • Groove.  This has been our simplest way to share files instead of email.  There are some tricks to learn, but we’ve successfully shared projects of with thousands of files and hundreds of MBs.

    What about you?  … What have been your best lessons learned when it comes to distributed teamwork?

  • J.D. Meier's Blog

    Agile Security Engineering

    • 1 Comments

    “It is not necessary to change. Survival is not mandatory.”—Edwards Deming

    I gave a talk for the developer security MVPs at the Microsoft 2010 MVP Summit last week.  While I focused primarily on Azure Security, I did briefly cover Agile Security Engineering.  Here is the figure I used to help show how we do Agile Security Engineering in patterns & practices:

    Agile Security Engineering

    What’s important about the figure is that it shows an example of how you can overlay security-specific techniques on an existing life cycle.  In this case, we simply overlay some security activities on top of an Agile software cycle.

    Rather than make security a big up front design or doing it all at the end or other security approaches that don’t work, we’re baking security into the life cycle.  The key here is integrating security into your iterations.

    Here is a summary of the key security activities and how they play in an agile development cycle:

    • Security Objectives – This is about getting clarity on your goals, objectives, and constraints so that you effectively prioritize and invest accordingly.
    • Security Spikes – In Agile, a spike is simply a quick experiment in code for the developer to explore potential solutions.  A security spike is focused exploring potential security solutions with the goal of reducing technical risk.  During exploration, you can spike on some of the cross-cutting security concerns for your solution.
    • Security Stories – In Agile, a story is a brief description of the steps a user takes to perform a goal.  A security story is simply a security-focused scenario.  This might be an existing “user” story, but you apply a security lens, or it might be a new “system” story that focuses on a security goal, requirement, or constraint.  Identify security stories during exploration and during your iterations.
    • Security Guidelines – To help guide the security practices throughout the project, you can create a distilled set of relevant security guidelines for the developers.  You can fine tune them and make them more relevant for your particular security stories.
    • Threat Modeling – Use threat modeling to shape your software design.  A threat model is a depiction of potential threats and attacks against your solution, along with vulnerabilities.  Think of a threat as a potential negative effect and a vulnerability as a weakness that exposes your solution to the threat or attack.  You can threat model at the story level during iterations, and you can threat model at the macro level during exploration.
    • Security Design Inspections – Similar to a general architecture and design review, this is a focus on the security design.  Security questions and criteria guide the inspection.  The design inspection is focused on higher-level, cross-cutting, and macro-level concerns.
    • Security Code Inspections – Similar to a general code review, this is a focus on inspecting the code for security issues.  Security questions and criteria guide your inspection.
    • Security Deployment Inspections – Similar to a general deployment review, this is a focus on inspecting for security issues of your deployed solution.  Physical deployment is where the rubber meets the road and this is where runtime behaviors might expose security issues that you didn’t catch earlier in your design and code inspections.

    The sum of these activities is more than the parts and using a collection of proven, light-weight activities that you can weave into your life cycle helps you stack the deck in your favor.  This is in direct contrast to relying on one big silver bullet.

    Note that we originally used “reviews” which are more exploratory, but we later optimized around “inspections.”  The distinction is that inspections use criteria (e.g. a 12 point inspection.)  We share the criteria using security checklists for design, coding, and deployment inspections.

    There are two keys to chunking up security so that you can effectively focus on it during iterations:

    1. Security stories
    2. Security frame

    Stories are a great way of chunking up value.  Each story represents a user performing a useful goal.  As such, you can also chunk up your security work, by focusing on the security concerns of a story.

    A security frame is a lens for security.  It’s simply a set of categories or “hot spots” (e.g. auditing and logging, authentication, authorization, configuration management, cryptography, exception management, sensitive data, session management.)   Each category is a container for principles, patterns, and anti-patterns.  By grouping your security practices into these buckets, you can more effectively consolidate and leverage your security know-how during each iteration.  For example, one iteration might have stories that involve authentication and authorization, while another iteration might have stories that involve input and data validation.

    Together, stories and security frames help you chunk up security and bake it into the life cycle, while learning and responding along the way.

    For more information on security engineering, see patterns & practices Security Engineering Explained.

  • J.D. Meier's Blog

    ADO.NET Code Samples Collection

    • 0 Comments

    image

    The ADO.NET Code Samples Collection is a roundup and map of some of the various data access code samples from  various sources including the MSDN library, Code Gallery, CodePlex, and Microsoft Support.

    You can add to the code examples collection by sharing in the comments or emailing me at FeedbackAndThoughts at live.com.

    Common Categories for ADO.NET Code Samples
    The ADO.NET Code Samples Collection is organized using the following categories:

    image

    ADO.NET Code Samples Collection

    Category

    Items

    Data Binding

    MSDN Library

    Data Models

    Code Gallery

    Microsoft Support

    DataReader

    MSDN Library

    DataSet

    MSDN Library

    DataTable

    MSDN Library

    Entity Framework

    All-in-One Code Framework

    Code Gallery

    General

    All-in-One Code Framework

    MSDN Library

    LINQ to DataSet

    MSDN Library

    LINQ to Entities

    MSDN Library

    LINQ to Objects

    All-in-One Code Framework

    LINQ to SQL

    All-in-One Code Framework

    Code Gallery

    Code Gallery

    N-Tier

    Code Gallery

    O/RM Mapping

    Code Gallery

    OData

    Code Gallery

    POCO

    Silverlight

    Code Gallery

    SQL Server

    MSDN Library

    Streaming

    Code Gallery

    WCF Data Services

    All-in-One Code Framework

    Code Gallery

    My Related Posts

  • J.D. Meier's Blog

    patterns and practices Complete Catalog

    • 5 Comments

    What's the full patterns & practices catalog?  I created a quick index of the patterns & practices catalog since I've needed to hunt down a few things.  I figured this might be useful to share.

    Views

    Blocks

    Enterprise Library

    Factories

    Guides

    Patterns

    Tools

  • J.D. Meier's Blog

    What Makes a Good Threat Model

    • 4 Comments

    While trying to create threat model template for customers, I analyzed many threat models inside and outside Microsoft.  It was insightful to see the patterns of what was useful across threat models and what was noise.

    A good threat model has the following components:

    • Security objectives.  What must you do vs. what's nice to do?  These set the boundaries of what's in scope vs. what's out of scope.  
    • Key Scenarios.  Where and how will your software be used? These put your software in context and gives you context while evaluating.
    • Security mechanisms.  These shine the spotlight on explicit security engineering decisions.
    • Trust boundaries.  These help you focus on critical places where security trust levels change.  These also help prioritize entry points.
    • Data flows.  These help you trace data through the system, to expose potential issues.
    • Entry points.   Where do you accept input?  These are primary attack vectors.
    • Exit points.  Where do you write output?
    • Threats.  A list of these helps you put perspective when ranking vulnerabilities.  What's the worst that can happen?  What can you live with?
    • Vulnerabilities.  A list of these helps you identify actionable places in your software to address security concerns.

    A good threat model serves the following purposes:

    • Informs your design
    • Scopes your security testing
    • Helps reviewers evaluate your security decisions

    By far, the most tangible output of the threat modeling activity is a prioritized list of vulnerabilities.  These are action items for your developers and input for your testers.  The developer makes a call on whether and how to fix, and the tester will test the fix.


    This sample Template for a Web Applications Threat Model comes very close to showing what I've empirically seen to be useful, though there's always a gap between reality and real-time.

  • J.D. Meier's Blog

    How To Use ASP.NET Forms Auth with SQL Server on Windows Azure

    • 2 Comments

    This post is a quick step through of creating a Windows Azure cloud project that authenticates using ASP.NET Forms Authentication with SQL Server as the user store.

    The core steps are very much the same as my previous post How To Use ASP.NET Forms Auth with Azure Tables.   The key difference is step 7 and step 8, which specify the connection to SQL Server.

    Summary of Steps
    Here are the steps at a glance:

    • Step 1. Create a New Cloud Service Project.
    • Step 2. Add a Login Page.
    • Step 3. Create a Way for New Users to Register
    • Step 4. Configure ASP.NET to use Forms Authentication
    • Step 5. Configure ASP.NET to restrict Anonymous Users
    • Step 6. Set up the SQL Membership Database
    • Step 7. Add the SQL Connection String
    • Step 8. Configure ASP.NET to Use the SQL Membership Provider
    • Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details
    • Step 10. test registering a new user and logging in to the application

    Here we go …

    Step 1. Create a New Cloud Service Project.
    In this step, you create a new cloud service project in Visual Studio:

    1. Start Visual Studio, from the menu select  “File” then click “New’ and then click ‘Project”
    2. In the “New Project’ dialog box, expand ‘Visual C#’ (or Visual Basic, if you are using it) in the ‘Project Types’ section, and select “Cloud Service”.
    3. In the ‘Templates’ section choose “Windows Azure Cloud Service” template, set the location, Name it as FormsAuthSample and click the “Ok” button.
    4. In the “New Cloud Service Project” dialog box, select “ASP.NET Web Role”, and click the “>” button to add it to the solution.  Then click the “Ok” button.  This will create a sample cloud Web Application, which is ready to be hosted in the cloud with all required configuration files etc.
    5. Run and verify that it works fine.

    Step 2. Add a Login Page.
    Use Solution Explorer to add a new Web form named Login.aspx to the WebRole1 site.

    Step 3.  Create a Way for New Users to Register
    Add the following two lines into the Login.aspx <form> tag

        <asp:Login runat="server" />
        <asp:CreateUserWizard runat="server"></asp:CreateUserWizard>

    It should resemble the following:

        <form id="form1" runat="server">
        <div>
        <asp:Login runat="server" />
        <asp:CreateUserWizard runat="server"></asp:CreateUserWizard>
        </div>
        </form>

    Step 4. Configure ASP.NET to use Forms Authentication
    In Web.config, add the following line insde the <system.web> tag:
            <authentication mode="Forms" />

    Step 5. Configure ASP.NET to restrict Anonymous Users
    In Web.config, add the following line inside the <system.web> tag:

          <authorization>
            <deny users="?" />
            <allow users="*" />
          </authorization>

    Note – The preceding configuration allows only authenticated users to access the application. The "?" indicates unauthenticated users and the "*" indicates all users. By denying unauthenticated users, any requests made by unauthenticated users are redirected to the login page. The loginUrl attribute of the <forms> element determines the name of the login page. The default setting of this attribute is Login.aspx.

    Step 6. Set up the SQL Membership Database
    In this step, you configure the SQL data store for membership.  This is accomplished through the use of the aspnet_regsql.exe utility.  Details on aspnet_regsql.exe can be found at: http://msdn.microsoft.com/en-us/library/ms229862(VS.80).aspx

    Step 7. Add the SQL Connection String
    In Web.config, add the connection string to the connectionStrings tag using the <add> tag as follows:

      <connectionStrings>
        <add name="MyLocalSQLServer" connectionString="Initial Catalog=aspnetdb;Data Source=MyServerName;Integrated Security=SSPI"/>
      </connectionStrings>

    Step 8. Configure ASP.NET to Use the SQL Membership Provider
    In this step, you configure the Web application to use the SQL Membership Provider.

    In Web.config, add the following lines inside the <system.web> tag:

        <membership defaultProvider="MySqlMembershipProvider" >
          <providers>
            <clear/>
            <add name="MySqlMembershipProvider"
                 connectionStringName="MyLocalSQLServer"
                 applicationName="MyAppName"
                 type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
          </providers>
        </membership>

    Step 9. Add Test Code to Page_Load to Show the Forms Authentication Details
    Add a using statement to Default.aspx.cs in your WebRole1 project to add a reference to  System.Web.Security.
    Add the following code to Page Load of Default.aspx.cs in WebRole1:
    protected void Page_Load(object sender, EventArgs e)

        Response.Write("Hello, " + Server.HtmlEncode(User.Identity.Name) + "<br />");
    }

    Step 10. test registering a new user and logging in to the application

    1. Run the project by using the F5 key (this runs the project in Debug mode.)
    2. Create a new user.  On your first visit, you need to create a new user (e.g. “bob”.)  Note that the password rules by default are alphanumeric plus one non- alphanumeric (for example, "password!")
    3. Login to the application.  Sign in with your new username and password pair.

    The Web application should return something along the following lines:

    Hello, waldo

    Share your feedback or results in the comments.  We’re path paving along with you.

    My Related Posts

  • J.D. Meier's Blog

    Getting Results the Agile Way - The Book on Getting Results

    • 11 Comments

    GettingResults2

    “Are you getting results? …”

    Over Christmas break, I committed to finishing the writing for a book that I expect to change a lot of people's lives.  It's my first non-technical book.  The working title is, Getting Results the Agile Way.  It's all about getting results in work and life.  It's the playbook I wish somebody had given me long ago for finding work/life balance, managing time, playing to my strengths, and making the most of what I've got.

    Why Getting Results
    The world is a tough place.  Between layoffs, the economy, and simply the unknown, a lot of people are having a really tough time in their lives.  There are constantly new challenges at a pace that's tough to keep up.  Worse, I don't think you learn a lot of these skills in school or on the job, except through the school of hard knocks.

    This is my playbook for you.  For more than 10 years at Microsoft I've tested and evaluated ways to get results.  I've had to find things that not only work for me, but that could work for the people I mentor inside and outside the company, as well as for large teams around the world.  I'm a big believer that everybody can get great results if they have the right know-how.

    What Sorts of Problems Does It Tackle
    The book is a system and a playbook for some of these common challenges:

    • How to find work / life balance
    • How to shift from tasks and activities to meaningful results and outcomes
    • How to use stories and scenario-driven results to carve out value in your life
    • How to overwhelm your challenges with fierce results
    • How to defeat perfectionism
    • How to avoid analysis paralysis and take action a simple story at a time
    • How to find your flow state for more engaging work
    • How to find your passion and purpose
    • How to play to your strengths for more energy and better results
    • How to conquer fear and avoid learned helplessness
    • How to motivate yourself in ways that make you feel you can move mountains
    • How to focus on what really counts
    • How to prioritize more effectively
    • How to create more value for yourself and others
    • How to spend more time on what you want, and less time on what you don’t

    It helps with a lot of things because mostly it gets you spending the right time, on the right things, with the right energy, the right way.  This is the key to your best results.

    My Story
    When I first joined Microsoft, it was sink or swim.  I saw a lot of people fail.  Among the chaos, I also saw many people thrive.  I wanted to know their secrets.  I started with people on my team, but the next thing you know I was studying success patterns around the company.  If somebody was known for getting results, I hunted them down and studied their ways.

    I learned so many simple things that actually worked.  For example, instead of managing time, the real key is managing your energy.  I'd rather have four power hours, than a week of just going through the motions.  The secret of work life balance is setting up your own artificial boundaries, whether it's "dinner on the table at 5:30" or "no work on the weekends."  Finding your passion can be as simple as connecting to your values.  For example, I use metaphors to make my project an epic adventure and I have the team create the movie poster of what great results will look like.  How's that for wanting to show up and give your best every day knowing you're working on blockbuster results?

    What is Agile Results?
    You'll hear me talk about Agile Results quite a bit.  It's the name I gave the system  that serves as the foundation for the Getting Results guide.  Agile is all about responding to change.  It's agility in action.  It's all about making progress while the world changes under your feet.

    My Agile Results system borrows the best principles, patterns, and practices across a variety of disciplines from sports, positive psychology, personal productivity, Agile development, Scrum, project management, time management, leadership skills, and strengths-based development.  It's more than a mash up -- I've tested and honed the system to work for individuals and teams while refining it over years of deliberate practice.  To me, great results for the team, always starts with unleashing an individual’s best.  Having fun is contagious and getting results spreads like a wild fire.

    Agile Results in a Nutshell
    Here is the Agile Results system at a glance:

    • The Rule of 3 – You can apply the Rule of 3 to work and life to avoid overwhelming yourself while carving out  value, a day at a time, a story at a time.  See The Rule of 3.
    • Monday Vision, Daily Outcomes, and Friday Reflection – This is a simple weekly pattern for results.  On Mondays figure out your 3 compelling results for the week.  Each day, figure out your 3 best results for the day.  On Fridays, identify 3 things going well, and 3 things to improve.  See Monday Vision, Daily Outcomes, and Friday Reflection.
    • Hot Spots -  This is your heat map.  Hot Spots are a simple lens to look at your life as a portfolio you invest in: mind, body, emotions, career, financial, relationships, and fun.  It’s under-investing or over-investing in these areas that can get in the way of great results.  See Hot Spots.

    How to Get Started
    Getting started is really easy.  If you write down 3 results you want for today, you're doing Agile Results.  Is there more to it? … Sure, but take it at your own pace.  Here’s a one-page guide for getting started with Agile Results.

    How To Follow Along for the Ride
    You can read Getting Results for free online in HTML.  I’ll continue to shape the guide over the next several weeks based on feedback.  I’ll also be making March a focus on getting results so if you’ve been looking for a jumpstart for your life, this is a great month to make it happen.   I’ll be sharing nuggets for getting results at my effectiveness blog, Sources of Insight.

    If you're not getting the results you want in your life, you just need the skills.  Use my guide to stuff your bag of tricks with some new tools that will change your game and help you unleash your best.

  • J.D. Meier's Blog

    People I've Worked with On Past Projects

    • 1 Comments

    One lesson I've learned time and again is that it's about the people.  You can be on a lousy project with great people and still have a great time.  The reverse is not always true.  Of course, the ideal world is a great project with great people.  I've been lucky enough to have enjoyed several adventures with great people while trying to change the world.

    As part of mid-year review, I'm taking a stroll down memory lane.  To do so, I created a snapshot of people I've worked with while writing books in patterns & practices over the years. Looking into the past always gives me insight into the future.   I use it to find personal success patterns.  It also helps me get a new vantage point for project analysis.

    The first thing I learned by looking at the list of people I've worked with is how the right project can really grow your network.   The other thing is how you can also predict a project's success largely by who's involved.   The thing that really stands out for me is that the most successful projects were ones that created an intersection of the right problems, with the right people, with the right passions and strengths.  That's what dream teams and compelling missions are made of.  A simple test of whether you have the right team is whether you want to run towards or away from the problem.

    Here's the snapshot I used for my analysis ...

    Application Architecture Guide 2.0

    • Home Page: http://www.codeplex.com/AppArchGuide
    • Forewords: S. Somasegar, Scott Guthrie
    • Authors: J.D. Meier , Alex Homer, David Hill, Jason Taylor , Prashant Bansode , Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
    • Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman
    • Edit Team - Dennis Rea
    • 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; 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; Javed Sikander; 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; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

    Improving Web Services Security

    • Home Page: http://www.codeplex.com/WCFSecurityGuide
    • Forewords: Nicholas Allen, Rockford Lhotka
    • Authors: J.D. Meier, Carlos Farre, Jason Taylor, Prashant Bansode, Steve Gregersen, Madhu Sundararajan, Rob Boucher
    • External Contributors/Reviewers: Andy Eunson; Anil John; Anu Rajendra; Brandon Bohling; Chaitanya Bijwe; Daniel Root; David P. Romig, Sr.; Dennis Rea; Kevin Lam; Michele Bustamante; Parameswaran Vaideeswaran; Rockford Lotka; Rudolph Araujo; Santosh Bejugam
    • Microsoft Contributors / Reviewers: Alik Levin; Brandon Blazer; Brent Schmaltz; Curt Smith ; Dmitri Ossipov; Don Smith; Jan Alexander; Jason Hogg; Jason Pang; John Steer; Marc Goodner; Mark Fussell; Martin Gudgin; Martin Petersen-Frey; Mike de Libero; Mohammad Al-Sabt; Nobuyuki Akama; Ralph Squillace; Richard Lewis; Rick Saling; Rohit Sharma; Scott Mason; Sidd Shenoy; Sidney Higa; Stuart Kwan; Suwat Chitphakdibodin; T.R. Vishwanath; Todd Kutzke; Todd West; Vijay Gajjala; Vittorio Bertocci; Wenlong Dong; Yann Christensen; Yavor Georgiev

    Team Development with Visual Studio Team Foundation Server

    • Home Page: http://msdn.microsoft.com/en-us/library/bb668991.aspx
    • Forewords: Jeff Beehler, Rob Caron, Brian Harry
    • Authors: J.D. Meier, Jason Taylor, Prashant Bansode, Alex Mackman, Kevin Jones
    • External Contributors/Reviewers.  David P. Romig, Sr; Dennis Rea; Eugene Zakhareyev; Leon Langleyben; Martin Woodward; Michael Rummier; Miguel Mendoza ; Mike Fourie; Quang Tran; Sarit Tamir; Tushar More; Vaughn Hughes
    • Microsoft Contributors / Reviewers.  Aaron Hallberg; Ahmed Salijee; Ajay Sudan; Ajoy Krishnamoorthy; Alan Ridlehoover; Alik Levin; Ameya Bhatawdekar; Bijan Javidi; Bill Essary; Brett Keown; Brian Harry; Brian Moore; Brian Keller; Buck Hodges; Burt Harris; Conor Morrison; David Caufield; David Lemphers; Doug Neumann; Edward Jezierski; Eric Blanchet; Eric Charran; Graham Barry; Gregg Boer; Grigori Melnik; Janet Williams Hepler; Jeff Beehler; Jose Parra; Julie MacAller; Ken Perilman; Lenny Fenster; Marc Kuperstein; Mario Rodriguez; Matthew Mitrik; Michael Puleio; Nobuyuki Akama; Paul Goring; Pete Coupland; Peter Provost; Granville (Randy) Miller; Richard Berg; Rob Caron; Robert Horvick; Rohit Sharma; Ryley Taketa; Sajee Mathew; Siddharth Bhatia; Tom Hollander; Tom Marsh; Venky Veeraraghavan

    Performance Testing Guidance

    • Home Page: http://msdn.microsoft.com/en-us/library/bb924375.aspx
    • Forewords: Alberto Savoia, Rico Mariani
    • Authors: J.D. Meier, Microsoft, Senior Program Manager, patterns & practices
      Carlos Farre, Microsoft, Software Design Engineer Test, patterns & practices
      Prashant Bansode, Infosys Technologies Ltd
      Scott Barber, PerfTestPlus Inc, Chief Technologist
      Dennis Rea, Wadeware LLC
    • Microsoft Contributors and Reviewers: Alan Ridlehoover; Clint Huffman; Edmund Wong; Ken Perilman; Larry Brader; Mark Tomlinson; Paul Williams; Pete Coupland; Rico Mariani
    • External Contributors and Reviewers: Alberto Savoia; Ben Simo; Cem Kaner; Chris Loosley; Corey Goldberg; Dawn Haynes; Derek Mead; Karen N. Johnson; Mike Bonar; Pradeep Soundararajan; Richard Leeke; Roland Stens; Ross Collard; Steven Woody

    Security Engineering

    • Home Page: http://msdn.microsoft.com/en-us/library/ms998382.aspx
    • Authors: J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, and Rudolph Araujo.
    • Test Team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Infosys Technologies Ltd.
    • Edit Team: Nelly Delgado, Microsoft Corporation
    • Release Management: Sanjeev Garg, Microsoft Corporation
    • External Contributors and Reviewers: Anil John, Johns Hopkins University – Applied Physics Laboratory; Frank Heidt; Keith Brown Pluralsight LLC; Mark Curphey, Foundstone Professional Services
    • Microsoft Services and PSS Contributors and Reviewers: Adam Semel, Denny Dayton, Gregor Noriskin, Kate Baroni, Tom Christian, Wade Mascia
      Microsoft Product Group: Charlie Kaufman, Don Willits, Mike Downen, Rick Samona
      Microsoft IT Contributors and Reviewers: Akshay Aggarwal, Irfan Chaudhry, Shawn Veney, Talhah Mir
    • MSDN Contributors and Reviewers: Kent Sharkey
    • Microsoft EEG: Corey Ladas, James Waletzky 

    Improving .NET Application Performance and Scalability

    • Home Page: http://msdn.microsoft.com/en-us/library/ms998530.aspx
    • Forewords: S. Somasegar, Rico Mariani, Brandon Bohling, Connie U. Smith, Scott Barber
    • Authors: J.D. Meier, Srinath Vasireddy, Ashish Babbar, Alex Mackman
    • Special thanks to key contributors: Anandha Murukan; Andy Eunson; Balan Jayaraman, Infosys Technologies Ltd; Christopher Brumme (CLR and COM interop); Connie U. Smith, Ph.D.; Curtis Krumel (SQL Server); David G. Brown (SQL Server); Denny Dayton; Don Willits ("Uber man"); Edward Jezierski; Ilia Fortunov; Jim O'Brien, Content Master Ltd; John Allen (ASP.NET); Matt Odhner (ACT); Prabhaker Potharaju (SQL Server); Rico Mariani (Performance Modeling, CLR, Code Review, Measuring); Ray Escamilla (Tuning); Scott Barber (Performance Modeling and Testing); Sharon Bjeletich (SQL Server)
    • Special thanks to key reviewers: Adam Nathan (Interop); Brad Abrams; Brandon Bohling, Intel Corporation; Carlos Farre, Solutions IQ; Chuck Delouis, Veritas Software (SQL Server); Cosmin Radu (Interop); Eddie Lau (ACE); Eric Morris (ACE); Erik Olsen (ASP.NET); Gerardo Bermudez (CLR, Performance Modeling); Gregor Noriskin; Ken Perilman; Jan Gray; John Hopkins (ACE); Joshua Lee; K.M. Lee (ACE TEAM); Mark Fussell (XML); Matt Tavis (Remoting); Nico Jansen (ACE Team); Pablo Castro (ADO.NET and SQL); Patrick Dussud (CLR); Riyaz Pishori (Enterprise Services); Richard Turner (Enterprise Services); Sonja Keserovic (Interop); Thomas Marquardt (ASP.NET); Tim Walton; Tom McDonald; Wade Mascia (ASP.NET threading, Web services, and Enterprise Services); Yasser Shohoud (Web services)
    • External Reviewers: Ajay Mungara, Intel Corporation; Bill Draven, Intel Corporation; Emil Lerch, Intel Corporation; Carlos Santos (Managed Code); Chris Mullins, Kiefer Consulting; Christopher Bowen, Monster.com; Chuck Cooper; Dan Sullivan; Dave Levine, Rockwell Software; Daniel Cazzulino, Lagash Systems SA; Diego Gonzalez, Lagash Systems SA (XML); Franco Ceruti; Fredrik Normen "N2", Barium AB (extensive review); Grant Fritchey; Greg Buskirk; Greg Kiefer, Kiefer Consulting; Ingo Rammer, IngoRammer.com; James Duff, Vertigo Software; Jason Masterman, Barracuda .NET (Remoting); Jeff Fiegel, Acres Gaming; Jeff Sukow, Rockwell Software; John Lam; John Vliet, Intel Corporation; Juval Lowy (COM interop); Kelly Summerlin, TetraData; Mats Lanner, Open Text Corporation; Matt Davey; Matthew Brealey; Mitch Denny, Monash.NET; Morten Abrahamsen (Performance and Transactions); Nick Wienholt, dotnetperformance.com; Norm Smith (Data Access and Performance Modeling); Pascal Tellier, prairieFyre Software Inc.; Paul Ballard, Rochester Consulting Partnership, Inc.; Per Larsen (Managed Code Performance); Scott Allen (Design Guidelines); Philippe Harry Leopold Frederix (Belgium); Scott Stanfield, Vertigo Software; Ted Pattison, Barracuda .NET (COM Interop); Thiru Thangarathinam; Tim Weaver, Monster.com; Vivek Chauhan (NIIT); Thiru Thangarathinam; Wat Hughes, Creative Data (SQL Server)
    • Microsoft Consulting Services and Product Support Services (PSS): Dan Grady; David Madrian; Eddie Clodfelter; Hugh Wade; Jackie Richards; Jacquelyn Schmidt; Jaime Rodriguez; James Dosch; Jeff Pflum; Jim Scurlock; Julian Gonzalez (Web services); Kenny Jones; Linnea Bennett; Matt Neerincx; Michael Parkes; Michael Royster; Michael Stuart; Nam Su Kang; Neil Leslie; Nobuyuki Akama; Pat Altimore; Paul Fallon; Scott Slater; Tom Sears; Tony Bray
    • Microsoft Product Group: Alexei Vopilov (Web services); Amrish Kumar; Arvindra Sehmi; Bill Evans; Brian Spanton; Keith Ballinger (WSE); Scot Gellock (Web services); Brian Grunkemeyer (CLR); Chris Eck; David Fields (NT); David Guimbellot; David Mortenson (CLR); Dax Hawkins; Dhananjay Mahajan (Enterprise Services); Dino Chiesa; Dmitry Robsman; Doug Rothaus (ADO.NET); Eddie Liu; Elena Kharitidi (Web services); Fabio Yeon; Harris Syed (Enterprise Services); Jason Zander; Jeffrey Cooperstein; Jim Radigan; Joe Long (Web services vs. ES vs. Remoting); Joshua Allen; Larry Buerk; Lubor Kollar (SQL Server); Maoni Stephens; Michael Coulson; Michael Fanning; Michael Murray (FxCop); Omri Gazitt; Patrick Ng (FX DEV); Peter Carlin (SQL Server); Rebecca Dias (WSE); Rick Vicik; Robin Maffeo (CLR Thread pool); Vance Morrison; Walter Stiers; Yann Christensen
    • patterns & practices members: Jason Hogg (ADO.NET and XML); Naveen Yajaman; Sandy Khaund; Scott Densmore; Tom Hollander; Wojtek Kozaczynski
      Thanks to our test team: (Infosys Technologies Ltd): Austin Ajit Samuel Angel; Dhanyah T.S.K; Lakshmi; Prashant Bansode; Ramesh Revenipati; Ramprasad Gopalakrishnan; Ramprasad Ramamurthy; Terrence J. Cyril
      Thanks to our editors for helping to ensure a quality experience for the reader: Sharon Smith; Tina Burden McGrayne, Entirenet; Susan Filkins, Entirenet; Tyson Nevil, Entirenet
    • product manager: Ron Jacobs
    • Finally, thanks to: Alex Lowe; Chris Sells; Jay Nanduri; Nitin Agrawal; Pat Filoteo; Patrick Conlan (SQL Server); Rajasi Saha; Sanjeev Garg (Satyam Computer Services); Todd Kutzke

    Improving Web Application Security: Threats and Countermeasures

    • Home Page: http://msdn.microsoft.com/en-us/library/ms994921.aspx
    • Forewords: Mark Curphey, Erik Olson, Joel Scambrary, Michael Howard
    • Authors: J.D. Meier, Alex Mackman, Srinath Vasireddy, Michael Dunner, Ray Escamilla, Anandha Murukan
    • External Reviewers–Mark Curphey, Open Web Application Security Project and Watchfire; Andy Eunson (extensive review); Anil John (code access security and hosting scenarios); Paul Hudson and Stuart Bonell, Attenda Ltd. (extensive review of the Securing series); Scott Stanfield and James Walters, Vertigo Software; Lloyd Andrew Hubbard; Matthew Levine; Lakshmi Narasimhan Vyasarajan, Satyam Computer Services; Nick Smith, Senior Security Architect, American Airlines (extensive review of the Securing series); Ron Nelson; Senthil Rajan Alaguvel, Infosys Technologies Limited; Roger Abell, Engineering Technical Services, Arizona State University; and Doug Thews.
    • Microsoft Product Group–Michael Howard (Threat Modeling, Code Review, and Deployment Review); Matt Lyons (demystifying code access security); Caesar Samsi; Erik Olson (extensive validation and recommendations on ASP.NET); Andres De Vivanco (securing SQL Server); Riyaz Pishori (Enterprise Services); Alan Shi; Carlos Garcia Jurado Suarez; Raja Krishnaswamy, CLR Development Lead; Christopher Brown; Dennis Angeline; Ivan Medvedev (code access security); Jeffrey Cooperstein (Threat Modeling); Frank Swiderski; Manish Prabhu (.NET Remoting); Michael Edwards, MSDE; Pranish Kumar, (VC++ PM); Richard Waymire (SQL Security); Sebastian Lange; Greg Singleton; Thomas Deml (IIS Lead PM); Wade Hilmo (IIS); Steven Pratschner; Willis Johnson (SQL Server); and Girish Chander (SQL Server).
    • Microsoft Consulting Services and Product Support Services (PSS): Ilia Fortunov (Senior Architect) for providing continuous and diligent feedback; Aaron Margosis (extensive review, script injection, and SQL Injection); Jacquelyn Schmidt; Kenny Jones; Wade Mascia (Web Services and Enterprise services); Aaron Barth; Jackie Richards; Aaron Turner; Andy Erlandson (Director of PSS Security); Jayaprakasam Siddian Thirunavukkarasu (SQL Server security); Jeremy Bostron; Jerry Bryant; Mike Leuzinger; Robert Hensing (reviewing the Securing series); Gene Ferioli; David Lawler; Jon Wall (threat modeling); Martin Born; Michael Thomassy; Michael Royster; Phil McMillan; and Steven Ramirez.
    • Special Thanks To: Joel Scambray; Rich Benack; Alisson Sol; Tavi Siochi (IT Audit); Don Willits (raising the quality bar); Jay Nanduri (Microsoft.com) for reviewing and sharing real world experience; Devendra Tiwari and Peter Dampier, for extensive review and sharing best IT practices; Denny Dayton; Carlos Lyons; Eric Rachner; Justin Clarke; Shawn Welch (IT Audit); Rick DeJarnette; Kent Sharkey (Hosting scenarios); Andy Oakley; Lucas Lavarello; Vijay Rajagopalan (Dev Lead MS Operations); Gordon Ritchie, Content Master Ltd; Chase Carpenter (Threat Modeling); Matt Powell (for Web Services security); Joel Yoker; Juhan Lee [MSN Operations]; Lori Woehler; Mike Sherrill; Mike Kass; Nilesh Bhide; Rebecca Hulse; Rob Oikawa (Architect); Scott Greene; Shawn Nandi; Steve Riley; Mark Mortimore; Matt Priestley; and David Ross.
    • Editors: Sharon Smith; Kathleen Hartman (S&T OnSite); Tina Burden (Entirenet); Cindy Riskin (S&T OnSite); and Pat Collins (Entirenet) for helping to ensure a quality experience for the reader.
    • patterns & practices team members: Naveen Yajaman; Philip Teale; Scott Densmore; Ron Jacobs; Jason Hogg; Per Vonge Nielsen; Andrew Mason; Edward Jezierski; Michael Kropp; Sandy Khaund; Shaun Hayes; Mohammad Al–Sabt; Edward Lafferty; Ken Perilman; and Sanjeev Garg (Satyam Computer Services).

    Building Secure ASP.NET Applications

    • Home Page: http://msdn.microsoft.com/en-us/library/aa302415.aspx
    • Authors: J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
    • Contributors and reviewers: Manish Prabhu, Jesus Ruiz-Scougall, Jonathan Hawkins and Doug Purdy, Keith Ballinger, Yann Christensen and Alexei Vopilov, Laura Barsan, Greg Fee, Greg Singleton, Sebastian Lange, Tarik Soulami, Erik Olson, Caesar Samsi, Riyaz Pishori, Shannon Pahl, Ron Jacobs, Dave McPherson, Christopher Brown, John Banes, Joel Scambray, Girish Chander, William Zentmayer, Shantanu Sarkar, Carl Nolan, Samuel Melendez, Jacquelyn Schmidt, Steve Busby, Len Cardinal, Monica DeZulueta, Paula Paul, Ed Draper, Sean Finnegan, David Alberto, Kenny Jones, Doug Orange, Alexey Yeltsov, Martin Kohlleppel, Joel Yoker, Jay Nanduri, Ilia Fortunov, Aaron Margosis (MCS), Venkat Chilakala, John Allen, Jeremy Bostron, Martin Petersen-Frey, Karl Westerholm, Jayaprakasam Siddian Thirunavukkarasu, Wade Mascia, Ryan Kivett, Sarath Mallavarapu, Jerry Bryant, Peter Kyte, Philip Teale, Ram Sunkara, Shaun Hayes, Eric Schmidt, Michael Howard, Rich Benack, Carlos Lyons, Ted Kehl, Peter Dampier, Mike Sherrill, Devendra Tiwari, Tavi Siochi, Per Vonge Nielsen, Andrew Mason, Edward Jezierski, Sandy Khaund, Edward Lafferty, Peter M. Clift, John Munyon, Chris Sfanos, Mohammad Al-Sabt, Anandha Murukan (Satyam), Keith Brown (DevelopMentor), Andy Eunson, John Langley (KANA Software), Kurt Dillard, Christof Sprenger, J.K.Meadows, David Alberto, Bernard Chen (Sapient)
  • J.D. Meier's Blog

    Lessons Learned in 2008

    • 5 Comments

    I posted my Lessons Learned in 2008 on Sources of Insight.  2008 was a pretty insightful year for me.  I met a lot of great people, read a lot of books, and learned a lot along the way.  I recapped my top 10 lessons here.

    Top Ten Lessons for 2008

    • Adapt, adjust, or avoid situations. Learn how to read situations. Some situations you should just avoid.  Some situations you should adapt yourself, as long as you play to your strengths.  Some situations you should adjust the situation to set yourself up for success.  See The Change Frame.
    • Ask questions over make statements.  If you want to get in an argument, make statements.  If you want to avoid arguments, ask questions.
    • Character trumps emotion trumps Logic.  Don’t just go for the logical win.  Win the heart and the mind follows.  Build rapport.  Remember the golden rule of “rapport before influence.  Have the right people on your side.   If you win the right pillars first, it’s a domino effect.  It’s part of social influence.  See Character Trumps Emotion Trumps Logic.
    • Develop a routine for exceptional thinking.  Create a preperformance routine that creates consistent and dependable thinking.  Work backwards from the end in mind.  Know what it’s like when you’re at your best.  Model from your best experiences.  Success leaves clues.  Turn them into a routine.  Set time boundaries.  Don’t let yourself take as long as it takes.  Work has a way of filling the available hours. Set a timebox and improve your routine until you can shift gears effectively within your time boundaries.  See Design a Routine for Exceptional Thinking.
    • Give your best where you have your best to give.   Design your time to spend most of your time on your strengths.  Limit the time you spend in your weaknesses.   Play to your strengths.  When you play to your strengths, if you get knocked down, it’s easier to get up again.  It’s also how you unleash your best.  See Give Your Best Where You Have Your Best to Give.
    • Label what is right with things.  There’s been too much focus on what’s wrong with things.  Find and label what’s right with you.  We all have a deep need to know what’s right with us.  Shift from labeling what’s wrong, to labeling what’s right. See Label What is Right with Things.
    • One pitch at a time.  Focus on one pitch at a time.  Hook on to one thing.  Be absorbed in the moment, no matter what’s at stake.  Let results be the by-product of what you’re doing.  Don’t judge yourself while you’re performing.  Don’t rearrange your work; rearrange your focus.  See One Pitch at a Time.
    • Spend 75 percent on your strengths.  Very few people spend the majority of their time on their strengths.  Create timeboxes for your non-negotiables.  You’re not your organization’s greatest asset until you spend your time on your strengths.  Activities that you don’t like, hurt less, if you compartmentalize them to a smaller chunk of your day.  See Spend 75 Percent on Your Strengths.
    • Ask Solution-focused questions.   Ask things like “how do we make the most of this?” … “what’s the solution?” … “if we knew the solution, what might it be?”  Believe it or not, a lot of folks get stuck unless you add the “if you did know the solution …” or “what might it be?”  See Solution-Focused Questions.
    • Use stress to be your best.  It’s not what happens to you, it’s what you make of it.  Distinguish stress from anxiety.  Stress is your body’s response.  Anxiety is your mind’s response.   See Use Stress to Be Your Best.
  • J.D. Meier's Blog

    The Zen of Zero Mail

    • 14 Comments

    You too can have a zero mail inbox, if you choose to.  I chose to go zero mail in my inbox when I first joined Microsoft years ago, and I'm glad I did.  With a single glance, I know whether I have new mail to deal with.  I never have to scroll to see what my next actions are.   At a more basic level, an empty inbox feels good.  I thought it was just me, but others say the same. 

    Proven Over Time
    It was tough when I first joined Microsoft.  My inbox drove me.  Eventually, I learned how to drive my inbox.  I studied the masters around me.  I also studied those that failed (there's no failure, only lessons.)  I refined my approach over the years.  Since then, I've successfully taught my mentees and others how to spend less time on administration and more time on results.  Now I'm sharing with you.

    Slides
    Here's a short deck that steps you through and highlights the keys:

    Note
    Normally, I work with my mentees one-on-one and tailor the approach for their particular scenario.  It's a learning by doing approach.  While I've blogged about clearing your inbox before, this is an experiment in how effectively I can share techniques in slides.  If it works out, I'll do additional slides on focused topics.  The more I can reduce friction around sharing, the more I can share.  If you have tips or tricks for improving my slide sharing approach, send my way.

  • J.D. Meier's Blog

    Software Architecture Best Practices at a Glance

    • 3 Comments

    Today we posted our updated software architecture best practices at a glance to CodePlex, as part of our patterns & practices Application Architecture Guide 2.0 project:

    They’re essentially a brief collection of problems and solutions around building software applications.  The answers are short and sweet so that you can quickly browse them.  You can think of them as a bird’s-eye view of the problem space we tackled.  When we add them to the Application Architecture Guide 2.0, we'll provide quick links into the guide for elaboration.

    This is your chance to bang on the set of problems and solutions before Beta 2 of the guide.

  • J.D. Meier's Blog

    Writing Books on Time and on Budget

    • 1 Comments

    AppARch2.0_small

    One of the questions I get asked is how did we execute our patterns & practices Application Architecture Guide 2.0 project, on time and on budget?  It was a six month project, during which we ....

    2 Keys to Success
    We used two keys to success:

    • Fix time, Flex scope
    • Agile Guidance Engineering

    Fix Time, Flex Scope
    One of the most successful patterns I've used for years now is to fix time, and flex scope.  The idea is to deliver incremental value and find a way to flow value along the way rather than wait for one big bang at the end.  This allows you to deliver the most timely and relevant value with a healthy worklife balance.  It helps reduce project risk along the way.  More importantly, it helps get your stakeholders on board, by showing them results versus just trust you to the end.  Scope is the best to flex because there's the least amount of precision or accuracy up front, and it enables you to respond to the market or stakeholder concerns more effectively.

    Agile Guidance Engineering
    This is the secret sauce.  I call it Agile Guidance Engineering:

    AgileGuidanceEngineering2

    In a nutshell, Agile Guidance Engineering is about building guidance using nuggets of specific types (how tos, guidelines, checklists ... etc.) and composing them into books.  The books themselves are actually an information model.  The information model is designed to both structure the content as well as structure the problem domain.  We vet the nuggets as we go for feedback, and we prioritize, tune, and improve them along the way.

    I've used Agile Guidance Engineering successfully to build the following Microsoft patterns & practices Blue Books:

    My Related Posts

  • J.D. Meier's Blog

    MSF Agile Persona Template

    • 1 Comments

    I was looking for examples of persona templates, and I came across Personas: Moving Beyond Role-Based Requirements Engineering by Randy Miller and Laurie Williams.  I found it to be insightful and practical.  I also like the fact they included a snapshot of a persona template example from MSF Agile ...

    MSF Agile Persona Template

    • Name - Enter a respectful, fictitious name for the persona.
    • Status and Trust Level - Favored or disfavored and level of credentials.
    • Role - Place the user group in which the persona belongs.
    • Demographics - Age and personal details optional Goals, motives and concerns.
    • Knowledge, skills and abilities - Group real but generalized information about the capabilities of the persona.
    • Goals, motives, and concerns - Describe the real needs of the users in the user group represented by the persona. If multiple groupings exist, write a persona for each grouping.
    • Usage Patterns - Write the frequency and usage patterns of the system by the persona. Develop a detailed understanding of what functions would be most used. Look for any challenges that the system must help the persona overcome. Note the learning and interaction style if the system is new. Does the persona explore the system to find new functionality or need guidance? Keep this area brief but accurate.
  • J.D. Meier's Blog

    Agile Guidance

    • 2 Comments

    When I ramp new folks on the team, I find it helpful to whiteboard how I build prescriptive guidance.  Here's a rough picture of the process:

    AgileGuidanceEngineering2

    Examples
    I've used the same process for Performance Testing Guidance, Team Development with Visual Studio Team Foundation Server, and WCF Security.

    Here's a brief explanation of what happens along the way:

    Design
    The dominant focus here is identifying candidate problems, candidate solutions, and figuring out key risks, as well as testing paths to explore.  The best outcome is a set of scenarios we can execute against.

    • Research - finding the right people, the right problems, and the right solutions.
    • Prototypes - experiment and test areas of high risk to prove the path.  This can include innovating on how we build prescriptive guidance.  We also use these to test with customers and get feedback on the approach.
    • Question Lists - building organized lists of one-liner user questions.
    • Task Lists - building organized lists of one-liner user tasks.
    • Scenario Frames - organizing scenarios into meaningful buckets.  See Scenario Frame Example.
    • Information Models - framing out the problem space and creating useful ways to organize, share, and act on the information.  See Web Services Security Frame.
    • Guidance Types  - testing which guidance types to use (how tos, checklists, guidelines, patterns, ... etc.)

    Execution
    The dominant focus here is product results.  It's scenario-driven.  Each week we pick scenarios to execute against.

    • Development - building prescriptive guidance, including coding, testing, and writing.
    • Backlog - our backlog is a prioritized set of scenarios and guidance modules.
    • Iterations - picking sets of scenarios to focus development on and test against.
    • Refactoring - tuning and pruning the guidance to improve effectiveness.  This includes breaking the content up and rewriting it.  For example, a common refactoring is factoring reference information from action.  We try to keep reference information in our Explained modules and action information in our How Tos.
    • Testing -  step through the guidance against the scenario.  The first pass is about making sure it works.  It should be executable by a human.  Next, it's about reducing friction and making sure the guidance really hits the what, why and how.  We test the guidance against objectives and scenarios with acceptance criteria so we know when we're done.
    • Problem Repros - creating step by step examples that reproduce a given problem.
    • Solution Repros - creating step by step examples that reproduce a given solution.

    Release
    We produce a Knowledge Base (KB) of guidance modules and a guide.  The guidance modules are modular and can be reused.   The guide includes chapters in addition to the guidance modules.  Here's examples from our WCF Security Guide:

    Agile Publishing
    We release our guidance modules along the way to test reactions, get feedback and reshape the approach as needed.

    • CodePlex - we publish our guidance modules to CodePlex so we can share early versions of the guidance and get customer feedback, as well as to test the structure of the guidance, and experiment with user experience.
    • Guidance Explorer - we publish guidance modules to Guidance Explorer so users can do their own guidance mash ups and build their own personalized guides.  Our field also uses this to build customized sets of guidance for customers.

    Stable Reference
    Once we've tested and vetted the guidance and have made it through a few rounds of customer feedback, we push the guidance to MSDN.

    • MSDN - this is the trusted site that users expect to see our prescriptive guidance in final form.
    • Visual Studio/ Visual Studio Team System - once we're a part of the MSDN distribution, we can automatically take advantage of the VS/VSTS documentation integration.

    My Related Posts

  • Page 4 of 43 (1,064 items) «23456»