J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    patterns & practices Performance Engineering

    • 4 Comments

    As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Performance Engineering.  Our performance engineering approach is simply a collection of performance-focused techniques that we found to be effective for meeting your performance objectives.  One of the keys to the effectiveness is our performance frame.   Our performance frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns.  We use the frame to perform effective performance design and code inspections.  Here's a preview of our cheat sheet so far.  You'll notice a lot of similarity with our patterns & practices Security Engineering.  It's by design so that you can use a consistent approach for handling both security and performance.

    Performance Overlay
    This is our patterns & practices Performance Overlay:

    PerformanceEngineering

    Key Activities in the Life Cycle
    This Performance Engineering approach extends these proven core activities to create performance specific activities.  These include:

    • Performance Objectives. Setting objectives helps you scope and prioritize your work by setting boundaries and constraints. Setting performance objectives helps you identify where to start, how to proceed, and when your application meets your performance goals.
    • Budgeting. Budget represents your constraints and enables you to specify how much you can spend (resource-wise) and how you plan to spend it.
    • Performance Modeling. Performance modeling is an engineering technique that provides a structured and repeatable approach to meeting your performance objectives.
    • Performance Design Guidelines. Applying design guidelines, patterns and principles which enable you to engineer for performance from an early stage.
    • Performance Design Inspections. Performance design inspections are an effective way to identify problems in your application design. By using pattern-based categories and a question-driven approach, you simplify evaluating your design against root cause performance issues.
    • Performance Code Inspections. Many performance defects are found during code reviews. Analyzing code for performance defects includes knowing what to look for and how to look for it. Performance code inspections to identify inefficient coding practices that could lead to performance bottlenecks.
    • Performance Testing. Load and stress testing is used to generate metrics and to verify application behavior and performance under normal and peak load conditions.
    • Performance Tuning.  Performance tuning is an iterative process that you use to identify and eliminate bottlenecks until your application meets its performance objectives. You start by establishing a baseline. Then you collect data, analyze the results, and make configuration changes based on the analysis. After each set of changes, you retest and measure to verify that your application has moved closer to its performance objectives.
    • Performance Health Metrics.   Identity the measures, measurements, and criteria for evaluating the health of your application from a performance perspective.
    • Performance Deployment Inspections. During the deployment phase, you validate your model by using production metrics. You can validate workload estimates, resource utilization levels, response time, and throughput.
    • Capacity Planning. You should continue to measure and monitor when your application is deployed in the production environment. Changes that may affect system performance include increased user loads, deployment of new applications on shared infrastructure, system software revisions, and updates to your application to provide enhanced or new functionality. Use your performance metrics to guide your capacity and scaling plans.

    Performance Frames
    Performance Frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application performance issues. The categories within the frame represent the critical areas where mistakes are most often made.

    Category Description
    Caching What and where to cache? Caching refers to how your applications caches data. The main points to be considered are Per user, application-wide, data volatility.
    Communication How to communicate between layers? Communication refers to choices for transport mechanism, boundaries, remote interface design, round trips, serialization, and bandwidth.
    Concurrency How to handle concurrent user interactions? Concurrency refers to choices for Transaction, locks, threading, and queuing.
    Coupling / Cohesion How to structure your application? Coupling and Cohesion refers structuring choices leading to loose coupling, high cohesion among components and layers.
    Data Access How to access data? Data Access refers to choices and approaches for schema design, Paging, Hierarchies, Indexes, Amount of data, and Round trips.
    Data Structures / Algorithms How to handle data? Data Structures and Algorithm refers to choice of algorithms; Arrays vs. collections.
    Exception Management How to handle exceptions? Exceptions management refers to choices / approach for catching, throwing, exceptions.
    Resource Management How to manage resources? Resource Management refers to approach for allocating, creating, destroying, and pooling of application resource
    State Management What and where to maintain state? State management refres to how your application maintains state. The main points to consider are Per user, application-wide, persistence, and location.


    Architecture and Design Issues
    Use the diagram below to help you think about performance-related architecture and design issues in your application.

    PerformanceIssues

    The key areas of concern for each application tier are:

    • Browser.  Blocked or unresponsive UI.
    • Web Server.  Using state affinity.  Wrong data types.  Fetching per request instead of caching.  Poor resource management.
    • Application Server.  Blocking operations.  Inappropriate choice of data structures and algorithms.  Not pooling database connections.
    • Database Server.  Chatty instead of batch processing.  Contention, isolation levels, locking and deadlock.

    Design Process Principles
    Consider the following principles to enhance your design process:

    • Set objective goals. Avoid ambiguous or incomplete goals that cannot be measured such as "the application must run fast" or "the application must load quickly." You need to know the performance and scalability goals of your application so that you can (a) design to meet them, and (b) plan your tests around them. Make sure that your goals are measurable and verifiable. Requirements to consider for your performance objectives include response times, throughput, resource utilization, and workload. For example, how long should a particular request take? How many users does your application need to support? What is the peak load the application must handle? How many transactions per second must it support? You must also consider resource utilization thresholds. How much CPU, memory, network I/O, and disk I/O is it acceptable for your application to consume?
    • Validate your architecture and design early. Identify, prototype, and validate your key design choices up front. Beginning with the end in mind, your goal is to evaluate whether your application architecture can support your performance goals. Some of the important decisions to validate up front include deployment topology, load balancing, network bandwidth, authentication and authorization strategies, exception management, instrumentation, database design, data access strategies, state management, and caching. Be prepared to cut features and functionality or rework areas that do not meet your performance goals. Know the cost of specific design choices and features.
    • Cut the deadwood. Often the greatest gains come from finding whole sections of work that can be removed because they are unnecessary. This often occurs when (well-tuned) functions are composed to perform some greater operation. It is often the case that many interim results from the first function in your system do not end up getting used if they are destined for the second and subsequent functions. Elimination of these "waste" paths can yield tremendous end-to-end improvements.
    • Tune end-to-end performance. Optimizing a single feature could take away resources from another feature and hinder overall performance. Likewise, a single bottleneck in a subsystem within your application can affect overall application performance regardless of how well the other subsystems are tuned. You obtain the most benefit from performance testing when you tune end-to-end, rather than spending considerable time and money on tuning one particular subsystem. Identify bottlenecks, and then tune specific parts of your application. Often performance work moves from one bottleneck to the next bottleneck.
    • Measure throughout the life cycle. You need to know whether your application's performance is moving toward or away from your performance objectives. Performance tuning is an iterative process of continuous improvement with hopefully steady gains, punctuated by unplanned losses, until you meet your objectives. Measure your application's performance against your performance objectives throughout the development life cycle and make sure that performance is a core component of that life cycle. Unit test the performance of specific pieces of code and verify that the code meets the defined performance objectives before moving on to integrated performance testing.  When your application is in production, continue to measure its performance. Factors such as the number of users, usage patterns, and data volumes change over time. New applications may start to compete for shared resources.

    Design Guidelines
    This table represents a set of secure design guidelines for application architects. Use this as a starting point for performance design and to improve performance design inspections.

    Category Description
    Caching Decide where to cache data. Decide what data to cache. Decide the expiration policy and scavenging mechanism. Decide how to load the cache data. Avoid distributed coherent caches.
    Communication Choose the appropriate remote communication mechanism. Design chunky interfaces. Consider how to pass data between layers. Minimize the amount of data sent across the wire. Batch work to reduce calls over the network. Reduce transitions across boundaries. Consider asynchronous communication. Consider message queuing. Consider a "fire and forget" invocation model.
    Concurrency Design for loose coupling. Design for high cohesion. Partition application functionality into logical layers. Use early binding where possible. Evaluate resource affinity.
    Coupling / Cohesion How to structure your application? Coupling and Cohesion refers structuring choices leading to loose coupling, high cohesion among components and layers.
    Data Structures / Algorithms Choose an appropriate data structure. Pre-assign size for large dynamic growth data types. Use value and reference types appropriately.
    Resource Management Treat threads as a shared resource. Pool shared or scarce resources. Acquire late, release early. Consider efficient object creation and destruction. Consider resource throttling.
    Resource Management How to manage resources? Resource Management refers to approach for allocating, creating, destroying, and pooling of application resource
    State Management Evaluate stateful versus stateless design. Consider your state store options. Minimize session data. Free session resources as soon as possible. Avoid accessing session variables from business logic.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Top 100 Blogs for Software Development Managers

    • 2 Comments

    Jurgen Appelo put together an impressive list of what he calls the Top 100 Blogs for Software Development Managers (Q3 2008).  I think it's a great way to find out about blogs you might not know about.

    The Top 10
    Here's the top ten blogs on the list:

    No, I didn't make the top 10.  I'm number 20.

    Blogs That Made the List
    In Jurgen's words:

    "The idea of this list is to promote popular blogs that are interesting to software development managers. Therefore, I ignored the blogs that did not have any (recent) content directly related to either requirements, design, coding, testing, management, process improvement or methodologies. I also discarded generic project management blogs without topics on software development practices. Likewise, I discarded the pure coding and technology blogs when they did not elevate to the level of "managing" or "ruminating about" software development. Last of all, I only considered blogs in the English language."

  • J.D. Meier's Blog

    What Makes Great Content?

    • 1 Comments

    Darren at ProBlogger asks, what is great content? ...

    I need to think about it.  For now, I'll say that great content ...

    • Surprises you.  You learn something you didn't expect.
    • Lifts you up.  You're inspired to act.
    • Echoes in your mind. It sticks. A new idea is forever etched into the canvas of your mind.
    • Makes you feel.  Maybe happy, maybe angry, maybe sad.  You don't feel indifferent.
    • Changes your game.  You can't wait to test your new skills on the unwary.
    • Leads you to an "ah ha".  It wrinkles your brain.  A shiver runs up your spine as you connect the dots.
    • Answers a burning question.  You always wondered why.  And now you know.
    • Solves a relevant, valuable problem.  Life tests us.  It's nice to have the answers.  

    To put it another way, it's got character, emotional appeal, and logic you can't help but to tango with.   It changes what you think, feel, or do.

    PS - I distinguish great content from great writing though they share some common attributes.

  • J.D. Meier's Blog

    Guidelines are Live!

    • 8 Comments

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

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

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

    My Related Posts

  • J.D. Meier's Blog

    App Arch Guide 2.0 Key Features

    • 4 Comments

    One of my colleagues on the patterns & practices team, David Hill, collected and distilled feedback on what people would like to see from the App Arch Guide 2.0 project:

    • Book, 180-200 pages in length. Descriptive & conversational tone. Lots of diagrams.
    • The guide will provide a description/overview of the Microsoft custom app dev platform and the main technologies and capabilities within it.
    • The guide will provide guidance to help folks choose the right architecture for their application.
    • The guide will provide guidance to help folks choose the right technologies for their application (with particular focus where there are multiple/overlapping MS technologies that could be applied).
    • The guide will provide guidance on the C3, architectural ‘–ility’ issues to be considered – performance, security, scalability, manageability, deployment, communication, etc.
    • The guide will not provide detailed how-to/checklist guidance on any one technology/app type/technique/pattern/-ility, but it will serve to provide jumping off points to more detailed guidance.
    • The guide will be structured around  a canonical app frame that 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.
    • The guide will describe 5-7 canonical application archetypes to illustrate common application types. Each archetype will be described in terms of the target scenarios, technologies, patterns and infrastructure it contains.  Each archetype will be mapped to the canonical app frame.
    • It will be noted that some apps will not fall cleanly into these archetypes, and that they are illustrative of common app types and not comprehensive or definitive.

    My Related Posts

  • J.D. Meier's Blog

    patterns & practices Security Engineering

    • 4 Comments

    As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Security Engineering.  Our security engineering approach is simply a collection of security-focused techniques that we found to be effective.  One of the keys to the effectiveness is our security frame.   Our security frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns.  We use the frame to perform security code and design inspections.  Here's a preview of our cheat sheet so far.

    Security Overlay
    This is our patterns & practices Security Overlay:

    SecurityEngineering

    It simply shows a common set of activities that customers already do, and then we overlay a set of security techniques.

    Summary of Key Activities in the Life Cycle 
    Our patterns & practices Security Engineering approach extends these proven core activities to create security specific activities. These activities include:

    • Security Objectives. Setting objectives helps you scope and prioritize your work by setting boundaries and constraints. Setting security objectives helps you identify where to start, how to proceed, and when you are done.
    • Threat Modeling. Threat modeling is an engineering technique that can help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.
    • Security Design Guidelines. Creating design guidelines is a common practice at the start of an application project to guide development and share knowledge across the team. Effective design guidelines for security organize security principles, practices, and patterns by actionable categories.
    • Security Design Inspection. Security design inspections are an effective way to identify problems in your application design. By using pattern-based categories and a question-driven approach, you simplify evaluating your design against root cause security issues.
    • Security Code Inspection. Many security defects are found during code reviews. Analyzing code for security defects includes knowing what to look for and how to look for it. Security code inspections optimize inspecting code for common security issues.
      Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans.
    • Security Deployment Inspection. When you deploy your application during your build process or staging process, you have an opportunity to evaluate runtime characteristics of your application in the context of your infrastructure. Deployment reviews for security focus on evaluating your security design and configuration of your application, host, and network.

    Security Frame
    Security frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application vulnerabilities. The categories within the frame represent the critical areas where mistakes are most often made.

    Category Description
    Auditing and Logging Who did what and when?  Auditing and logging refer to how your application records security-related events.
    Authentication Who are you?  Authentication is the process where an entity proves the identify of another entity, typically through credentials, such as a user name and password.
    Authorization What can you do?  Authorization is how your application provides access controls for resources and operations.
    Configuration Management Who does your application run as?  Which databases does it connect to?  How is your application administered?  How are these settings protected?  Configuration management refers to how your application handles these operations and issues.
    Cryptography How are you handling secrets (confidentiality)?  How are you tamper proofing your data or libraries (integrity)?  how are you providing seeds for random values that must be cryptographically strong?  Cryptography refers to how your application enforces confidentiality and integrity.
    Exception Management

    When a method call in your application fails, what does your application do?  How much do you reveal?  Do you return friendly information to end users?  Do you pass valuable exception information back to the caller?  Does your application fail gracefully?

    Input and Data Validation How do you know that the input your application receives is valid and safe?  Input validation refers to how your application filters, scrubs, or rejects input before additional processing.  Consider constraining input through entry points and encoding output through exit points.  Do you trust data sources such as databases and file shares?
    Sensitive data How does your application handle sensitive data?  Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores.
    Session Management How does your application handle and protect user sessions?  A session refers to a session of related interactions between a user and your Web application.

    Architecture and Design Issues
    Use the diagram below to help you think about architecture and design issues in your application.

    SecurityDesignIssues

    The key areas of concern for each application tier are:

    • Browser. Authenticating users on the client. Protecting sensitive data on the wire.  Preventing common attacks such as parameter manipulation and session hijacking.
    • Web Server. Validating untrusted input. Exception handling. Authorizing your users. Securing the configuration.
    • Application Server. Authenticating and Authorizing users. Auditing and logging. Protecting sensitive data on the wire. Securing configuration.
    • Database Server. Protecting sensitive data in the database. Securing configuration. Locking down database users.

    Design Guidelines
    This table represents a set of secure design guidelines for application architects. Use this as a starting point for secure design and to improve security design inspections

    Category Guidelines
    Auditing and Logging Identify malicious behavior. Know what good traffic looks like. Audit and log activity through all of the application tiers. Secure access to log files. Back up and regularly analyze log files.
    Authentication    Partition site by anonymous, identified, and authenticated area. Use strong passwords. Support password expiration periods and account disablement. Do not store credentials (use one-way hashes with salt). Encrypt communication channels to protect authentication tokens. Pass Forms authentication cookies only over HTTPS connections.
    Authorization Use least privileged accounts. Consider authorization granularity. Enforce separation of privileges. Restrict user access to system-level resources.
    Configuration Management Use least privileged process and service accounts. Do not store credentials in plaintext. Use strong authentication and authorization on administration interfaces. Do not use the LSA. Secure the communication channel for remote administration. Avoid storing sensitive data in the Web space.
    Cryptography Do not develop your own. Use tried and tested platform features. Keep unencrypted data close to the algorithm. Use the right algorithm and key size. Avoid key management (use DPAPI). Cycle your keys periodically. Store keys in a restricted location.
    Exception Management Use structured exception handling. Do not reveal sensitive application implementation details. Do not log private data such as passwords. Consider a centralized exception management framework.
    Input and Data Validation Do not trust input; consider centralized input validation. Do not rely on client-side validation. Be careful with canonicalization issues. Constrain, reject, and sanitize input. Validate for type, length, format, and range.
    Parameter Manipulation Encrypt sensitive cookie state. Do not trust fields that the client can manipulate (query strings, form fields, cookies, or HTTP headers). Validate all values sent from the client.
    Sensitive Data Avoid storing secrets. Encrypt sensitive data over the wire. Secure the communication channel. Provide strong access controls on sensitive data stores. Do not store sensitive data in persistent cookies. Do not pass sensitive data using the HTTP-GET protocol.
    Session Management Limit the session lifetime. Secure the channel. Encrypt the contents of authentication cookies. Protect session state from unauthorized access.

    Patterns
    Design patterns in this context refer to generic solutions that address commonly occurring application design problems.  Some of the patterns identified below are well known design patterns. Their use in certain scenarios enables better security as a secondary goal. Some of the main patterns that help improve security are summarized below:

    • Brokered Authentication. Use brokered authentication where the application validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the application.
    • Direct Authentication. Use direct authentication where the application acts as an authentication service to validate credentials from the client. The credentials, which include proof-of-possession that is based on shared secrets, are verified against an identity store.
    • Roles-based authorization. Role-based authorization is used to associate clients and groups with the permissions that they need to perform particular functions or access resources. When a user or group is added to a role, the user or group automatically inherits the various security permissions.
    • Resource-based authorization. Resource-based authorization is performed on a resource, depending on the type of the resource and the mechanism used to perform authorization. Resource-based authorization can be based on access control lists (ACLs) or URLs.
    • Trusted Subsystem. The application acts as a trusted subsystem to access additional resources. It uses its own credentials instead of the user's credentials to access the resource. The application must perform appropriate authentication and authorization of all requests that enter the subsystem. Remote resources should also be able to verify that the midstream caller is a trusted subsystem and not an upstream user of the application that is trying to bypass access to the trusted subsystem.
    • Impersonation and Delegation. The application uses original user’s credentials to access the resource. The application must perform appropriate authentication and authorization of all requests that enter the subsystem and then impersonation or delegation while accessing resources. Remote resources should also be able to verify that individual users are trusted to access the resource.
    • Transfer Security. Sensitive data passed between layers or remote tiers should be encrypted and signed to ensure confidentiality and integrity of the data.
    • Exception Shielding. Sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the application’s inner workings.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    The Architecture Journal

    • 1 Comments

    As part of our patterns & practices App Arch Guide 2.0 Project, I'm scanning Microsoft for helpful architect and architecture related resources.  One helpful resource I found is The Architecture Journal.

    The Architecture Journal
    Here's the journal's description from their home page:

    “The Architecture Journal is an independent platform for free thinkers and practitioners of IT architecture. New editions are issued quarterly, with articles designed to offer perspective, share knowledge, and help you learn the discipline and pursue the art of IT architecture.”

    Sounds like just what the doctor ordered!

    Article Map
    To make it easy for my team to find the articles, I created an index that matches the MSDN tree.  We'll be digging through the articles throughout our project.  Creating the map actually helped me quickly see the scope and range of the articles, so it was a great exercise.

    July 2008 - Identity Management

    April 2008 - The Role of an Architect

    January 2008 - Mobile Architecture

    October 2007 - Software + Services

    July 2007 - Web Architecture

    April 2007 - Infrastructure Architecture

    January 2007 - Composite Applications

    October 2006 - Software Factories

    July 2006 - Data By Design

    April 2006 - Generation Workflow

    January 2006 - Strategies for Design

    July 2005 - Integration Interchange

    January 2005

    July 2004

    April 2004

    January 2004

    Architecture Journal Links
    Here's the key links for The Architecture Journal:

    My Related Posts

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

    Services Layer

    • 7 Comments

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

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

    ServicesLayer

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

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

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

    Additional Resources

    My Related Posts

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

    Layers and Components

    • 11 Comments

    In my previous post, I summarized layers and tiers.  In this post, I'll walk through the key components of the layers.  This exercise is part of our patterns & practices App Arch Guide 2.0 project.

    Layers and Components
    Here's a visual of a layered architecture and relevant components:

    LayeredArch

    Note that this is just an example of common components and layers.  Your scenarios may vary.

    Presentation Layer Components
    Here's typical presentation layer components:

    • User interface (UI) components. Your user interface components (controls) provide a way for users to interact with your application. They render and format data for users and acquire and validate data coming in from them.
    • User process components. Your user process components help synchronize and orchestrate user interactions. This way the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction patterns can be reused by multiple user interfaces.

    Business Layer Components
    Here's typical business layer components:

    • Application Facade. (Optional).  Your application facade maps your business logic to your application.  It's optional and it depends on how reusable and generic your business logic is.  If your business logic was written specifically for your application, then you probably don't need an application facade.
    • Business components. Your business components implement business rules and perform business tasks.
    • Business workflows. Your business workflows define and coordinate long-running, multi-step business processes.  They can be implemented using business process management tools.
    • Business entity components. Your business entity components represent actual business entities (for example products or orders.)  You use them to pass data between components.  They're usually data structures (such as DataSets, DataReaders, or XML streams), but they can also be implemented using custom object-oriented classes.

    Data Layer Components
    Here's typical data layer components:

    • Data access logic components. Data access components abstract the logic necessary to access. Doing so centralizes data access functionality and makes it easier to configure and maintain.
    • Data Helpers / Utilities.   
    • Service agents. Your service agents help you call external services.  They do so by mapping the format of the data exposed by the service to the format your application uses, as well as help manage the semantics of calling the services.

    Cross-Cutting

    • Cross-cutting components.  This includes components  components to perform exception management, to authorize users to perform certain tasks, and to communicate with other services and applications.

    Feedback
    Does this match what you see in practice?

    Additional Resources
    Here's some relevant links:

    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

  • J.D. Meier's Blog

    Scenario Frames for Presentation, Business, Data, and Services

    • 6 Comments

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

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

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

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

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

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

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

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

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

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

    My Related Posts

  • 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

    patterns & practices App Arch Guide 2.0 Project

    • 55 Comments

    It's long overdo, but we're kicking off a project for v2 of the patterns & practices Application Architecture Guide.  You might be familiar with Tom Hollander's post "Application Architecture for .NET" 2 - The Revenge.  Well, now it's time for results.

    Solution Architects / Dev Leads / Developers
    Our primary audience is solution architects, developer leads, and developers.

    Principles, Patterns, and Practices
    I'm a principles, patterns, and practices kind of a guy, so expect the guide to be principle-based, durable, and evolvable.

    CodePlex Community Site
    It's a work in progress and it's early, but you can follow along here:

    Topics
    Here's some of the areas we're looking at for the guide:

    Macro

    • App Types
    • Arch Styles
    • Patterns
    • Layers, Tiers, and Components
    • Architectural Hot Spots
    • Presentation Layer
    • Business Layer
    • Data Access Layer
    • Services Layer
    • Services Design
    • Quality Attributes
    • Trends
    • Security Engineering
    • Performance Engineering
    • Baseline Architectures
    • Deployment Patterns

    Micro

    • Choosing Presentation Technologies
    • Choosing Data Access Technologies
    • Choosing Workflow Technologies
    • Inline SQL vs. sprocs
    • MVC vs. MVP
    • Domain model driven vs. structure driven

    Your Feedback
    What would you like to see in the guide?

  • J.D. Meier's Blog

    SourcesOfInsight.com is Now Live

    • 1 Comments

    Sources of Insight.com is now live.  It's a blog I use to share insights and actions for improving work and life.  I have a lot of mentees at Microsoft so it helps me scale.

    I have a very simple goal for the blog.  It's to share the best insight and action to help you be your best in any situation.

    It's a work in progress, but I treat it as a living KB of the best insight I can find from books, people, and quotes.  While books are great mentors, I also draw from a lot of people.  Some mentors have a knack for saying just the right things at just the right times.   Sometimes the right quote says it best.

    To make the most of the sight, first, start with the About.  That will give you a pretty good sense of what the blog is about.  Next, visit the Archives.   Unfortunately, I haven't fixed all my links yet, so the Archives is the fastest way to hop around.

    I'm still experimenting with format, style, and voice so that will continue to evolve.  Sometime's it's tough for me to switch gears from writing technical guidance to writing life changing insight.  The engineer in me wants precision.  The writer in me wants impact.  In the meantime, I can say that my mentees, friends, family, and colleagues have been using the nuggets to improve the quality of their lives.

    Enjoy,
    JD

  • J.D. Meier's Blog

    My Favorite Software Books

    • 3 Comments

    Aside from people, I think books are the best mentors.  Ajoy mentioned to me that people like to know what books our team actually uses on the job.  I can't speak for the patterns & practices team, at large, but I thought I would help bootstrap by creating a list of my favorite software books.  The list includes the books that I continue to mine for principles, patterns, and practices for shaping software.

  • J.D. Meier's Blog

    Lessons Learned from Peaceful Warrior

    • 4 Comments

    Have you seen Peaceful Warrior?  It's a pretty simple movie, but it's full of lessons.  Probably the most important lesson is how to keep getting back up when life knocks you down and how to continue to follow your dreams, even after your world is shattered.   I shared my lessons learned from Peaceful Warrior with some colleagues and they suggested I post them.  Here it goes ...

    Where Are You, What Time is It, What Are You
    This theme echoed throughout the movie:

    • Where are you? .... HERE.
    • What time is it? ... NOW.
    • What are you? ... THIS MOMENT.

    Favorite Lessons

    • There are no ordinary moments
    • A Warrior acts; only a fool reacts.
    • What do you do if you can’t do what you were born to do?  Everything has a purpose -- it’s up to you to find it.
    • Make every move about the move -- that one moment in time.
    • Don't fall into the trap -- If only I had this, I'd be ...  If only ... , I'd get to be happy. 
    • If you don't get what you want, you suffer.  If you get what you want, you still suffer.
    • You control you.  Master you.
    • Don't pin your success on outcomes.
    • The people that are the hardest to love, probably need it the most.
    • Take out the trash.  Clear you mind of everything you don't need (doubt, past failures, future victories, ... etc.)
    • Develop the wisdom to use the right leverage at the right time.
    • Knowledge is not the same as wisdom.  Knowledge is knowing -- wisdom is doing.
    • You'll never be better than anybody, the same way you'll never be any less.

    Additional Lessons Learned 
    Here’s my lessons from peaceful warrior:

    • Experience the moment.  Be fully engaged in the moment.
    • Limiting beliefs.  Don't become a victim of your own limiting beliefs.  Stay adaptable.
    • Don't miss out on what's going on by letting your mind fill up with noise.
    • Trash is anything that keeps you from the only thing that matters which is right here and now.
    • Be right here, right now.  Don't be in the past, gloating.  Be in the present living.
    • All you have is right now.
    • Let got of attachments.
    • Meditate.  Be able to clear you mind and focus on the moment.
    • Don't let your emotions control you.
    • Enjoy the here and now -- that's the secret.
    • Savor the moment.
    • Other people's perspectives don't matter as much if you have your own perspective.
    • Find your purpose.
    • Assign meaning.  You're the most important meaning maker in your life.
    • There's never nothing going on (take a look around.)
    • Don't give up the one thing you control -- your response.
    • The habit is the problem.  Wake up and experience the moment.
    • Be conscious of your choices.
    • Be responsible for your actions.
    • Every action has its price and it's pleasure.
    • Most people don't live at all.
    • When you feel fear, use this sword.
    • Don't take for granted what you can do; don't be sloppy with your life.
    • Devote life to a higher purpose; service to others.
    • The warrior doesn't give up what they love.
    • The warrior finds the love in what they do.
    • The warrior is not about invincibility.
    • The warrior chooses to act; the coward reacts.
    • Life is about 20 seconds in front of the judges.
    • A warrior does what they love.  A warrior does the thing they are put here to do.
    • Don't live in fear of failure
    • It's the journey, not the destination.
    • Warrior is not about perfection.  Warrior is about absolute vulnerability.
    • Life is about choice.
    • Actions speak for themselves.
  • J.D. Meier's Blog

    Software Methodologies at a Glance

    • 1 Comments

    I like to draw from a variety of sources for software engineering principles, patterns, and practices.  To be able to do this, I usually need to create information models that let me quickly scan bodies of knowledge.  Once I can frame out a space, it's a lot easier to drill into areas looking for gold.  I can also step back and see across approaches and this helps me see underlying principles or key distinctions between approaches.

    XP, MSF Agile, RUP, and Microsoft Solution Framework
    To compare process methodologies, here are some skeletal information models I've used:

    While the frames aren't entirely consistent, I can still quickly scan the methodologies and get a good sense of what the key ideas, activities, artifacts, and practices are.

    My Related Posts

  • J.D. Meier's Blog

    10 Success Patterns for PMs

    • 7 Comments

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

    10 Success Patterns

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

    Success Patterns Explained
    Here's the essence of each:

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

    Do you have any favorite success patterns to share?

    My Related Posts

  • J.D. Meier's Blog

    Lessons Learned from Per

    • 9 Comments

    I like to learn from everyone around me.  One of my most influential mentors has been my manager, Per.  Here’s a highlight of some of the lessons I learned from Per over the years:

    Communication

    • Consolidate communication.   Chunky over chatty.  Rather than a random stream of ideas, consolidate down to a theme.  Rather than a bunch of mini-mails, consolidate to a more meaningful message. 
    • Distinguish between phases of communication.  Walt Disney used three stages for ideas: Dreamer, Realist, and Critic.  Dreamer is the vision, Realist is the steps, Critic is the constraints and limits.  In practice, Per encourages first brainstorm, then critique.

    Cutting Questions

    • Do you influence or do you own?   Distinguish between when you own the decision versus when you influence.  If you influence, but don’t own, reset your own expectations.  Responsibility without authority is a common pitfall. 
    • Does it matter?   In the grand scheme of things, does this particular issue matter.
    • Five customers under your belt?  If you don’t have five customers you can point to that stand behind what you’re doing, it’s a flag.  As simple as this test sounds, I’ve used it many times to ensure project success.
    • Is it the right thing to do?  First figure out the right thing to do, then figure out what you can do based on the circumstances.
    • Is it working?  If you keep taking the same approach, but it’s not working, you need to change your approach.  It’s simple, but you’d be surprised how many people get stuck.
    • Next steps?   Asking “next steps?” at the end of your meeting is a pretty crisp way of turning talk into action.
      What’s the agreement?  When you’re not sure why things aren’t happening as you expect, check the agreement.  You might find you don’t really have one.
    • What’s the solution?  If you’re spending too much time on the problem, switch by asking, “what’s the solution?”
    • What’s their story?  If you don’t get why another person or team isn’t doing what you want, figure out what their side of the story is.  (see What’s Their Story)
      What’s your gut say?  If you find a decision isn’t sitting right, check your gut.   While the numbers may say one thing, your intuition may be telling you a deeper story.

    Influence

    • Argue the data.  Rather than argue your opinion, argue the data.  Arguing the data keeps it more objective.  It can also be more convincing.
    • Don’t state the conclusion.  Rather than state your conclusions, show the data that leads to your conclusions.  Even if you know the “right answer,” showing the data can help others get on board.
    • Lead the horse to water.   Let them connect the dots.  You can draw a dotted line, but let your audience connect the dots. 
      Mental Judo.  This is Per’s phrase for Ward Cunninham’s uncanny ability to lead people to a conclusion through rhetoric and stories.
    • Set the frame.   Frame the problem or solution so that you have a common backdrop to share understanding.  This will help set boundaries, create agreements, and improve communication.
    • They’re not engaged.  If you notice a lack of engagement throughout your meeting, there’s a good chance that you don’t have rapport.  If you don’t have rapport, you won’t effectively influence.
    • They’re not on board.  You should be able to tell whether somebody is on board.  If they aren’t, then don’t kid yourself.
      You didn’t agree on values.  Recognize when you don’t have the same values.  Do they value time or do they value a level of results?  If you don’t share the values, you can expect problems in agreements, prioritization, expectations, and results.
    • You didn’t have buy in.  Just because somebody shakes their head yes, doesn’t mean they are bought in.  You don’t want somebody to tell you yes, just to drag their feet.

    Organizational Prowess

    • Call it an experiment.  In a risk adverse environment, it can help to call a project an experiment.  It’s a simple but effective metaphor to help people think about trying something new.
    • Do you influence or do you own?  If you don’t own the decision, you don’t own it.  Period.  You can attempt to influence, but at the end of the day, you’re not the owner.   That doesn’t mean don’t try your best.  Just don’t be surprised if it’s not the decision you wanted and don’t take it personally.
    • Expose the approach.   People may not agree on the implementation or the results, but sharing the approach is a good place to start.  Exposing the approach gives you a chance to improve the approach.  Exposing the approach can also build trust, particularly if everybody buys in.
    • Expose the thinking.  This is similar to showing your homework.  If you expose the thinking, then you can improve the thinking.  You can also help build trust.  You may not get to the right answer, but showing how you got there helps bring people along with you.
    • Get consensus.  Where possible and time permits, get folks on board.  If there’s resistance, this can be a flag that you’re off in the wrong direction.  If it’s a decision where you need everybody’s skin in the game, then you’ll want them on board helping push the ball forward versus dragging their feet.
    • Get smart folks on the bus.  This is just a general belief that if you have smart people around, the right things will happen.  It’s about people over process.
    • Slides are a forcing function.    Slides are a great way to get folks on the same page, or at least start the dialogue.  If you can’t show your ideas in a slide, then you don’t have a well-formed message for others.  Doing slides helps create a strawman of the thoughts that can be reviewed and improved.  Slides can help turn thoughts into action.

    Results

    • Change your approach.  If it’s not working; change your approach.
    • Change yourself first.  You can change yourself faster than you can change others.  Seriously.
    • Chunk it down.   If you can’t release something in a healthy rhythm, chunk it down.
    • Divide and Conquer.  If you have an overwhelming challenge, divide and conquer.(See Divide and Conquer - One Step at a Time)
    • Drive or Be Driven.  If you don’t drive it, you’ll be driven by somebody else.
      Get it out and get feedback.  Good ideas often die because there’s no action or momentum.  If you get something out, you can get feedback and start to improve it.
    • Give attribution.  In our industry, acknowledgement is important.  Be sure to give attribution where it’s due.
    • Focus.   If there’s one place where projects fail or people fail, it’s a lack of focus.  Focus is your friend.  If you’re not getting results, narrow the focus. 
    • Follow your passion.  Where there’s passion, there’s strength.
    • Forcing functions.  Use meetings, slides, and reviews as forcing functions to drive results.
    • Model the best.   This is Per’s phrase for my approach of finding the best people and modeling their success. 
    • Play to your strengths.  Per’s a fan of the book, Good to Great, and he believes in focusing on your strengths rather than your weaknesses.
    • Rattle the cage.  Challenge the thinking.  Challenge ideas.  Challenge yourself.  Don’t fall into the trap of the status quo.
    • Ship it!  This is one of Per’s favorite sayings which characterizes the emphasis on getting results and making impact.   He’s learned that a rhythm of shipping produces results while failure to ship is how teams fail at Microsoft. 

    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

    Model-Driven Approaches

    • 4 Comments

    When people ask me my take on model-driven approaches, I think of two ends of the spectrum -- human and the machine.

    Key Points 

    • Model for humans.  For humans, I find using a whiteboard (whiteboard modeling) works well -- it's universal.
    • Model for machines.  For machines, I find speaking closer to the code is a good thing and design is rarely a clean model.
    • Model to learn.  I've found modeling more useful when you throw it away -- it's a learning tool.  Model so you get it, then go to it.  I think the key is that the model is a map, not the actual territory.  The usefulness of a map is actually decoupling from the complexity and creating a simpler lens.
    • Model to share.  I think the real value of models is when you create a way to share the problem or solution in a simplified way.  This helps for sharing a vision of the end in mind, as well as getting more sustained thinking around the problem.

    Model-Driven Code
    I've never experienced an effective modeling approach that turns visuals of systems into code, where the model doesn't get in the way.  At some point, the model stops being useful for humans or stops being useful to the machine.  As a result, I've never really been a fan of model-driven approaches that are coupled to code in practice, although they're always interesting in theory.   While I'm open to the idea, I just haven't seen it.  Am I missing out?

    Effective Modeling for Shaping Software
    While I'm not a fan of most visual modeling tools, there’s some very real modeling approaches I find to be effective (which is more about modeling for the humans to understand what matters.)  I find that light-weight, human-oriented models are particularly effective for shaping software around quality attributes.  For example:

    My Related Posts

  • J.D. Meier's Blog

    Agile Guidance

    • 2 Comments

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

    AgileGuidanceEngineering2

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

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

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

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

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

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

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

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

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

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

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

    My Related Posts

  • J.D. Meier's Blog

    Software Guidance Share

    • 1 Comments

    I'm testing another version of the home page on Software Guidance Share.  Software Guidance Share is a perpetual work in progress.  I think of it as my quick-and-dirty guidance KB for developers and solution architects.  I continuously refactor information into reusable nuggets.  I also test ways to browse the guidance and find relationships among the nuggets.

    Here's a couple of example scenarios:

    I haven't fleshed out some of the areas, but the Wiki gives me a lot of flexibility and it's easy to course-correct.  In other words, it's more adaptable than adapted.

  • J.D. Meier's Blog

    Designing an Authentication and Authorization Strategy

    • 2 Comments

    What are the key steps to designing an effective authentication and authorization strategy?  The keys are knowing your user stores, role stores, and who need to access what or perform which operations.   In this post, I share the approaches we've used in two of our patterns & practices guides.  These are the approaches we've used to help customers design successfully design their authentication and authorization approaches.

    Designing an Authentication and Authorization Strategy - v1
    When we first wrote Building Secure ASP.NET Applications, here's the meta-process we came up with for working through your authentication and authorization strategies:

    1. Identify resources
    2. Choose an authorization strategy
    3. Choose the identities used for resource access
    4. Consider identity flow
    5. Choose an authentication approach
    6. Decide how to flow identity

    For elaboration, see Authentication and Authorization.

    Designing an Authentication and Authorization Strategy - v2
    When we recently wrote Improving Web Application Security, we made some revisions:

    1. Identify your user stores.
    2. Identify your role stores.
    3. Identify resources you need to access and operations you need to perform.
    4. Identify which identities need to access the resources and perform the operations.
    5. Choose your authentication and authorization strategies.

    Personally, I've found it really cuts to the chase if you start with your user stores and role stores, since they tend to be somewhat fixed. 

    Identities
    When you think through the identities, I've found it helpful to think in terms of who needs to access which resources or perform which actions.  Consider the following:

    • Original caller
    • Process identity
    • Service account
    • Custom identity
    • Role

    Resource Types
    When you think through the resource types, I find it helpful to think in terms of:

    • System
    • Application
    • User

    Authorization Strategies
    When thinking through the authorization strategies, I find it helpful to consider:

    • Role-based
    • Resource-based
    • Operation-based

    Resource Access Patterns
    When thinking through the resource access patterns, I find it helpful to consider:

    • Trusted subsystem model
    • Impersonation/delegation model

    Designing authentication and authorization can be a gnarly topic.  I hope the scaffolding above helps you find a path that works for you.

  • J.D. Meier's Blog

    WCF Security Guide is Now Available in HTML

    • 2 Comments

    Our guide, patterns & practices Improving Web Services Security:Scenarios and Implementation Guidance for WCF is now available in HTML.

  • Page 31 of 43 (1,069 items) «2930313233»