J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Office 365 at a Glance

    • 4 Comments

    This is my roundup of Microsoft Office 365 at a glance.  I’ve included a brief summary of the key services and features direct from the Microsoft Office 365 Service Descriptions, as well as a massive feature list of the Office 365 Services at the end of this post.

    At the start of every year, I do an extreme roundup of the Microsoft platform.  It helps me see the forest for the trees, understand the big bets, and make sense of the overall Microsoft platform.  It also helps me anticipate growth, jobs, declines, etc.  As part of the process, I try to share what I learn because I imagine a lot of people benefit from the ability to see the Microsoft platform at a glance.

    With that in mind, let’s begin …

    The main things you need to know to figure out Office 365 are:

    • Office 365 refers to the online services:  Exchange Online, Lync Online, SharePoint Online, etc. 
    • Don’t confuse Office 365 with the on-premises versions: Lync Server 2013, Exchange Server 2013, SharePoint Server 2013, etc.  (Once you recognize this naming convention, then it’s a lot easier to parse what you find on Microsoft.com, MSDN, and TechNet.)
    • The key way to figure out what’s in Office 365 is to read the Microsoft Office 365 Service Descriptions.
    • Don’t confuse the Microsoft Office 365 Service Descriptions with the older Business Productivity Online Services Service Descriptions. (I fell for this.  I was reading a Service Description for Exchange Online wondering why it seemed dated – it was.)
    • You can find feature comparisons between the on-premises versions and the online versions within the Microsoft Office 365 Service Description documents.  For example, you can see Lync Server vs. Lync Online, Exchange Server vs. Exchange Online, SharePoint Server vs. SharePoint Online.

    Office 365 Service Descriptions

    The Office 365 Service Descriptions are the important documents for understanding what the Office 365 services actually are:

    • Microsoft Exchange Online Archiving Service Description
    • Microsoft Exchange Online Enterprise Service Description
    • Microsoft Lync Online for Enterprises Service Description
    • Microsoft Office Professional Plus Service Description
    • Microsoft Office Web Apps Service Description
    • Microsoft SharePoint Online for Enterprises Service Description
    • Office 365 Identity Service Description
    • Office 365 Mobility Solutions Service Description
    • Office 365 Security and Service Continuity Service Description
    • Office 365 Support for Apple Mac and iOS Devices
    • Office 365 Support Service Description

    About Microsoft Office 365

    Microsoft Office 365 brings together cloud versions of its most trusted communications and collaboration products with the latest version desktop suite. Office 365 is designed to meet the needs of organizations of all sizes—from sole proprietors and small, mid-sized, and large businesses to government agencies to educational institutions—helping you save time, money, and free up valuable resources.
    Key Office 365 benefits include:

    • Access to email, documents, contacts, and calendars on almost any smartphone or tablet.
    • Simple and secure collaboration with colleagues and business partners.
    • Seamless functioning with Microsoft Office and other programs.
    • Comprehensive solutions including desktop productivity applications, portals, extranets, instant messaging (IM), voice and video conferencing, web conferencing, email and voice mail.
    • Pay-as-you-go pricing options with a financially backed 99.9 percent uptime guarantee.
    • Office 365 includes the Microsoft Exchange Online and Microsoft SharePoint Online services.

    Common Features Across Microsoft Office 365

    Cloud services offered by Microsoft Office 365 for enterprises are designed to help meet the need for robust security, 24/7 reliability, and user productivity.
    Each service is designed for reliability, availability, and performance with a financially backed service level agreement (SLA) for a guaranteed 99.9-percent scheduled uptime. Microsoft deploys patches, security updates, and back-end upgrades, helping to eliminate the time and effort organizations spend managing their servers.
    Subscribers to Office Professional Plus benefit from a set of features that are common to all of the Microsoft business-class cloud services:

    • Secure access: Each offering from Microsoft Office 365 is accessed through 128-bit Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption. Anyone who intercepts a communication sees only encrypted text.
      Intrusion monitoring: Microsoft continuously monitors the Office 365 systems for any unusual or suspicious activity. If Microsoft detects such activity, it investigates and responds appropriately. In the unlikely event that a significant incident occurs, the customer is notified.
    • Security audits: Microsoft regularly assesses the Office 365 infrastructure to ensure that the latest antivirus signatures and required security updates are installed, and that high-level configuration settings are in compliance with Microsoft security policies. For details, refer to the Security and Service Continuity for Enterprises Service Description.
    • High availability: Microsoft Office 365 services have a 99.9-percent scheduled uptime. If a customer’s service is affected, Office 365 offers financial remedies subject to the terms and conditions of the SLA. For details, refer to the Service Level Agreement for Microsoft Online Services.
    • Service continuity: Redundant network architecture is hosted at geographically dispersed Microsoft data centers to handle unscheduled service outages. Data centers act as backups for each other: If one fails, the affected customers are transferred to another data center with limited interruption of service.
    • Microsoft Online Services Portal: This easy-to-use website is the center for activities related to Microsoft Office 365. The portal provides services based on each organization’s specific needs. Prospective subscribers can use the portal to sign up for a free trial. End users accessing the portal can find online help, open Microsoft SharePoint site collections, and launch Microsoft Outlook® Web App. Administrators can manage users, administer services, download tools, and learn about service administration from online help.
    • Directory Synchronization tool: For subscribers with Active Directory® directory services deployed on-premises, this tool helps keep the on-premises Active Directory and the Microsoft Office 365 directory synchronized.
    • Remote administration: With Microsoft Windows PowerShell™, administrators can perform many tasks using a script or automated process. For example, tasks such as creating users, resetting passwords, assigning licenses, and obtaining service-use data can be fully automated.

    Types of Identity in Office 365

    Office 365 offers two types of identities:

    1. Microsoft Online Services cloud IDs (Cloud Identity): Users receive cloud credentials—separate from other desktop or corporate credentials—for signing into Office 365 services. The cloud ID password policy is stored in the cloud with the Office 365 service.
    2. Federated IDs (Federated Identity): In companies with on-premises Active Directory®, users can sign into Office 365 services using their Active Directory credentials. The corporate Active Directory authenticates the users, and stores and controls the password policy.

    The type of identity affects the user experience, administrative requirements, deployment considerations, and capabilities using Office 365.

    For more information about Office 365 Identity, please refer to the Office 365 Identity Service Description.

    Microsoft Exchange Online

    Microsoft Exchange Online is a hosted messaging solution that delivers the capabilities of Microsoft Exchange Server as a cloud-based service. It gives users rich and familiar access to email, calendar, contacts, and tasks across PCs, the web, and mobile devices. With Exchange Online, organizations can take advantage of sophisticated messaging capabilities without the operational burden of on-premises server software.
    Exchange Online supports the Microsoft Exchange ActiveSync® protocol. Exchange ActiveSync provides synchronization of mailbox data between mobile devices and Exchange Online, so users can access their email, calendar, contacts, and tasks on the go.
    For more information about Exchange Online, please refer to the Microsoft Exchange Online Service Description.

    Microsoft Lync Online

    Microsoft Lync Online is a next-generation cloud communications service that connects people in new ways, anytime, from virtually anywhere. Lync Online provides intuitive communications capabilities across presence, instant messaging, audio/video calling and a rich online meeting experience including PC-audio, video and web conferencing. Transform your interactions with colleagues, customers and partners from today’s hit-and-miss communication to a more collaborative, engaging, and effective experience.

    For more information about Lync Online, please refer to the Microsoft Lync Online Service Description.

    Microsoft SharePoint Online

    SharePoint Online gives you a central place to share documents and information with colleagues and customers. Designed to work with familiar Office applications, it’s easy to save documents directly to SharePoint and work together on proposals and projects in real-time because you have access to the documents and information you need from virtually anywhere.
    SharePoint Online helps businesses of all sizes share team documents and track project milestones. You can manage important documents online so the latest versions are always at hand. You can also provide teams with access to critical information and documents when and where they need them, while controlling who can access, read, and share them.
    SharePoint Online sites can render on many devices (including Web-enabled mobile phones) using a simplified text-only format. Like Exchange Online, SharePoint Online includes a standardized web-based administrative console that enables your IT administrator to easily manage and set up services for users.
    For more information about SharePoint Online, please refer to the Microsoft SharePoint Online Service Description.

    Office Professional Plus

    The capabilities of Office Professional Plus can be summarized as:  Use Office Anywhere, Work Together, and Bring Ideas to Life.
    With Office Professional Plus, users get the latest version of the Microsoft Office applications, seamlessly connected and delivered with cloud services, so they can access their documents, email, and calendars from virtually any device. Office Professional Plus includes the new Office Web Apps—online companions to Microsoft Word, Microsoft Excel®, Microsoft PowerPoint®, and Microsoft OneNote®—which let users review and make minor edits to documents directly from a browser.
    The flexible pay-as-you-go, per-user licensing of Office Professional Plus is available as part of Office 365 and provides companies with purchasing flexibility; in addition, robust management and deployment tools give companies the IT control to adapt to evolving business needs.

    For more information about Office Professional Plus, please refer to the Microsoft Office Professional Plus Service Description.

    Microsoft Office Web Apps

    Microsoft® Office Web Apps is the online companion to Microsoft Word, Microsoft Excel®, Microsoft PowerPoint®, and Microsoft OneNote® applications that helps users access documents from almost anywhere. Users can view, share, and work on documents online with other users across personal computers, mobile devices, and the web.
    Office Web Apps is available to users through Microsoft SharePoint® Online, which is part of Microsoft Office 365. Office Web Apps is also available as a part of Microsoft Windows Live™ and also to business customers through Microsoft Office 2010 volume licensing, Office 365, and document management solutions based on Microsoft SharePoint 2010 products.
    This document focuses on using Office Web Apps as a part of SharePoint Online.

    For more information about Microsoft Office Web Apps, please refer to the Microsoft Office Web Apps Service Description.

    Office 365 Suite Subscription Plans

    Friendly Name

    Plan

    Size Max

    Items

    Hosted Email

    Exchange Online

    50,000+

    Complete integration with Outlook* and web access to email, calendars, and contacts
    Cloud-based email using your own domain name
    Shared calendars
    Configurable anti-spam filtering
    Active Directory synchronization
    25GB user mailboxes and ability to send attachments up to 25 MB
    Live 24 x 7 IT-level phone support

    Small Business

    Plan P1

    50

    Cloud-based email using your own domain name
    Shared calendars
    Instant messaging, PC-to-PC calling, and video conferencing
    Web-based viewing and editing of Word, Excel, PowerPoint, and OneNote files
    Team site for sharing files
    Public website
    Anti-malware and anti-spam filtering
    Microsoft community support

    MIDSIZE BUSINESS & ENTERPRISE

    Plan E1

    50,000+

    Everything in Small Business, P1*, plus:
    Active Directory synchronization
    Configurable anti-spam filtering
    SharePoint intranet supporting up to 300 site collections
    Live 24 x 7 IT-level phone support
    * Please note: with E

    MIDSIZE BUSINESS & ENTERPRISE

    Plan E3

    50,000+

    Everything in E1, plus:
    Office Professional Plus 2010 desktop version subscription (for up to 5 devices per user)
    Email archiving and unlimited email storage
    Hosted voicemail support
    Connection to line-of-business applications
    Dashboards with Excel Services

     

    For more information on the Office 365 Suite Subscription Plans, see the Office 365 Suite Subscription Plans page and the Office 365 Plan Advisor Tool.

    Features at a Glance for Microsoft Office 365

    This is a roundup of Office 365 services at a glance, organized by product.  It’s the balcony view.  By scanning the list, you can get a quick sense of the services.  Then read the actual Office 365 Service Descriptions to find out more.

     

    Category

    Items

    Office 365

    Secure access
    Intrusion monitoring
    Security audits
    High availability
    Service continuity
    Microsoft Online Services Portal
    Directory Synchronization tool
    Remote administration

    Exchange Online

    Service Features
    Mailbox size (1 GB for Exchange Online Kiosk user, 25 GB for Exchange Online (Plan 1) user, unlimited for Exchange Online (Plan 2) user)
    Message size limits (max attachment size - 25 MB)
    Recipient limits (1,500 recipients/day)
    Message rate limits (30 messages/minute)
    Deleted item recovery (14 Days)
    Deleted mailbox recovery (30 Days)

    Client Access
    Outlook 2010
    Outlook 2007
    Outlook 2003 (POP or IMAP only)
    Outlook Anywhere (RPC over HTTPS)
    Outlook Cached Mode
    Outlook Online Mode
    Autodiscover (for Outlook and mobile)
    Outlook Web App (Internet Explorer 7+, Safari+, Firefox, Chrome)
    Outlook Web App light experience (Almost any browser)
    Outlook Web App: Vanity URL (Customer can set up a redirect)
    Outlook Web App: session time-out (Default: 6 hours, Configurable up to 24 hours)
    WebReady document viewing
    Instant messaging and presence connected to web email client
    Macintosh support (Outlook for Mac 2011, Entourage 2008 Web Services edition)
    IMAP
    POP

    Mobility
    Windows Phone 7 devices
    Windows Mobile devices (Windows Mobile 6.0+)
    Other Exchange ActiveSync devices (such as iPhone)
    Remote device wipe
    Customize Exchange ActiveSync security policies and settings, including PIN/password lock
    Disable Exchange ActiveSync access
    Mobile device allow/block/quarantine
    Over-the-air-update for Outlook Mobile
    Mobile SMS sync (through Exchange ActiveSync)
    SMS (text messaging) notifications
    Blackberery (via Blackberry Enterprise Server)
    Blackberry (via Blackberry Internet Service)

    Email/Inbox
    "Send on behalf of" and "send as"
    Shared mailboxes
    Server-side email forwarding
    Inbox rules
    Tasks
    Conversation view and actions (such as ignore conversation)
    MailTips and MailTips customization
    Connected accounts (aggregate mail from multiple external email accounts)

    Contacts/Directory
    Personal contacts
    Personal distribution groups
    Shared distribution groups (in Global Address List)
    Restricted distribution groups
    Dynamic distribution groups
    Moderated distribution groups
    Moderated distribution groups
    Self-service distribution groups
    Global Address List
    Hide users from Global Address List
    Offline Address Book
    External contacts (in Global Address List)

    Calendar
    Out-of-office auto-replies
    Cross-premises calendar free/busy (mix of on-premises/cloud users)
    Federated calendar sharing
    Publish or subscribe to calendar through iCal
    Side-by-side calendar view in web client
    Resource mailboxes (for example, for conference rooms or equipment)
    Outlook 201 Room Finder

    Unified Messaging, FAX
    Interoperability with on-premises voicemail systems
    Exchange Unified Messaging (hosted voicemail)

    Security
    Anti-spam (AS) (Forefront Online Protection for Exchange)
    Antivirus (AV) (Forefront Protection for Exchange)
    Safe and blocked senders (configurable at the organization level)
    Opportunistic TLS for inbound/outbound email
    Forced TLS for inbound/outbound email
    S/MIME (Yes, with limitations, No Outlook Web App support)
    PGP

    Compliance/Archiving
    Disclaimers
    Transport rules
    Personal archive
    Retention policies
    Journal messages to external or on-premises archive
    Multi-mailbox search (eDiscovery)
    Legal hold
    Rolling legal hold

    Administration
    Administration through a Web-based interface (Exchange Control Panel)
    Forefront Online Protection for Exchange Administration Center access
    Administration through command line shell (PowerShell)
    Role-Based Access Control (RBAC)
    Message Tracking
    Usage Reporting (Some data can be extracted using PowerShell)
    Auditing

    Application Access/Customization
    Application connectivity through web services
    SMTP relay
    Outlook Web App Web Parts
    Outlook add-ins and Outlook MAPI

    Other
    Global Address List synchronization from on-premises directory (Active Directory) (One-way through the Directory Synchronization tool)

    Lync Online

    IM/presence and Lync-to-Lync calls
    1-to-1 and multiparty IM/presence
    Address book search
    Dl expansion (DLX)
    File transfer
    Lync-to-Lync audio/video calls
    Lync-to-Lync high definition video
    Presence and click-to-Lync from Office Apps
    Interactive contacts card in Office 2010

    Lync external connectivity (federation and Public IM connectivity)
    IM/presence/audio/video federation with other OSC/Lync Server/Lync Online organizations
    IM/presence/audio/video with Windows Live Messenger

    Meetings (audio/video/web conferencing)
    Meeting attendee capacity (250)
    Desktop sharing
    Application sharing
    White boarding and annotations
    PowerPoint upload for online presentations
    Polling
    Ad-hoc multiparty PC-based audio-video
    Unauthenticated attendee in Lync Web App
    Lync attendee client
    Scheduled conferences (using Outlook plug-in)
    Outlook delegation for scheduling meetings
    Support for RoundTable device
    Lobby
    Interoperability with certified partners for dial-in audio conferencing (ACP)
    Phone-dial-out from scheduled meetings via third-party dial-in conferencing service
    Client-side recording and playback
    Backstage/Content Preview for presenters
    Mute all attendees
    Mute individual attendees
    Unmute all attendees
    Unmute individual attendees
    In-meeting attendee permission controls

    Voice and telephony
    Lync-to-phone (calls with landlines and mobile phones)
    Call hold/retrieve
    Dial-out from ad-hoc Lync meetings
    Advanced call controls (transfer, forward, simul-ring)
    Access to Exchange Online voicemail
    Team call
    Delegation (boss-admin) for Voice

    Client support
    Lync 2010
    Lync Web App for participating in scheduled meetings
    Lync 2010 Attendee client (joniing meeting)
    Lync 2010 Mobile client
    IM and media encryuption
    IM filtering

    Exchange/SharePoint interoperability
    Presence interoperability with Exchange and SharePoint on-premises
    Presence interoperability with Exchange Online and SharePoint Online

    Third-party API support
    Client-side APIs

    SharePoint Online

    Communities
    Ask Me About
    Blogs
    Colleague Suggestions
    Colleagues Network
    Discussions
    Enterprise Wikis
    Keyword Suggestions
    Memberships
    My Site My Content
    My Site My Newsfeed
    My Site My Profile
    Notes Board
    Organization Browser
    Photos and Presence
    Ratings
    Recent Activities
    Status Updates
    Tag Clouds
    Tag Profiles
    Tags
    Tags and Notes Tool
    Wikis
    Client Object Model (OM)
    Event Receivers
    Language Integrated Query (LINQ) for SharePoint
    Solution Packages
    REST and ATOM Data Feeds
    Ribbon and Dialog Framework
    Silverlight Web Part
    Worklow Models
    Access Services
    Browse-Based Customizations
    Business Data Connectivity Service
    External Data Column
    Business Data Web Parts
    External Lists
    SharePoint Designer 2010
    Forms: Out-of-Box workflows and customization through SharePoint Designer 2010
    InfoPath Forms Services
    Sandboxed Solutions
    Workflow
    Microsoft Visual Studio 2010 SharePoint Developer Tools
    Windows 7 Support
    Workflow Support
    Workflow Templates
    SharePoint Service Architecture

    Content
    In-Place Legal Holds
    Document Sets
    Metadata-driven Navigation
    Multi-Stage Disposition
    Rich Media Management
    Shared Content Types
    Support for Accessibility Standards
    Content Organizer
    Unique Document IDs
    Managed Metadata Service

    Insights
    Excel Services
    Visio Services
    Calculated KPIs

    Search
    Best Bets
    Extensible Search Scale
    Duplicate Detection
    Metadata-Driven Refinement
    Mobile Search Experience
    People and Expertise Search
    Phonetics and Nickname Search
    Recently Authored Content
    Search Scopes
    Single Site Collection Search
    Site Search
    Click-Through Relevancy
    View in Browser
    Basic Sorting

    Sites
    SharePoint Lists
    Web Parts
    Improved Governance
    Large List Scalability and Management
    Multi-Lingual User Interface (MUI)
    Permissions Management
    Quota Templates
    Secure Store Service
    Connections to Microsoft Office Clients
    Public Website (One per tenant)
    Audience Targeting
    RSS Feeds
    Cross-Browser Support
    External sharing
    SharePoint Ribbon
    Mobile Connectivity
    Office Web Apps integration
    SharePoint Workspace 2010
    Out-of-the-Box Web Parts
    Scalability
    Template
    Accessibility
    Configuration Wizards

    Office Professional Plus

    Microsoft Access
    Microsoft Excel
    Microsoft InfoPath
    Microsoft Lync
    Microsoft OneNote
    Microsoft Outlook
    Microsoft PowerPoint
    Microsoft Publisher
    Microsoft SharePoint Workspace
    Microsoft Word

    Office Web Apps

    Word Web App
    Print
    Find
    Zoom
    Navigation
    Open in Word
    Edit in Web App
    Save
    View in Web App
    Clipboard
    Undo and Redo
    Font Formatting
    Paragraph Formatting
    Bullets and Numbering
    Styles
    Proofing Tools
    Tables
    Pictures
    Hyperlinks
    Placeholders

    Excel Web App
    Refresh Data
    Find
    Navigation
    Open in Excel
    Edit in Web App
    Sort and Filter Data
    Save or Download a Copy
    Co-authoring
    Save
    Clipboard
    Undo and Redo
    Formula Bar
    Font and Cell Formatting
    Alignment
    Number Formatting
    Functions
    Tables
    Edit Worksheet Structure
    Hyperlinks

    PowerPoint Web App
    View and Copy Slide Notes
    Run Slide Show
    Navigation
    Broadcast Slide Show
    Outline View
    Open in PowerPoint
    Edit in Web App
    Save
    View and Edit Slide Notes
    View in Web App
    Clipboard
    Undo and Redo
    Create and Manage Slides
    Font Formatting
    Alignment, Bullets, and Numbering
    Pictures
    SmartArt
    Hyperlinks

    OneNote Web App
    Show Authors
    View Previous Page Versions
    Navigation
    Open in OneNote
    Edit in Web App
    Save
    View in Web App
    Co-authoring for Shared Notebooks
    Clipboard
    Undo and Redo
    Font Formatting
    Paragraph Formatting
    Bullets and Numbering
    Styles
    Tags
    Proofing Tools
    Create and Manage Pages and Sections
    View and Restore Page Versions
    Pictures
    Tables
    Hyperlinks
    Placeholders

    You Might Also Like

  • J.D. Meier's Blog

    Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS)

    • 1 Comments

    In cloud computing, you might hear the terms SaaS, PaaS and IaaS.  These are simply different logical layers in the stack.  You can visualize it like this:

    SaaS PaaS and IaaS

    As you move up the stack, you increase abstraction.  As you move down the stack, you increase control.  Here is a brief summary of each term:

    • Infrastructure as a Service (IaaS) - In this case, computing resources (compute, storage, and network) are exposed as a capability.  Instead of owning, managing or controlling the underlying infrastructure, you rent the infrastructure, as a service.  An example is  Amazon Elastic Cloud Compute (EC2).
    • Platform as a Service (Paas) - In this case, programming platforms and tools (such as java, python, or .NET) and/or building blocks and APIs for building cloud-based applications and services are made exposed as a capability.  Examples include Amazon Simple Storage Service (S3), Azure Storage, and Force.com.
    • Software as a Service (SaaS) – In this case, applications are exposed as a service running on a cloud infrastructure.  Examples include SalesForce.com and Microsoft Office Online.

    For my related posts on cloud, see:

  • 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

    Project Life Cycles at patterns & practices

    • 2 Comments

    Periodically I like to revisit our project life cycle in patterns & practices. I like to see how it's shape-shifted over the years.  (Note - our project life cycle wraps our product cycle)  

    patterns & practices Project Life Cycle Circa 2005
    Here's a snapshot of our patterns & practices project life cycle circa 2005:

    PAGProjectLifeCycle

    I used this as a baseline to reflect against.  Here are the phases, stages, and milestones:

    Phases
    Projects cycled through the following phases:

    • Planning
    • Design
    • Implementation
    • Stabilization
    • Release

    Stages
    Stages included:

    • Requirements
    • Specifications
    • Iteration 1
    • Iteration N
    • Final Test and Edit Pass
    • Production

    Milestones
    The milestones included:

    • Proposal Approved
    • Vision Scope Approved
    • M0 (Milestone Zero) / Specifications Approved
    • Technical Review and Solution Approved
    • Test and Edit Complete
    • Go / No Go
    • Customer Availability

    Three Things That Worked Well
    Here's three things that worked well with the original project cycle:

    • There were clear phases, stages, milestones, and deliverables, along with criteria.
    • The project cycle was decoupled from the product cycle.  This gave management a simple frame for understanding projects.  This also gave each project flexibility to choose the most appropriate software development methodology depending on the product.
    • There was sufficient time between key milestones to provide a frame + air-cover.  This helped avoid randomizing engineering and being able to see the forest from the trees.

    Additionally, the key milestones such as Vision Scope and MO were something of a ceremony and tended to include the right representation across the p&p team.

    Three Things That Needed Improvement
    Here's three things that needed improvement:

    • It was a lot of overhead for smaller projects.  It worked well for larger programs (collections of projects), but it was tougher for individual projects.
    • It was tough to bootstrap projects.  M0 and Vision/Scope could be especially tough.  In retrospect, there were two key issues: 1) asking the right questions at the wrong time (premature) 2) chickens with controlling votes over pigs. (See Turning Chickens Into Pigs.)
    • There was too much agreement up front, with not enough ability to coarse correct in the later stages/phases (needed more agility)
  • J.D. Meier's Blog

    Performance vs. Load vs. Stress Testing

    • 5 Comments

    This conversation (er, debate) comes up a lot.  What's the difference between performance, load and stress testing?  I'm sure there's tons of *official* definitions.  At the end of the day, I think about them like this:

    • Performance - is about response, time lapses, duration ... etc.
    • Load testing - is about test behavior under normal/peak workload conditions.  Load is more about characterizing / simulating your actual workload.
    • Stress testing - is about surfacing issues under extreme conditions and resource failures.

    I could say more, but sometimes less is better.  If you want to read more, check out our patterns & practices Performance Testing Guidance Project on CodePle  or browse through Scott Barber's exhaustive collection of performance testing articles.

  • J.D. Meier's Blog

    Agile Architecture Method

    • 11 Comments
    AgileArchitecture

    I presented our new patterns & practices Agile Architecture Method for the first time at the patterns & practices Summit.   Our Agile Architecture Method is an iterative and incremental approach for designing architectures. 

    To summarize, it’s a technique that:

    • Scopes and focuses your architecture exercise.
    • Uses scenarios to drive the design and evaluate potential solutions.
    • Helps you think through your choice of application type, deployment, architectural style and technologies.
    • Helps you quickly iterate through potential solutions.
    • Helps you map potential patterns.

    I’ve summarized the approach below, and we’ve posted a step-step how to on CodePlex:

    Input
    Here’s the key input into the process:

    • Use cases and usage scenarios
    • Functional requirements
    • Non-functional requirements (quality attributes such as performance, security, and reliability)
    • Technological requirements
    • Target deployment environment
    • Constraints

    Output
    Here’s the key output of the process:

    • Architecturally significant use cases
    • Architecture hot spots
    • Candidate architectures
    • Architectural spikes

    Summary of Steps

    • Step 1. Identify Architecture Objectives.
    • Step 2. Identify Key Scenarios.
    • Step 3. Create an Application Overview.
    • Step 4. Analyze Key Hot Spots.
    • Step 5. Create Candidate Solutions.

    Step 1. Identify Architecture Objectives
    This is a scoping exercise.  The purpose of this step is to figure out how much time and energy to spend on subsequent steps as well as guide your overall effort.   You should know what you want in terms of outcomes.  Here’s an example of potential goals:

    • Build a prototype
    • Identify key technical risks
    • Test potential paths
    • Share models and understanding

    Step 2. Identify Key Scenarios
    Identify relevant scenarios to focus your design on what matters most, and to evaluate your candidate solutions.    In this case, you want to identify architecturally significant use cases.  Architecturally significant use cases are those that meet the following criteria:

    1. They are important for the success and acceptance of the deployed application.
    2. They exercise enough of the design to be useful in evaluating the architecture.

    You can draw key scenarios from your user stories, business stories and system stories.

    Step 3. Create an Application Overview
    Create an application overview.  The application overview serves to make your architecture more real, connecting it to real-world constraints and decisions. 

    WhiteboardingYourDesign

    An application overview consists of the following steps:

    • Determine your application type. First, determine what type of application you are building. Is it a mobile application, a rich client, a rich internet application, a service, a Web application, or some combination?
    • Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact this will have on your architecture.
    • Identify important architectural styles. Determine which architectural styles you will be using in your design. Will you build a service oriented architecture, client/server, layered, a message bus, or some combination?
    • Determine relevant technologies. Finally, identify the relevant technology choices based on your application type, architectural styles and deployment constraints.

    A good test of an application overview is whether you can whiteboard it.

    Step 4. Analyze Key Hot Spots
    Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application.

    Quality Attributes Frame
    Understand the quality attributes that are important for your application and scenarios. For instance, most applications need to address security and performance and will be traded against usability, flexibility and other attributes that may be more or less important to you depending on your scenarios and requirements.  You can use the following frame to identify key quality attributes to consider:

    Category Considerations
    Availability
  • How to design for failover support
  • How to design a redundant site
  • How to plan for backup and recovery How to design for runtime upgrades
  • Conceptual Integrity
  • How to isolate from external dependencies
  • How to create a migration path from legacy technologies
  • How evolve the system without breaking clients
  • Flexibility
  • How to handle dynamic business rules How to handle dynamic UI
  • How to handle changes in data and logic processing
  • How to handle changes in business requirements
  • Interoperability
  • How to allow applications to interoperate while still evolving separately
  • How to isolate systems through the use of service interfaces
  • How to isolate systems through the use of mapping layers
  • Maintainability
  • How to reduce dependencies between layers and components
  • How to implement a pluggable architecture
  • How to choose an appropriate communication model
  • Manageability
  • How to understand the key types of failure
  • How to monitor system operation and health
  • How to modify system behavior based on load
  • Performance
  • How to determine a caching strategy
  • How to design high performance communication between layers
  • How to design high performance data access
  • How to manage resources effectively
  • Reliability
  • How to handle unreliable external systems
  • How to audit requests and jobs
  • How to redirect load
  • How to handle failed communication
  • How to handle failed transactions
  • How to handle exceptions
  • Reusability
  • How to reduce duplication between components and layers
  • How to share functionality across systems
  • How to share functionality across components and layers
  • Scalability
  • How to design layers and tiers for scalability
  • How to scale-up or scale-out
  • How to handle spikes in traffic and load
  • Security
  • How to address authentication and authorization.
  • How to protect against malicious input.
  • How to protect sensitive data
  • Supportability
  • How to design auditing and logging
  • How to design usable error messages
  • Testability
  • How to design for testability
  • How to design unit tests
  • How to design for UI automation
  • Usability
  • How to design for user empowerment
  • How to improve responsiveness
  • How to avoid common user experience pitfalls
  • Architecture Frame
    The architecture frame represents cross cutting concerns that will impact your design across layers and tiers. These are also the areas in which high impact design mistakes are most often made. Use the architecture frame to identify hot spots in your design that require additional attention to get right.  You can use the following architecture frame to identify cross cutting concerns in your design:

    Category Considerations
    Authentication and Authorization
  • How to choose an authentication strategy.
  • How to choose an authorization strategy.
  • How to flow identity across layers and tiers.
  • How to store user identities when not using Active Directory.
  • Caching and State
  • How to choose an appropriate caching technology.
  • How to determine what data to cache.
  • How to determine where to cache the data.
  • How to determine the expiration policy.
  • Communication
  • How to choose appropriate protocols for communication across layers and tiers.
  • How to design loose coupling across layers.
  • How to perform asynchronous communication.
  • How to pass sensitive data.
  • Composition
  • How to choose a composition pattern for the user interface (UI).
  • How to avoid dependencies between modules in the UI.
  • How to handle communication between modules in the UI.
  • Concurrency and Transactions
  • How to handle concurrency between threads.
  • How to choose between optimistic and pessimistic concurrency.
  • How to handle distributed transactions.
  • How to handle long running transactions.
  • Configuration Management
  • How to determine what information needs to be configurable.
  • How to determine where and how to store configuration information.
  • How to protect sensitive configuration information.
  • How to handle configuration information in a farm/cluster.
  • Coupling and Cohesion
  • How to choose an appropriate layering strategy for separation of concerns.
  • How to design highly cohesive components and group them within layers.
  • How to determine when loose coupling is appropriate between components within a layer.
  • Data Access
  • How to manage database connections.
  • How to handle exceptions.
  • How to improve performance.
  • How to handle binary large objects (blobs).
  • Exception Management
  • How to handle exceptions.
  • How to log exceptions.
  • How to provide notification when required.
  • Logging and Instrumentation
  • How to determine which information to log.
  • How to make the logging configurable.
  • How to determine what level of instrumentation is required.
  • User Experience
  • How to improve task efficiency and effectiveness.
  • How to improve responsiveness.
  • How to improve user empowerment.
  • How to improve look and feel. </>
  • Validation
  • How to determine where and how to perform validation.
  • How to validate for length, range, format, and type.
  • How to constrain and reject input.
  • How to sanitize output.
  • Workflow
  • How to choose the appropriate workflow technology.
  • How to handle concurrency issues within a workflow.
  • How to handle task failure within a workflow.
  • How to orchestrate processes within a workflow.
  • Step 5. Create Candidate Solutions
    Create a candidate architecture and along with architectural spikes and evaluate it against your key scenarios, hot spots, and deployment constraints.  The outcomes of this step are:

    • Baseline / Candidate Architectures
    • Architectural Spikes

    Iterative and Incremental Design
    You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture.  You don’t have to design your architecture in a single iteration. Do not get lost in the details; focus on the big steps and build a framework on which you can base your architecture and design.

    My Related Posts

  • New Release: patterns & practices App Arch Guide 2.0 Beta 1
  • patterns & practices App Arch Guide 2.0 Project
  • App Arch Guide 2.0 Overview Slides
  • Abstract for Application Architecture Guide 2.0
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Components
  • Key Software Trends
  • Cheat Sheet: patterns & practices Catalog at a Glance Posted to CodePlex
  • Cheat Sheet: patterns & practices Pattern Catalog Posted to CodePlex

  • J.D. Meier's Blog

    Now Available: patterns & practices Application Architecture Book

    • 12 Comments

    AAG2FrontCover-Small The Microsoft Application Architecture Guide, 2nd edition, is now available on Amazon and should be available on the shelf at your local bookstores soon.  The PDF was downloaded ~180,000 times.  This is the Microsoft platform playbook for application architecture.  You can think of it as a set of blueprints, and as your personal mentor for building common types of applications on the Microsoft platform:  mobile, RIA, services, and Web applications.

    The backbone of the guide is an information model for the application architecture space.  It’s a durable and evolvable map to give you a firm foundation of principles, patterns, and practices that you can overlay the latest technologies.  It’s your “tome of know-how.”  While it’s not a step-by-step for building specific applications, it is a pragmatic guide for designing your architecture, with quality attributes, key software principles, common patterns, and architectural styles in mind.  It’s holistic and focused on the key engineering decisions where you face your highest risks and most important choices.

    Key Features of the Book
    The book has several compelling features for slicing and dicing the application architecture body of knowledge:    

    • Canonical Frame.  This describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer will be described in terms of its focus, function, capabilities, common design patterns and technologies.
    • Application Types.  These are canonical application archetypes to illustrate common application types: Mobile, Rich Client, RIA, Services, and Web applications.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype is mapped to the canonical app frame. They are illustrative of common application types and not comprehensive or definitive.
    • Quality attributes.  This is a set of qualities and capabilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
    • Cross-cutting concerns.  This is a common set of categories for hot spots for key engineering decisions: Authentication, Authorization, Caching, Communication, Configuration Management, Exception Management, Logging and Instrumentation, State Management, and Validation.
    • Step-by-Step Design Approach.
    • Principles, patterns, and practices.   Using the application types, canonical frame, and cross-cutting concerns as backdrops, the guide provides an overlay of relevant principles, patterns, and practices.
    • Technologies and capabilities.  The guide provides an overview and description of the Microsoft custom application development platform and the main technologies and capabilities within it.

    Contents at a Glance
    The full Microsoft Application Architecture Guide is available for free on MSDN in HTML.  This is the contents of the guide at a glance:

    Chapters

    Appendices

    The Team
    Here is the team that brought you the guide:

    • Core Dev Team: J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
    • Test Team - Rohit Sharma, Praveen Rangarajan, 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; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

    Application Architecture Knowledge Base
    The guide was developed in conjunction with our Application Architecture Guide v2.0 Knowledge Base Project. The knowledge base project was used to inform and steer the guide during its development. The Application Architecture Knowledge Base includes a large amount of material that expands on specific topics in the main guide. It also includes draft material from the main guide that is targeted and packaged for more specific audiences, such as the Pocket Guide series.

    Key Links at a Glance
    Here are the key links at a glance:

  • J.D. Meier's Blog

    Using Live.com for RSS

    • 11 Comments

    Here's a quick set of steps for using Live.com (http://www.Live.com) as your RSS reader.  What I like about it is that I can log in to it from anywhere.  What I like most is that I can create multiple pages to organize my feeds.  This let's me focus my information.

    Here's the steps for creating pages and adding feeds to them: (you need to login to Live.com for these options)

    Adding a New Page

    1. Click Add Page.
    2. Click the drop-down arrow next to the new page you just created.
    3. Click Rename and type the name of your page (for example VS.NET)

    Adding Feeds

    1. Click Add stuff (upper left)
    2. Click Advanced options
    3. Put the path to the RSS feed you want (for example, http://blogs.msdn.com/jmeier/rss.xml), next to the Subscribe button.
    4. Click subscribe.  This will add the feed to your page.
    5. Either add more feeds or click Add stuff again (upper left) to close the options.

    Tip - If I need to search for a feed, I use a separate browser, do my search, and then paste the path next to the Subscribe button.  I don't like the Search for feeds option because I lose my context.

    I like Live.com for my Web-based RSS reading experience.  I use JetBrains Omea Pro for my desktop experience, where I do my heavy processing.  I think of this like my Outlook Web Access and Outlook desktop experiences.  My Web experience is optimized for reach; my desktop experience is optimized for rich.

  • J.D. Meier's Blog

    Now Available: Windows Azure Security Notes PDF

    • 1 Comments

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

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

    Download

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

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

    Reference

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

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

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

    App Arch Meta-Frame

    • 20 Comments

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

    AppArchMetaFrame

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

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

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

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

    Feedback
    What do you think? ...

    Additional Resources

  • J.D. Meier's Blog

    Application Architecture Guide 2.0 Final Release

    • 14 Comments

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

    Key Links

    Key Changes Since Beta 2

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

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

    ArchitectureMetaFrame

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

    Key Scenarios for the Guide

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

    Key Features of the Guide

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

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

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

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

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

    How To Reference Web Services and Databases During Development

    • 2 Comments

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

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

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

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

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

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

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

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

  • J.D. Meier's Blog

    Visual Model of Cloud Computing

    • 0 Comments

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

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

    VisualModelOfCloudComputing 

     

    Here are the key things to know:

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

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

  • J.D. Meier's Blog

    Kanban: The Secret of High-Performing Teams at Microsoft

    • 4 Comments

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

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

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

    Identify State Changes in Your Workflow

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

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

    image

    Identify Work Items

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

    image

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

    Set Limits for Work in Progress

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

    image

    Push Quality Upstream

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

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

    A Living Process

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

    Kanban for Execution Excellence

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

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

    You Might Also Like

  • J.D. Meier's Blog

    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 Developer Guidance Map

    • 2 Comments

    image

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

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

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

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

    Download the ASP.NET Developer Guidance Map

    Contents at a Glance

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

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

    image

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

    Enjoy.  Share the map with a friend.

  • J.D. Meier's Blog

    patterns and practices WCF Security Guidance Now Available

    • 20 Comments

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

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

    Videos
    Our videos step you visually through key guidance:

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

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

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

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

  • J.D. Meier's Blog

    Code Sharing in Team Foundation Server

    • 4 Comments

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

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

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

    Here's what seems to be our emerging guidance:

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

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

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

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

  • J.D. Meier's Blog

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

    • 16 Comments
    AppArchGuidev2

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

    5 Parts

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

    Chapters

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

    Key Scenarios
    The guide helps you address the following scenarios:

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

    Key Features

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

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

    ArchMetaFrame2

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

    RefAppArch

    Key Links

    Core Dev Team

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

    My Related Posts

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

    Security Principles

    • 5 Comments

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

    Turning Insights Into Action

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

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

    Core Security Principles

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

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

    Frame for Organizing Security Design Principles

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

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

    Auditing and Logging

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

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

    Authentication

    Here's our security design principles for authentication:

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

    Authorization

    Here's our security design principles for authorization:

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

    Configuration Management

    Here's our security design principles for configuration management:

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

    Cryptography

    Here's our security design principles for cryptography:

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

    Exception Management

    Here's our security design principles for exception management:

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

    Input / Data Validation

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

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

    Sensitive Data

    Here's our security design principles for sensitive data:

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

    Session Management

    Here's our security design principles for session management:

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

    Using the Security Design Principles

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

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Clearing Your Inbox

    • 9 Comments

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

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

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

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

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

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

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

    My Related Posts

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

    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

    New Release: Microsoft Enterprise Library 5.0

    • 1 Comments

    patterns & practices Enterprise Library 5.0 is now available on MSDN.   Microsoft Enterprise Library (EntLib) is a collection of application blocks (reusable software components) designed to address common cross-cutting concerns (data access, exception handling, logging, validation, ...etc.)  EntLib provides source code, test cases, and docs that you can use "as is" or extend as you see fit.  The goal of EntLib is to codify Microsoft recommended and proven practices for .NET application development.

    What's New in 5.0
    Enterprise Library 5.0 brings the following to the table:

    • Major architectural refactoring that provides improved testability and maintainability through full support of the dependency injection style of development
    • Dependency injection container independence (Unity ships with Enterprise Library, but you can replace Unity with a container of your choice)
    • Programmatic configuration support, including a fluent configuration interface and an XSD schema to enable IntelliSense
    • Redesign of the configuration tool to provide: a more usable and intuitive look and feel, extensibility improvements through meta-data driven configuration visualizations that replace the requirement to write design time code, a wizard framework that can help to simplify complex configuration tasks
    • Data accessors for more intuitive processing of data query results
    • Asynchronous data access support
    • Honoring validation attributes between Validation Application Block attributes and DataAnnotations
    • Integration with Windows Presentation Foundation (WPF) validation mechanisms
    • Support for complex configuration scenarios, including additive merge from multiple configuration sources and hierarchical merge
    • Optimized cache scavenging
    • Better performance when logging
    • Support for the .NET 4.0 Framework and integration with Microsoft Visual Studio 2010
    • Improvements to Unity: Streamlined configuration schema, a simplified API for static factories and interception, the capability to add interface implementation through interception, additional types of lifetime manager, deferred resolution (automatic factories), a reduction of the number of assemblies

    Key Links

  • J.D. Meier's Blog

    Timebox Your Day

    • 5 Comments

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

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

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

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

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

    My Related Posts

  • J.D. Meier's Blog

    Layers and Tiers

    • 2 Comments

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

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

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

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

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

    Layers 

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

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

    Two-Tier

    2Tier

    Three-Tier

    3Tier 

    N-Tier

    NTier

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

    My Related Posts

  • Page 2 of 47 (1,159 items) 12345»