J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    patterns & practices Security Videos

    • 8 Comments

    We did a focused set of security videos with Keith Brown a while back.  The problem is they're not very findable (most customers I talk to aren't aware of them).  I added them to soapbox and listed them below to see if it helps (note soapbox may prompt you to log in):

    Input and Data Validation Videos

    They're designed to help you get key concepts behind some of our security guidance.   I also wanted to use somebody that was recognized in the field as somebody you could trust.  Keith's proven himself for a long time in the security community.  He also has the aura of an experienced trainer, which I think comes across in these videos.

  • J.D. Meier's Blog

    How patterns and practices Does Source Control with Team Foundation Server (TFS)

    • 8 Comments

    We've used TFS for more than a year, so it's interesting to see what we're doing in practice.  If you looked at our source control, you'd see something like the following:

    + Project X version 1
    + Project X version 2
    - Project Y
        |----Branches
        |----Releases
        |----Spikes
        |----TeamStuff
        |----Trunk
            |----Build
            |----Docs
            |----Keys
            |----Source
            |----Tools

    While there's some variations across projects, the main practices are:

    • Major versions get their own team project (Project X version 1, Project X version 2 ...)
    • The "Trunk" folder contains the main source tree.
    • Spikes go in a separate "Spikes" folder -- not for shipping, but are kept with the project.
    • QFEs use "Branches".  Branches are effectively self-contained snapshots of code.
    • Bug fixes go in the main "Source" under the "Trunk" folder
    • If we're shipping a CTP (Customer Tech Preview) next week, but we have a good build for this week.  We create a "shelveset" for the CTP.  
    • Within each release we have a number of Customer Tech Preview (CTP) releases, we "Label" those within the structure so we can go back and find at any point in time

    I'll be taking a look at how customers and different groups in Microsoft have been using TFs for Source Control.  If you have some practices you'd like to share, I'd like to hear them.  Comment here or send mail to VSGuide@microsoft.com

  • J.D. Meier's Blog

    Test-Driven Guidance

    • 8 Comments

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

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

    Test Cases for Guidelines

    Title

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

    Applies To

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

    What to Do

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

    Why

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

    When

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

    How

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

    Problem Example

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

    Solution Example

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

    Additional Resources

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

    Related Items

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

    Additional Tests to Consider When Writing a Guideline

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

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

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

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

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

  • J.D. Meier's Blog

    ASP.NET 2.0 Internet Security Reference Implementation

    • 8 Comments

    The ASP.NET 2.0 Internet Security Reference Implementation is a sample application complete with code and guidance.  Our purpose was to show patterns & practices security guidance in the context of an application scenario. We used Pet Shop 4 as the baseline application and tailored it for an internet facing scenario.  The application uses forms authentication with users and roles stored in SQL.

    Home Page/Download

    3 Parts
    The reference implementation contains 3 parts:

    1. VS 2005 Solution and Code 
    2. Reference Implemenation Document
    3. Scenario and Solution Document 

    The purpose of each part is as follows:

    1. VS 2005 Solution and Code - includes the Visual Studio 2005 solution, the reference implementation doc, and the scenario and solution doc.
    2. Reference Implemenation Document (ASP.NET 2.0 Internet Security Reference Implementation.doc) - is the reference implementation walkthrough document containing implementation details and key decisions we made along the way.  Use this document as a fast entry point into the relevant decisions and code.
    3. Scenario and Solution Document (Scenario and Solution - Forms Auth to SQL, Roles in SQL.doc) - is the more general scenario and solution document containing key decisions that apply to all applications in this scenario.

    Key Engineering Decisions Addressed
    We grouped the key problems into the following buckets:

    • Authentication
    • Authorization
    • Input and Data Validation
    • Data Access
    • Exception Management
    • Sensitive Data
    • Auditing and Logging

    These are actionable, potential high risk categories.  These buckets represent some of the more important security decisions you need to make that can have substantial impact on your design.  Using these buckets made it easier to both review the key security decisions and to present the decisions for fast consumption.

    Getting Started

    1. Download and install the ASP.NET 2.0 Internet Security Reference Implementation.
    2. Use ASP.NET 2.0 Internet Security Reference Implementation.doc to identify the code you want to explore
    3. Open the solution, Internet Security Reference Implementation.sln, and look into the details of the implementation
    4. If you're interested in testing SSL, then follow the instructions in  SSL Instructions.doc.

     

  • 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

    The Agile Way

    • 8 Comments

    Change happens. One of the many things Ward Cunningham taught me years ago was that Agile isn't about fast.  It's about "responding to change."  It's the Agile way.   

    I thought it was great that rather than pretend change doesn't happen, simply embrace it.

    Simplicity was another aspect that I found compelling.  Ward had a way to keep things simple.  If something felt heavy or complicated, he would cut right through -- "What's the simplest thing we can do now?"  Rather than get overwhelmed or lost in analysis paralysis, he simply decides to take action.

    I remember thinking how sweet it is to put your burden down, and travel light.

    One burden for me was all the stuff that was yet to be done.  The other burden was all the stuff that might matter someday.  The problem is, how do you plan for what you don't know or can't expect?  You don't.  Instead, you figure out the most valuable thing now to work on, and when you come to a bridge, you cross it.  When there's no bridge, you build one.  If that becomes the next most important thing now.

    The sense of now vs. someday maybe is important.  There's something empowering about knowing that you're on the right path, and that the path you're on flows value -- to yourself, for others, or whatever matters.  Mistakes turn into lessons, and success builds momentum. Paving a path of value down a road of learning and responding beats betting on a map that no longer works or is no longer relevant.

    Speaking of relevancy, time changes what's important.  All the things we think we know, and all the things we thing we want, don't always match what we find, once we're there.  The ladder may be up against the wrong wall, or the grass isn't any greener.  In fact, sometimes there's no grass.

    The irony is, the trip is lighter when we don’t carry the burden, and the trip mean more when we know it matters.  If we don't enjoy the journey, and we don't end up with what we want, what's the point?  Life's short.  Throwing your time and energy down a path should matter.  But, how do we carve out these paths that matter?

    Stories.  Stories help you find what matters.  I remember the first time Ward asked me to tell him a story.  He wasn't looking for once upon a time.  No, he wanted to explore and test possible paths.  He wasn't interested in a laundry list of requirements.  He wanted a simple story told from the user perspective of a single, meaningful goal.  We used the whiteboard and mapped out one scenario.  Disney would have been proud.

    This one chunk of value was compelling.  The story put things in context.  The flow made sense.  Value was obvious and explicit.  More than that, it was testable.  A testable chunk of value.  We could test whether it mattered, and we could test whether it was feasible.  We could even test the risk early and reduce the gap from what we know, don't know, and need to know next.

    Having a story helped us do a dry run.  The dry run produced immediate feedback.  Feedback is a good thing, and it supports learning and responding, the Agile way.

    All this goodness in approach, painted a better picture, of a better way forward.  Rather than over-engineer up front, or over-plan for some day maybe, start flowing value now.  Rather than travel with burden and assumptions, travel lightweight and sustainable.  Rather than fear change, allow for it, and embrace it – be adaptable.  But does this approach to work, also work for life?

    I asked Ward how he did his career planning and figured out his year ahead.  He said he simply works backward from the experiences he wants.  He writes his story forward, by focusing on the experiences he wants to create.  He leads an experience-driven life.  What a simple, yet elegant, and insightful approach.  What an empowering way forward.

    The journey is the trip and the destination.  It's the way we travel and it's the end in mind.  It's the Agile way.

    This is why my latest book is Getting Results the Agile Way.

  • J.D. Meier's Blog

    ASP.NET Security Scenarios on Azure

    • 8 Comments

    As part of our patterns & practices Azure Security Guidance project, we’re putting together a series of Application Scenarios and Solutions.  Our goal is to show the most common application scenarios on the Microsoft Azure platform.  This is your chance to give us feedback on whether we have the right scenarios, and whether you agree with the baseline solution.

    ASP.NET Security Scenarios on Windows Azure
    We’re taking a crawl, walk, run approach and starting with the basic scenarios first.  This is our application scenario set for ASP.NET:

    • ASP.NET Forms Auth to Azure Storage
    • ASP.NET Forms Auth to SQL Azure
    • ASP.NET to AD with Claims
    • ASP.NET to AD with Claims (Federation)

    ASP.NET Forms Auth to Azure Storage

    Scenario

    image

    Solution

    image

    Solution Summary Table

    Area Notes
    Authentication
    • ASP.NET application authenticates users with Forms authentication.
    • ASP.NET accesses the membership store through the TableStorageMembershipProvider.
    • ASP.NET authenticates against Azure Storage using a shared key.
    Authorization
    • ASP.NET accesses the Role store in Azure Storage through the TableStorageRoleProvider.
    • ASP.NET application performs role checks.
    Communication
    • Protect credentials over the wire using SSL.
    • A shared key protects communication between ASP.NET and Azure Storage.

    ASP.NET Forms Authentication to SQL Azure

    Scenario

    image

    Solution

    image

    Solution Summary Table

    Area Notes
    Authentication
    • Authenticate users with Forms Authentication.
    • Store users in SQL Azure.
    • ASP.NET connects to SQL Azure using a SQL user account.
    • Application identity is mapped to SQL account.
    Authorization
    • Store roles in SQL Azure.
    • ASP.NET checks roles through the SqlRoleProvider.
    Communication
    • Protect credentials over the wire with SSL.
    • ASP.NET connects to SQL Azure over port 1433
    • SQL authentication occurs over secure TDS.
    • SQL connections are configured to screen IP addresses to expected client app addresses.

    ASP.NET to AD with Claims

    Scenario

    image

    Solution

    image

    Solution Summary Table

    Area Notes
    Authentication
    • Authenticate users against Active Directory.
    • Obtain user credentials as claims.
    • Use ADFS to provide claims.
    • Authenticate users in application using claims.
    • Use Windows Identity Foundation in ASP.NET app to manage SAML tokens.
    Authorization
    • Authorize users against claims.
    • Authorize in application logic.
    • Store additional claims beyond what AD can provide in a local SQL server.
    Communication
    • Claims are passed using WS-* protocols.
    • Protect claims over the wire using Security Assertion Markup Language (SAML)
    • Protect SAML tokens with SSL

    ASP.NET to AD with Claims (Federation)

    Scenario

    image

    Solution

    image

    Solution Summary Table

    Area Notes
    Authentication
    • Authenticate client browser against Active Directory.
    • Obtain user credentials as claims.
    • Use Active Directory Federation Services (ADFS) to provide claims.
    • Authenticate users in application using claims.
    • Establish trust relationship between ASP.NET app and Azure hosted Secure Token Service (STS).
    • Establish trust relationship between ADFS and Azure STS.
    Authorization
    • Authorize users against claims.
    • Authorize in application logic.
    • Store additional claims beyond what AD can provide in a local SQL server.
    Communication
    • Claims are passed using WS-*protocols.
    • Protect claims over the wire using Security Assertion Markup Language (SAML).
    • Protect SAML tokens with SSL.
  • J.D. Meier's Blog

    Microsoft Application Architecture Guide 2.0 Impact

    • 8 Comments

    It's a platform, a playbook, and a language for application architecture.

    ArchitectureMetaFrame_2

    At a high level, that's how I think about our patterns & practices Application Architecture Guide and Application Architecture KB.

    The work has become a focal point both internally and externally as a playbook for the Microsoft application platform.  It’s less of a guide, and more of a platform.  Essentially, we’ve framed out a durable, evolvable backdrop for application architecture that we can build on in terms of products, tooling, services and experiences.  I get daily/weekly mails from folks inside and outside the company that want to align their efforts with the frames and approach. 

    I think of the frames as collection of hot spots.  The frames help cut through information overload and provide a common mental model.  They also help identify hot spots in architecture and design that are opportunities for improvement.  They also help map existing bodies of pattern work to relevant decisions that shape applications.

    Here's a few data points that I think highlight the impact:

    • As of today, we’re the #5 and #9 position in terms of downloads out of 7,328 projects.
    • As of today, we're #9 and #16 in terms of page views out of 7,328 projects on CodePlex.
    • Grady Booch says we’ve defined a language for describing our classes of applications.  See Grady Booch on the Microsoft Application Architecture Guide 2.0.
  • J.D. Meier's Blog

    Web Application with Domain Entity Application Pattern

    • 8 Comments

    We created a Web Application with Domain Entity Application Pattern as part of our patterns & practices Application Architecture Guide 2.0 project.  The purpose is to show a baseline architecture based on patterns.

    Scenario
    Here's the backdrop we use for the baseline architecture:

    Scenario

    Pattern Solution
    Here's our pattern overlay:

    PatternsSolution (2)

    Tech Solution
    Here's our technology overlay:

    TechnicalSolution

    Application Pattern
    You can review the full application pattern on CodePlex at:

    Feedback

    1. What are 3 things you like about the approach?
    2. What are 3 things you would improve?
  • J.D. Meier's Blog

    RIA Architecture Pocket Guide

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

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

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

    Download

    My Related Posts

  • J.D. Meier's Blog

    Choosing the Right Presentation Technology

    • 8 Comments

    How do you choose among the Microsoft .NET presentation technologies?  Use scenario-based evaluation.  At the end of the day, a technology is a set of capabilities. Map those capabilities to your scenario and requirements.  OK, great, but where do you start?  That's where our cheat sheet comes in.  As part of our Application Architecture Guidance 2.0 project, we created a cheat sheet to help you quickly find your way through the technologies:

    Cheat Sheet – Presentation Technology Matrix
    We posted our latest cheat sheet to CodePlex:

    Presentation Technologies
    Here’s the technology combinations that we identified, evaluated and cataloged:

    • ASP.NET Dynamic Data
    • ASP.NET Mobile
    • ASP.NET MVC
    • ASP.NET Web Forms
    • ASP.NET Web Forms with AJAX
    • ASP.NET Web Forms with Silverlight Controls
    • Compact Framework
    • Silverlight
    • Silverlight with AJAX
    • Silverlight Mobile
    • Windows Forms
    • Windows Forms with WPF User Controls
    • WPF Application
    • WPF with Windows Forms Controls
    • XAML Browser Application (XBAP) using WPF

    That’s a lot of options, but that’s a good thing.  In a mature market, expect lots of options and specialization.  This helps you use the right tool for the job.  The challenge, of course, is knowing which one is the right tool, but that’s where our cheat sheet should help.  Ultimately, the cheat sheet is a support aid and doesn’t replace your own thinking or analysis.  Instead, it helps you consolidate some key information on the technologies, and help you consider some of the benefits and considerations.

    Organizing the Technologies
    To organize the technologies, we use a simple frame:

    • Technology Summary
    • Benefits and Considerations Matrix
    • Common Scenarios and Solutions

    By pinning the technologies against common application types (Mobile, Rich Client, RIA, and Web App), it made it very easy for us to slice and dice the technologies by relevancy, capabilities, and scenarios.

    How We Created the Cheat Sheet

    We started from a base set of application types and scenarios.  We vetted from experience among the p&p development team.  Next, we reviewed with various product team members, including Brad Abrams, Pat Helland, Glenn Block, and Ian Ellison-Taylor.  Next we vetted with some customers.  It’s a work in progress and we’ve been through several iterations.  In fact, the version we posted today is version 35.   Now it’s time to share with a broader community.

    My Related Posts

  • J.D. Meier's Blog

    App Arch Guide 2.0 Overview Slides

    • 8 Comments

    I added a brief over deck of our patterns & practices App Arch Guide 2.0 project to codeplex:

    It's actually a pretty fast slide deck.  The first handful of slides give you a quick overview of the project goals and scope.  The appendix is all visual.  You can flip through and see how some of the key parts of our story are unfolding.

    My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • Abstract for Application Architecture Guide 2.0
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Components
  • Key Software Trends
  • J.D. Meier's Blog

    Guidelines are Live!

    • 8 Comments

    We posted an early draft of our guidelines for the following areas:

    You can browse our set of guidelines from our Guidelines Index page.

    This is part of our patterns & practices App Arch Guide 2.0 Project.

    My Related Posts

  • J.D. Meier's Blog

    Leaving patterns & practices

    • 8 Comments

    image“Life is like skiing.  Just like skiing, the goal is not to get to the bottom of the hill. It’s to have a bunch of good runs before the sun sets.” – Seth Godin

    It's been a good run.  After more than 10 years in patterns & practices, I'm on to my next adventure here at Microsoft.

    For this post, I wanted to take a stroll down memory lane.  During my time at patterns & practices, I learned more about project management, application architecture, software development, processes, teamwork, leadership, product success, and making impact than I think I could have ever hoped to learn anywhere else.  Perhaps the best part, is that I have 10+ years of deliberate practice in the art of “best practices” and I’ve had a chance to work with some of the most amazing people in the industry, lead SWAT teams around the world on fantastic voyages and epic adventures, and leave a legacy of several high-impact Microsoft Blue Books, all while mastering the art of prescriptive guidance.

    There are a few ways I can share my journey in patterns & practices.  One of my managers referred to me as “the abilities PM” because of my focus on quality attributes (security, performance, scalability, etc.)  and that’s a pretty good place to start.  My role as a PM (Program Manager) in patterns & practices, can largely be defined in terms of my impact on these three areas: security, performance, and application architecture.  (Yes, there is more to the story, but those three areas, serve as a good enough lens for now.)

    The Security Story
    It all started when I joined patterns & practices (PAG or the Prescriptive Architecture Guidance team at the time.) 

    image

    I moved from Microsoft Developer Support with the expectation that I would share and scale broadly with customers what I learned from living in across the hall from folks like Scott Guthrie, Brad Abrams, and other .NET Framework leaders.  Having performed more than 650 customer architecture and design reviews, I was in a unique position to share all the principles, patterns, practices, and anti-patterns that I had seen across a large number of customer projects, many of which were on the leading and bleeding edge of this space.

    But life has a way of throwing curve balls.  Around this time, security was Jim Allchin’s top priority, and he asked patterns & practices what we were going to do about security.  In turn, my manager asked me, what I was going to do about security.  Coming from a middleware background, security was something I was usually trying to work around, especially when I had to flow callers to the backend.  My new challenge was to design security architectures for our application platform on .NET.  Boy, was I in for a ride.

    I knew security was the name of the game, but I had a lot to learn in terms of leading project teams around the world, brokering in all the right parts of the company, our community, and the industry.  I also had a lot to learn in terms of how to create prescriptive guidance.  The purpose was not to just put out a book.  The purpose was to drive customer success on the platform.  This included creating a durable, and evolvable security story that our customers could build on, and that we could use to “train the trainers.”  This also meant creating a knowledge base that we could use as an anchor for driving product feedback and platform change.  This was all in addition to learning how to think about security from an architecture and design standpoint, in a way that could help customers build more secure applications.

    And thus the first Microsoft Blue Book, Building Secure ASP.NET Applications, was born.  It was our answer to IBM Redbooks.

    While I learned a lot from doing end-to-end security architectures and putting our variety of products and technologies together, the real learning came from driving Improving Web Application Security, or “Threats and Countermeasures”, as we affectionately called it.  This journey was about learning how to bridge the gap between architecture and design, development, test, and operations.  It was about learning how to think about security from a threats, attacks, vulnerabilities, and countermeasures perspective.  It was about thinking about security in a more holistic way, and our little mantra was “secure the network, host, and app.”

    We had the ultimate security dream team, on mission impossible, and we pulled it off.  Our core engineering team included Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, and we had an extended team  of industry champs including Joel Scambray of the Hacking Exposed series.  (In fact, check out the extensive team list at the bottom of our Threats and Countermeasures Landing Page.)

    How do I know we pulled it off?  We had outstanding results in our platform security competitive study, and we were told that is was our prescriptive guidance that made the difference in a very big way.  In addition, our guide was downloaded more than 800,000 times in the first six months, and it quickly established the mental models and language for how our growing customer base thought about security on the .NET platform.  It was a powerful thing when customers would say to us back in our language, “We’re using the trusted subsystem model  …”  It was like poetry in motion.

    The big thing we learned from the journey was the power of having end-to-end application scenarios, along with maps of threats and countermeasures, while baking security into the life cycle, and using proven practices, like threat modeling, to significantly change the game.

    Here are some of the key security deliverables at a glance from the various security adventures over the years:

    This doesn’t include the product feedback work we did, or the work we did to bake security into Visual Studio / MSF Agile, or the patents we filed, which were the icing on the cake.  As a sidenote, behind the scenes we called our “threats and countermeasures” guide “WOMA.”  It was short for weapon-of-mass adoption, because our field was continuously telling us stories of how they were winning accounts against the competition.

    The Performance Story
    Performance was right up my alley, but it was a significant shift from security. 

    image

    Ironically, I got a lot better at tackling security, by learning more about performance.  The big lesson I learned was that you have to bound or constrain your efforts in some way.  Just like performance can always be improved, so can security, so it’s all about prioritizing, knowing where to focus, and connecting back to the business objectives, aside from the technical perspective, and user experience.

    Our first epic adventure in the performance space was the guide, Improving .NET Application Performance and Scalability (or, “Perf and Scale” as we affectionately called it.)   It was where I first got to work with folks like Rico Mariani, Jan Gray, and Gregor Noriskin.   It was mind blowing. 

    Working on performance and scalability was probably the most technically challenging exercise I’ve had at Microsoft.  I remember spending countless days and nights walking through CLR internals, figuring out how to optimize collections, sorting through multi-threading patterns, and mastering how garbage collection really worked.  Strangely enough, the “ah-ha” that I appreciated the most was figuring out that we could think of performance in terms of response time, throughput, and resource utilization (CPU, memory, network, and disk.)  That little lens was the key to figuring out how to do effective performance modeling and solving nasty performance bottlenecks.  It also helped us parse complicated performance scenarios down into bite-sized chunks.

    Here are some of the key performance deliverables at a glance from the various performance adventures over the years:

    While performance took me to the depth of things, it was application architecture that took me to the breadth of things …

    Application Architecture
    Creating the Microsoft Application Architecture Guide was a chance to pull it all together.

    image

    It was a chance to finally showcase how to put our platform technologies together into common application archetypes.  Rather than just a bunch of technologies, we could talk about our application platform very specifically in terms of application types: Web applications, RIA applications, desktop applications, Web services, and mobile applications.  We could talk about scenarios and trade-offs.  We could look at the shapes of applications in terms of architectural styles and patterns.  We could look at cross-cutting concerns, such as caching, communication, concurrency, configuration management, data access, exception management, logging, state management, validation, and workflow.  We could also walk the various quality attributes, like performance, security, reliability, manageability, usability, etc.

    As you can imagine, this meant putting together a comprehensive map of our Microsoft application platform.  The surprise for me was that by putting together the map and looking broadly at the industry, it was easy to see the forest from the trees, as well as better understand and anticipate where the industry was going in terms of what was growing and what was dying.  It was a great way to get ahead of the curve.  In fact, I’ve continued to map out our Microsoft application platform each year, as a way to quickly see the forest from the trees and to figure out where to spend my time.

    During my adventures with application architecture, I got to learn a lot and work with amazing people.   I also learned how to go across a lot of information faster and easier, and bring teams of people along the journey.  The secret was to keep creating maps that helped everybody get on to the same page fast.  This was an invaluable approach as our team was hunting and gathering all the pattern collections we could find.  We basically built a large catalog and constellation of application patterns in the form of maps.  While we didn’t include our maps in the guide, they helped our team and extended team ramp up in various spaces very quickly, as well as advance the practice of application architecture.  Basically, we could browse patterns of solutions at a glance.

    If you read nothing else, check out A Technique for Architecture and Design.  Behind the scenes, we created this technique by synthesizing the expertise of more than 30 top solution architects, that had years of experience with structuring and designing end-to-end applications, dealing with security, performance, and reliability issues, and dealing with cross-cutting concerns.  The idea was to put down on paper, a proven practice for rapidly modeling applications on a whiteboard and identify risks earlier vs. later.  

    What’s Next?
    I’ll have more to share as I go along.   What you’ll most likely see is a shift to more focus on strategy, execution, and business impact.  I’ll also share more information on the art and science of program management.   I’ve been mentoring a lot of people and I think the PM role at Microsoft is a very special one.  One of my mail goals is to broadly share the lessons I’ve learned from driving projects and leading teams and making impact as a PM on the patterns & practices team.

    patterns & practices Guidance at a Glance
    Meanwhile, here is my catalog of patterns & practices guidance at a glance.  Note that a lot of the prescriptive guidance I’ve worked on is out of date because of changes in technology.  That said, you can still learn many of the key principles, patterns, and practices that  the guidance is based on.  In this respect, much of the guidance is “evergreen” in that it’s timeless and durable.

    Books

    Developer Guidance Maps

    Application Architecture

    Books / Guides

    Methods

    Guidelines

    Checklists

    How Tos

    Performance

    Books / Guides

    Methods

    Guidelines

    Checklists

    Practices at a Glance

    How Tos

    Security

    Guides

    Methods

    Threats and Countermeasures

    Cheat Sheets

    Guidelines

    Checklists

    Practices at a Glance

    Questions and Answers

    Explained

    Application Scenarios

    ASP.NET Security How Tos

    WCF Security How Tos

    Visual Studio Team System

    Guides

    Guidelines

    Practices at a Glance

    Questions and Answers

    How Tos

    My Related Posts

  • J.D. Meier's Blog

    Blessing Sibanyoni on Value Realization

    • 7 Comments

    Value Realization is hot.  You can think of Value Realization as simply the value extracted from a process or project. 

    Business leaders want to understand the benefits they’ll get from their technology solutions.   They also want to see the value of their investment deliver benefits and deliver real results along the way.   And, of course, they also want to accelerate adoption so that they can speed up their value realization, as well as help avoid “value leakage".”

    But how do you actually do Value Realization in the real world? …

    This is a guest post by Blessing Sibanyoni.   Blessing delivers advisory, IT architecture, and planning services to Microsoft’s top enterprise customers within the financial services sector.  He has more than 17 years of experience in the IT field.  He is currently an Enterprise Architect and Strategy Advisor on behalf of Microsoft Corporation. 

    As an Enterprise Strategy Advisor, Blessing helps organizations achieve challenging business and organizational goals.  He does so by helping them leverage value from their current and future investments, enabled by technology.  Blessing has a solid record of delivering large and complex initiatives within organizations while always doing this in a mutually beneficial way.  You can connect with Blessing Sibanyoni on LinkedIn.

    Without further ado, here’s Blessing on Value Realization …

    Value in the Eye of the Beholder

    Often we grapple with the notion of value.  At first it seems like a very simple thing but when you really take time to consider it, you realize how complicated and multi-dimensional it becomes.  Take a simple example of a person who follows a methodology, based on best practices, who crosses all the t’s and dots the i’s but at the end of the day experiences a failed project or is unable to reach goals that his customers appreciate.  Or perhaps, what about the notion of another who is highly intelligent but working for someone far less “intelligent” from a credentials or even IQ perspective. 

    What has happened here?

    Why do these paradoxes occur and how do you ensure you are not ending up experiencing the same?

    The Notion of Value

    I would argue that at the heart of these conundrums is the notion of value.  Value is the worth of something in terms of the amount of other things for which it can be exchanged.  Often it’s not about inputs but rather outcomes and many state that you cannot achieve it without effecting a transformation.  The transformation itself can be virtual or manifested in the real world, but for true value to be derived, transformation in whatever form, must transpire. 

    For transformation to transpire a real pain must be felt.

    Fiercely Competing Alternatives

    After spending almost two decades in public and private enterprises, I’m still intrigued by why organizations decide to spend resources on some things and not others.  Often it’s the thing that seem to make the least sense which these organizations decide to put all their resources into. 

    Why?

    This curiosity is one that lingers on especially realizing that resources are often limited and logically, one would naturally be better positioned by focusing on projects or initiatives that offer more returns and deserve more attention.  One could take the cynical view that common sense is not so common, or the perspective that organizations are made of people, and people are irrational and fallible beings that bring their own biases into every situation. 

    So the notion of value then or the expectation of what will bring value is often subjective and largely determined in the eye of the beholder. 

    Quantitative or Qualitative?

    I have met many stakeholders who are more interested in the qualitative rather than the quantitative.  Surprisingly, this is true, even in financial services! 

    Giving such people a quantitative, seemingly logical justification is often destined to result in failure, and the converse is also true.  So, knowing your stakeholders, what drives and resonates with them is more important that coming up with a definitive, objective, rational and quantitative hypothesis in order to convince them to take some action.

    Recently I was fortunate to have worked with a senior executive who was very financially inclined with a major focus on bottom line impact.  This stakeholder did so well in the organization that he was soon promoted.  To my surprise the person who replaced him was much more people oriented and his biggest concerns were around how the changes proposed would impact people within the organization.  The new stakeholder’s view was that people came first and happy employees result in a positive bottom line effect. 

    I believe both execs had a great view, even though it seemed that their perspectives were fundamentally different. 

    The key for me was to ensure that both qualitative and quantitative arguments were well prepared in advance so that we could tell compelling stories that drove the agenda regardless of the different concerns and viewpoints.

    Know Thy Foe

    Knowing your industry and thinking ahead about what your stakeholders may not yet know that they need or desire, is also a very valuable thing to do. 

    Think about the world of tablet computers that nobody knew they needed just a few years ago, yet these things are now taking the world by storm...

    A Few Lessons Learned in the Trenches

    At the beginning I spoke about blind implementation of a methodology being a less than great thing, I would argue that the following steps make great sense around realizing that value, in the eye of the beholder:

    1. First, seek to understand (Analyze the situation, the pains, problems being experienced and clearly identify who is being impacted – empathy is an important quality!)
    2. Take time to synthesize, communicate back the pain at its essence and color your findings with different perspectives
    3. Ensure you leave behind each interaction, always having taught something new to your customer - even if it’s a small thing. 
    4. Make your plan of action ensuring you focus on what will be high impact and high value to your stakeholder without losing sight of the bigger picture and remaining realistic  
    5. Take action, early and often whilst being nimble and adaptable as necessary
    6. Always endeavor to be mutualistic.  The power of reciprocity really goes a long way!

    You Might Also Like

    Paul Lidbetter on Value Realization

    Martin Sykes on Value Realization

    Mark Bestauros on Value Realization

    Graham Doig on Value Realization

  • 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

    10 Success Patterns for PMs

    • 7 Comments

    Here's a brief set of success patterns I've shared with a few colleagues.  These are the patterns I see that make a difference in getting results.

    10 Success Patterns

    1. Empathic listening.
    2. Rapport before influence
    3. Character trumps emotion trumps logic
    4. Match their style
    5. Ask WIIFY
    6. Distinguish between responsibility and authority
    7. Turn chickens into pigs
    8. Adapt, adjust, or avoid situations
    9. Know the system.
    10. Analyze it over time.

    Success Patterns Explained
    Here's the essence of each:

    • Empathic listening.  Listen until the other person "feels" they've been heard.  Once they feel heard, they're more likely to listen to you.  You can do this 1:1 or in a large meeting.  Covey uses an "Indian Talking Stick."  The person with the stick talks until they feel heard.  A former Softie told me his team used an eraser as "the mutex."   See Stephen Covey Speaks at Microsoft.
    • Rapport before influence.  This is true whether it’s a presentation, interview … etc.. For example, go to a comedy club and see how the comedian gets the crowd laughing only  after they have rapport.  See How Might That Be True?
    • Character trumps emotion trumps logic.  If you base all your arguments on logic, but fail to persuade, now you know.  See Win the Heart, the Mind Follows.
    • Match their style.  You don't have to go overboard, but a little bridge can go along way.  If somebody is visual, could you whiteboard it for them?  If somebody's detail oriented, can you provide the details?  If somebody needs to hear action, can you turn your ideas into action?
    • Ask WIIFY.  Ask the question What's In It For You?  If you're a marketer, this might come natural for you.  If you're an engineer, this might feel weird.  It's about shifting the focus from the thing to the person. If nobody shows up to your meetings, tailor the invite to be explicit about what's in it for the attendees.
    • Distinguish between responsibility and authority.  Know whether you influence a decision or own it.  When you don't have authority, but you need to get results, leverage the model in Influencing Without Authority.
    • Turn chickens into pigs.  A pig's committed while a chicken's involved.  Don't let a chicken have a controlling vote, without turning them into a pig.  See Turning Chickens into Pigs.
    • 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.
    • Know the system.   Analyze the problem from a system standpoint.  What are the components and subsystems?  What are the inputs and outputs?  Who are the players?   What levers can you pull that make the most impact?  If you don't know, who does?
    • Analyze it over time.  Look at the problem or solution over time. Build your temporal skills.  The more you play "what ifs" in the future, the easier it gets to anticipate.

    Do you have any favorite success patterns to share?

    My Related Posts

  • J.D. Meier's Blog

    WCF Security Resources

    • 7 Comments

    If you're building Web services or if you're implementing SOA on the Microsoft platform , then you're probably either working with or exploring WCF (Windows Communication Foundation.)   When we started our patterns & practices WCF Security Guidance project, one of the first things I did was compile a list of WCF security resources for our team.  This helped us quickly ramp up and as well as see gaps.  One thing that surprised me is how much is available in the product documentation, if you know where to look.  Here's a preliminary look at our WCF Security resources index which we'll include in our WCF Security Guide: 

    Getting Started

    Community

    Articles

    Microsoft

    Community

    Blogs

    Microsoft

    Community

    Channel9

    Podcasts

    ARCast.TV

    Videos

    Tags

    Documentation (MSDN Product Documentation)

    Overview

    Guidance

    Scenarios

    Threats and Countermeasures

    Topics

    How Tos

    Guides

    Community

    Posts

    Microsoft

    Community

    patterns & practices

    Product Support Services (PSS)

    Samples

    Microsoft

    Community

    Videos

    Web Casts

    MSDN Support WebCasts

  • J.D. Meier's Blog

    Services Layer

    • 7 Comments

    In my previous posts I showed layers and components, and layers and tiers.  In this post, I'll show the services layer in a layered architecture.

    Services Layer
    Here's a visual example of a services layer, where the application is exposing services:

    ServicesLayer

    Note that services don't need to be "web" services.

    Key Services Layer Components
    Here's the key components of a services layer:

    • Service Interfaces. The service interface acts as a facade that exposes the business logic to potential consumers.  The definition of the set of messages that must be exchanged with a service in order for the service to perform a specific business task is the contract.
    • Message Types. Message Types are “message contracts” for communication between service consumers and providers.  They wrap business entity components into specific messages for the calling service.

    Additional Resources

    My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • Layers and Components
  • Layers and Tiers
  • App Arch Meta Frame
  • Scenario Frames for Presentation, Business, Data and Services
  • J.D. Meier's Blog

    Mobile Application Architecture Pocket Guide

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

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

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

    Download

    My Related Posts

  • J.D. Meier's Blog

    Application Patterns for Application Architecture

    • 7 Comments

    We created an initial set of Application Patterns as part of our patterns & practices Application Architecture Guide 2.0 project.   The purpose of the application patterns is to show a skeletal solution for common end-to-end applications.  Each application pattern includes a scenario, a pattern solution, and a technical solution.  This provides you with a relatively stable backdrop and starting point to reuse lessons learned from successful applications.

    Application Patterns
    Here's our initial set of application patterns:

    Example Application Pattern
    The heart of each application pattern revolves around the scenario, the pattern overlay, and the technology overlay:

    Scenario
    Here's the backdrop we use for the baseline architecture:

    Scenario

    Pattern Solution
    Here's our pattern overlay:

    PatternsSolution (2)

    Tech Solution
    Here's our technology overlay:

    TechnologySolution (2)

    Application Pattern Template
    Here's the core structure of each application pattern:

    Section Description
    Key Characteristics Identifies the distinctions that impact the application architecture and design. Helps you quickly identify whether the scenario is relevant for your situation.
    Scenario A brief illustration of the deployment scenario and main application parts.
    Key Characteristics Identifies the distinctions that impact the application architecture and design. Helps you quickly identify whether the scenario is relevant for your situation.
    Pattern Solution Provides an overaly of patterns on top of the key application parts.
    Pattern Solution Details Elaborates on the patterns. Includes pattern summaries and any relevant example information.
    Technical Solution Provides an example overlay of technologies.
    Technical Solution Details Elaborates on the technologies. Includes technology summaries and any relevant example information, such as code snippets or psuedocode.
    Additional Resources Provides a set of directly relevant resources where you can find more information.

    Feedback

    1. What are 3 things you like about the approach?
    2. What are 3 things you would improve?

    My Related Posts

  • J.D. Meier's Blog

    Finding Your Strengths

    • 7 Comments

    At Microsoft, I learned to keep my energy strong while making things happen.  The best ways I’ve found to do that are follow my growth and follow my passion.  Another way, that’s very important, is to play to my strengths.  Spending time in my strengths is the key to hitting the high notes and getting exponential results.  It keeps me strong, my energy high, and produces more impactful results in less amount of time.

    Whenever I find myself drained, all I need to do is take a look at where I’ve been spending my time.  Sure enough, it’s always from spending too much time in my weaknesses and not enough time in my strengths.   That’s the interesting lesson too … I can spend more time in my weaknesses, as long as I’m spending enough time in my strengths.

    By strengths, I’m not talking about the skills I’ve learned.  I’m talking about my natural strengths – the ones that I can count on no matter what.  I didn’t find my strengths over night and it’s a continuous process of gaining clarity and precision.  The key here is knowing the language.  When you know what to look for, it’s easier to find your own strengths, label them, and use them to your advantage.

    34 Key Strengths
    Marcus Buckingham and Donald O. Clifton, Ph.D. identified 34 key signature themes of strength.  I have a brief description of each strength in my post, Finding Your Strengths.  Here are the 34 signature themes:

    • Achiever
    • Activator
    • Adaptability
    • Analytical
    • Arranger
    • Belief
    • Command
    • Communication
    • Competition
    • Connectedness
    • Context
    • Deliberative
    • Developer
    • Discipline
    • Empathy
    • Fairness
    • Focus
    • Futuristic
    • Harmony
    • Ideation
    • Inclusiveness
    • Individualization
    • Input
    • Intellection
    • Learner
    • Maximizer
    • Positivity
    • Relater
    • Responsibility
    • Restorative
    • Self-assurance
    • Significance
    • Strategic
    • Woo

    24 Signature Strengths
    Martin Seligman named a set of 24 Signature Strengths.  You can find out more about Martin Seligman’s work at the Authentic Happiness Center.  Here are Seligman’s 24 Signature Strengths:

    • Appreciation of Beauty and Excellence
    • Bravery and Valor
    • Capacity to Love and Be Loved
    • Caution, Prudence, and Discretion
    • Citizenship, Teamwork, and Loyalty
    • Creativity, Ingenuity, and Originality
    • Curiosity and Interest in the World
    • Fairness, Equity, and Justice
    • Forgiveness and Mercy
    • Gratitude
    • Honesty, Authenticity, and Genuineness
    • Hope, Optimism, and Future-mindedness
    • Humor and playfulness
    • Industry, Diligence, and Perseverance
    • Judgment, Critical Thinking, and Open-Mindedness
    • Kindness and Generosity
    • Leadership
    • Love of Learning
    • Modesty and Humility
    • Perspective  and Wisdom
    • Self-Control and Self-Regulation
    • Social Intelligence
    • Spirituality, Sense of Purpose, and Faith
    • Zest, Enthusiasm, and Energy

    How To Use These Strength Vocabularies
    One way to use these is to take their tests and find out what they say about you.  I do like the fact that they have framed and named the strengths which makes it easy to explore, test, and evaluate.  Personally, I’ve found more value by simply exploring the labels and using them as lenses.  I’ve been rationalizing them against the Myers-Briggs Type Indicator (MBTI) as well as my own frames for strengths, looking for underlying patterns and practices. 

    At the end of the day, the most important thing for me has been finding where I get energy from, and finding what takes it away.   This leads me to a personalized strengths frame that I can use as a lens for investing in my portfolio of strengths … and this is the key to exponential results.

  • J.D. Meier's Blog

    @Stake Security Study: .NET 1.1 vs. WebSphere 5.0

    • 7 Comments

    I like competitive studies.  I'm usually more interested in the methodology than the outcome.  The methodology acts as a blueprint for what's important in a particular problem space. 

    One of my favorite studies was the original @Stake study comparing .NET 1.1 vs. IBM's WebSphere security, not just because our body of guidance made a direct and substantial difference in the outcome, but because @Stake used a comprehensive set categories and an evaluation criteria matrix that demonstrated a lot of depth.

    Because the information from the original report can be difficult to find and distill, I'm summarizing it below:

    Overview of Report
    In June 2003, @Stake, Inc., an independent security consulting firm, released results of a Microsoft-commissioned study that found Microsoft's .Net platform to be superior to IBM's WebSphere for secure application development and deployment.  @stake performed an extensive analysis comparing security in the .NET Framework 1.1, running on Windows Server 2003, to IBM WebSphere 5.0, running on both Red Hat Linux Advanced Server 2.1 and a leading commercial distribution of Unix..


    Findings
    Overall, @stake found that:

    • Both platforms provide infrastructure and effective tools for creating and deploying secure applications
    • The .NET Framework 1.1 running on Windows Server 2003 scored slightly better with respect to conformance to security best practices 
    •  The Microsoft solution scored even higher with respect to the ease with which developers and administrators can implement secure solutions

    Approach
    @stake evaluated the level of effort required for developers and system administrators to create and deploy solutions that implement security best practices, and to reduce or eliminate most common attack surfaces.


    Evaluation Criteria

    • Best practice compliance.  For a given analysis topic, to what degree did the platform permit implementation of best practices?
    • Implementation complexity.   How difficult was it for the developer to implement the desired feature?
    • Documentation and examples.  How appropriate was the documentation? 
    • Implementor competence.  How skilled did the developer need to be in order to implement the security feature?
    • Time to implement.  How long did it take to implement the desired security feature or behavior? 


    Ratings for the Evaluation Criteria

    1. Best Practice Compliance Ratings
      1. Not possible
      2. Developer implement
      3. Developer extend
      4. Wizard
      5. Transparent
    2. Implementation Complexity Ratings
      1. Large amount of code
      2. Medium amount of code
      3. Small amount of code
      4. Wizard +
      5. Wizard
    3. Quality of Documentation and Sample Code Ratings
      1. Incorrect or Insecure
      2. Vague or Incomplete
      3. Adequate
      4. Suitable
      5. Best Practice Documentation
    4. Developer/Administrator Competence Ratings
      1. Expert (5+ years of experience
      2. Expert/intermediate (3-5 years of experience)
      3. Intermediate
      4. Intermediate/novice
      5. Novice (0-1 years of experience)
    5. Time to Implement
      1. High (More than 4 hours)
      2. Medium to High (1 to 4 hours)
      3. Medium (16-60 minutes)
      4. Low to Medium  (6-15 minutes )
      5. Low (5 minutes or less )


    Scorecard Categories
    The scorecard was organized by application, Web server and platform categories.  Each category was divided into smaller categories to test the evaluation criteria (best practice compliance, implementation complexity, quality of documentation, developer competence, and time to implement).

    Application Server Categories

    1. Application Logging Services
      1. Exception Management
      2. Logging Privileges
      3. Log Management
    2. Authentication and Access Control
      1. Login Management
      2. Role Based Access Control
      3. Web Server Integration
    3. Communications
      1. Communication Security
      2. Network Accessible Services
    4. Cryptography
      1. Cryptographic Hashing
      2. Encryption Algorithms
      3. Key Generation
      4. Random Number Generation
      5. Secrets Storage
      6. XML Cryptography
    5. Database Access
      1. Database Pool Connection Encryption
      2. Data Query Safety
    6. Data Validation
      1. Common Validators
      2. Data Sanitization
      3. Negative Data Validation
      4. Output Filtering
      5. Positive Data Validation
      6. Type Checking
    7. Information Disclosure
      1. Error Handling
      2. Stack Traces and Debugging
    8. Runtime Container Security
      1. Code Security
      2. Runtime Account Privileges
    9. Web Services
      1. Credentials Mapping
      2. SOAP Router Data Validation

    Host and Operating System Categories

    1. IP Stack Hardening
      1. Protocol Settings
    2. Service Minimization
      1. Installed Packages
      2. Network Services

    Web Server Categories

    1. Architecture
      1. Security Partitioning
    2. Authentication
      1. Authentication Input Validation
      2. Authentication Methods
      3. Credential Handling
      4. Digital Certificates
      5. External Authentication
      6. Platform Integrated Authentication
    3. Communication Security
      1. Session Encryption
    4. Information Disclosure
      1. Error Messages and Exception Handling
      2. Logging
      3. URL Content Protection
    5. Session Management
      1. Cookie Handling
      2. Session Identifier
      3. Session Lifetime

    More Information
    For more information on the original @stake report, see the eWeek.com article, .Net, WebSphere Security Tested.

  • J.D. Meier's Blog

    Making 30 Day Improvement Sprints More Effective

    • 7 Comments

    In my 30 Day Improvement Sprints post, a reader asked, what tips do I have to make 30 days sprints more effective.  Here's my short list

    • Buddy up.  Seriously.  One guy's hurdle, is another girl's breeze.
    • Don't beat yourself up.  If at first you don't succeed, tell yourself you just learned another way how NOT to do something.
    • Count your improvements, not your blunders.  It's a pick you up vs. put you down approach.
    • Make each session count.  Keep your sessions short and sweet.   Slow and steady wins the race.
    • Focus on your improvement process vs. the result itself.  Make the process your reward.  I enjoy learning again for learning's sake.       
    • If you're churning, change your approach.  Don't mistake churn for awkwardness. Growth feels awkward and is a precursor to proficiency. 
    • Find experts you can model and learn from.  Success leaves clues.  If you can find somebody who does a great job at what you want to do, you have a head start.  I leverage lots of mentors.  I used to just see an amazing pool of people around me.  Now I see an amazing team of coaches.
    • Journal your lessons learned.  Each day, reflect on distinctions you made.  What's one little thing you learned you didn't know the day before.  You'll be surprised how simple notes can shine a spotlight on your gains.
    • Repetition is your friend.  Remind yourself that repetition is the mother of skill.  World class experts master the fundamentals through repetition and refinement.
    • Set your own bar vs. follow others.  Don't compare yourself to others; compare yourself to you.  Be your personal best.  I remember a point John Wooden made some time ago.  He didn't think his team should gloat over wins, or beat themselves up over losses.  His point was, if you won, but didn't play your best, did you really deserve to win? ...  If you lost, but you played your personal best, did you really lose?
    • Focus on the thinking, feeling and doing.  Sometimes the inner dialogue is more important than what you see or hear.  While something might seem purely physical, sometimes, there's a lot of self-talk an expert does that might not be obvious.  What do they think about when they perform the technique?  When they mess up, how do they get back in the zone?  What's their decision tree?  For example, when I do a customer arch and design review, they see me put stuff on a whiteboard.  They hear me ask precise questions.  What they might not know is the matrix of questions and reference examples I draw from.
    • Be your own best coach.  Use questions to shape your improvement.    
    • Ask for feedback.  Find those you trust to point out things you might otherwise miss.  

    Few problems withstand sustained focus.  There's a bit of captive genius in everyone that just needs to be uncorked.  30 days of focused improvement seems to be a great way to pop the cork.  I'm finding improvement sprints refreshing because I now have a schedule for exploration.  I can rotate through more interests.  Most importantly, rather than tackle everything all at once, I just wait for my next 30 day focus.  It's easier to put something aside for the moment, if I know I'll have a chance to immerse myself in it in the future.  If I enjoyed something so much and I want to continue, I just do another 30 days.

    Hope that helps!

    Related Posts

  • J.D. Meier's Blog

    Now on MSDN: patterns & practices Team Development with Visual Studio Team Foundation Server Guide

    • 7 Comments

    You can now find our patterns & practices Team Development with Visual Studio Team Foundation Server guide on MSDN in HTML.  It's the same guidance we hosted on CodePlex.  CodePlex was our channel for agile release.  Once we baked the guidance, we ported to MSDN.  For some customers, MSDN is a trusted source, so being on MSDN is important.  Additionally, MSDN provides some additional hooks and channels.

    Contents At a Glance
    Here's the guide at a glance

    Chapters

    Guidelines

    Practices at a Glance

    Questions and Answers

    How Tos

    Download
    You can download the Team Development with Visual Studio Team Foundation Server Guide from CodePlex.

    Guidance Explorer Scenario
    If you want to tailor the guidance for your scenario, you can download Guidance Explorer from CodePlex.  Using Guidance Explorer, you can create custom views by dragging and dropping the relevant guidance and then tailoring it as you see fit.  You can then save your view or an item to Word or HTML. 

  • Page 3 of 44 (1,096 items) 12345»