J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

September, 2008

  • J.D. Meier's Blog

    Key Architecture Resources

    • 4 Comments

    As part of our patterns & practices App Arch Guide 2.0, I put together a short list of resources I want to make sure my team is spending time in:

    As far as some community sites, here's a short list of ones I've found helpful:

    What's your favorite haunts for architecture nuggets?

    My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • Abstract for Application Architecture Guide 2.0
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Tiers
  • Layers and Components
  • Services Layer
  • Scenario Frames for Presentation, Business, Data and Services
  • patterns & practices Security Engineering
  • patterns & practices Performance Engineering
  • Key Software Trends
  • J.D. Meier's Blog

    Scenario-Based Architecture Evaluation Methods

    • 0 Comments

    I'm a fan of scenarios.  Whether you use scenarios for scenario-driven development,  scenario-based evaluations, competitive assessments or for shaping products ...  scenarios are where the rubber meets the road.  I think scenarios are particularly effective for evaluating architectures and for making architecture trade-off decisions.  I wrote a short post on Shaping Software that reiterates a mantra I frequently use ... you can't evaluate architecture in a vacuum.

  • J.D. Meier's Blog

    Arch Frame Posted to CodePlex

    • 1 Comments

    Today we posted our Arch Frame to CodePlex.  Wednesdays are ship days (I don't ship on Fridays.)  The App Arch Frame is a collection of hot spots you hit when building line of business (LOB) applications.  The key to the buckets is that they organize actionable principles, patterns, and practices.  They also help us overlay patterns & practices solution assets.  You give feedback either in the comments here, or on the CodePlex page:

    My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • Abstract for Application Architecture Guide 2.0
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Tiers
  • Layers and Components
  • Services Layer
  • Scenario Frames for Presentation, Business, Data and Services
  • patterns & practices Security Engineering
  • patterns & practices Performance Engineering
  • Key Software Trends
  • J.D. Meier's Blog

    Abstract for Application Architecture Guide 2.0

    • 12 Comments

    A few people have asked me for an abstract on the patterns & practices Application Architecture Guide 2.0 project (a work in progress).  Here it is.

    Conceptual Framework
    A picture is worth a thousand words.  Here's the conceptual framework for the guide:

    AppArchMetaFrame

    Tagline

    "How to put the legos together"

    Abstract
    The purpose of the Application Architecture Guide 2.0 is to  improve your effectiveness building applications on the Microsoft platform.   The primary audience is solution architects and developer leads.  The guide will provide design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.

    Key Features

    • Canonical app frame - 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.
    • App Types - 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. 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 will overlay 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.

    Key Scenarios

    • Help you choose the right architecture for your application.
    • Help you choose the right technologies
    • Help you make more effective choices for key engineering decisions.
    • Help you map appropriate strategies and patterns.
    • Help you map relevant patterns & practices solution assets.

    My Related Posts

  • patterns & practices App Arch Guide 2.0 Project
  • App Arch Meta-Frame
  • App Types
  • Architecture Frame
  • App Arch Guidelines
  • Layers and Tiers
  • Layers and Components
  • Services Layer
  • Scenario Frames for Presentation, Business, Data and Services
  • patterns & practices Security Engineering
  • patterns & practices Performance Engineering
  • Key Software Trends
  • J.D. Meier's Blog

    Sources Of Insight is One Month Old

    • 2 Comments

    A few of my mentees mentioned that I'm not posting enough about effectiveness on my MSDN blog.  That's true.  I'll be posting more on effectiveness in the near future.  Meanwhile, I've been posting insights and actions for work and life on Sources of Insight.  It's how I scale myself and how I create reusable nuggets for my mentees.  Sources Of Insight is one month old.  Although the blog is only a month old, I ported my nuggets from my earlier blog, The Bookshare.  There are more than 250 nuggets that will help you improve your life.  Each nugget is carefully crafted to help you turn insights into action and improve your effectiveness.

  • J.D. Meier's Blog

    Architecture Frame

    • 10 Comments

    As part of our patterns & practices App Arch Guide 2.0 project, we've put together an arch frame.  The arch frame is simply a collection of hot spots.  These aren't just any hot spot though.  These hot spots represent key engineering decisions, anti-patterns, and opportunities for improved designs for more effective technical architectures.  This Arch Frame is part of the larger App Arch Meta Frame.  Think of it as an important branch off the main tree.  It serves as a lens to cut through a lot of information to get to the most meaningful and actionable guidance.

    Categories
    The following categories are the "hot spots" in the architecture frame:

    • Authentication and Authorization
    • Caching and State
    • Communication
    • Composition
    • Concurrency and Transactions
    • Configuration Management
    • Coupling and Cohesion
    • Data Access
    • Exception Management
    • Logging and Instrumentation
    • User Experience
    • Validation
    • Workflow

    What you might notice about the hot spots is that they map to common cross-cutting concerns when building applications.  You also might notice that the hot spots map to various patterns & practices solution assets.  For example, Enterprise Library includes blocks for caching, data access, exception management, logging, validation ... etc.  The categories also map to very actionable decisions where you there's relevant principles, patterns, and practices.  These buckets also contain many anti-patterns.  The worst anti-patterns are the "do overs."  Nobody wants a "do over" architecture.

    Key Engineering Decisions
    This table summarizes the key engineering decisions within each hot spot:

    Category Key Engineering Decisions
    Authentication and Authorization
  • How to store user identities.
  • How to authenticate callers.
  • How to authorize callers.
  • How to flow identity across layers and tiers.
  • Caching and State
  • How to choose effective caching strategies.
  • How to improve performance with caching.
  • How to improve security with caching.
  • How to improve availability with caching.
  • How to keep the cached data up to date.
  • How to determine when and why to use a custom cache.
  • How to determine what data to cache.
  • How to determine where to cache the data.
  • How to determine the expiration policy and scavenging mechanism.
  • How to load the cache data.
  • How to monitor a cache.
  • How to synchronize caches across a farm.
  • How to determine which caching technique provides the best performance and scalability for a specific scenario and configuration.
  • How to determine which caching technology complies with the application's requirements for security, monitoring, and management.
  • Communication
  • How to communicate between layers / tiers.
  • How to perform asynchronous communication.
  • How to pass sensitive data.
  • Composition
  • How do design for composition.
  • How to design loose coupling between modules.
  • How to handle dependencies in a loosely coupled way.
  • 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.
  • How to determine appropriate transaction isolation levels.
  • How to determine when compensating transactions are required.
  • Configuration Management
  • How to determine which information needs to be configurable.
  • How to determine where and how to store configuration information.
  • How to handle sensitive information.
  • How to handle configuration information in a farm/cluster.
  • Coupling and Cohesion
  • How to separate concerns
  • How to structure the application.
  • How to choose an appropriate layering strategy.
  • How to establish boundaries.
  • Data Access
  • How to manage database connections.
  • How to handle exceptions.
  • How to improve performance.
  • How to improve manageability.
  • How to handle blobs.
  • How to page records.
  • How to perform transactions.
  • Exception Management
  • How to handle exceptions.
  • How to log exceptions.
  • Logging and Instrumentation
  • How to determine which information to log.
  • How to make the logging configurable
  • 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 handle concurrency issues within a workflow
  • How to handle task failure within a workflow
  • How to orchestrate processes within a workflow
  •  

    Key Issues
    This table summarizes the key issues within each hot spot:

    Category Key Issues
    Authentication and Authorization
  • Clear text credentials in configuration files
  • Passing clear text credentials over the network
  • Over-privileged accounts
  • Long sessions
  • Mixing personalization with authentication
  • Reliance on a single gatekeeper
  • Failing to lock down system resources against application identities
  • Failing to limit database access to specified stored procedures
  • Inadequate separation of privileges
  • Caching and State
  • Cache misses.
  • Failure to expire items
  • Poor cache design
  • Lack of a cache synchronization mechanism for scaling out.
  • Communication
  • Increased network traffic and latency due to chatty calls between layers.
  • Inappropriate transport protocols and wire formats.
  • Large data volumes over limited bandwidth networks.
  • Composition Tightly coupled modules Duplication of code
    Concurrency and Transactions
  • Blocking calls
  • Nongranular locks
  • Misuing threads
  • Holding onto locks longer than necessary
  • Inappropriate isolation levels
  • Configuration Management
  • Insecure administration interfaces
  • Insecure configuration stores
  • Clear text configuration data
  • Too many administrators
  • Over-privileged process accounts and service accounts
  • Coupling and Cohesion
  • Limited scalability due to server and resource affinity.
  • Mixed presentation and business logic, which limits your options for scaling out your application.
  • Lifetime issues due to tight coupling.
  • Data Access
  • Per user authentication and authorization when not required.
  • Chatty calls to database
  • Intersperse of business logic
  • Exception Management
  • Leaving system / application in unstable state
  • Revealing sensitive information to end users.
  • Using exceptions for logic
  • Not logging enough details about the exception.
  • Logging and Instrumentation
  • Lack of logging and instrumentation
  • Too fine grained logging and instrumentation
  • Not making logging and instrumentation configurable option at runtime
  • Failure to log business critical functionality.
  • User Experience
  • Inefficient or ineffective task support.
  • Poor responsiveness.
  • Disempowered users.
  • Validation
  • Application-only filters for malicious input
  • Non-validated input in the Hypertext Markup Language (HTML) output stream
  • Non-validated input used to generate SQL queries
  • Reliance on client-side validation
  • Use of input file names, URLs, or user names for security decisions
  • Workflow
  • Tight coupling
  • Inflexible processes
  • Race and deadlock issues
  •  

    Key Guidelines
    This table summarizes the key guidelines within each hot spot:

    Category Key Guidelines
    Authentication and Authorization
  • Consider single-sign on requirements.
  • Separate public and restricted areas.
  • Use account lockout policies for end-user accounts.
  • Support password expiration periods.
  • Be able to disable accounts.
  • Do not store passwords in user stores.
  • Require strong passwords.
  • Do not send passwords over the wire in plaintext.
  • Protect authentication cookies.
  • Use multiple gatekeepers.
  • Restrict user access to system-level resources.
  • Consider authorization granularity.
  • Caching and State
  • Avoid caching per-user data.
  • Avoid caching volatile data which is required by the user to be accurate and updated in real time.
  • Cache data that does not change very frequently or is completely static.
  • Do not cache shared expensive resources.
  • Cache transformed data, keeping in mind the data use.
  • 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.
  • 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.
  • Cut call chains with queues and caches as much as possible. Doing so will enhance the scalability and availability of the overall solution.
  • Push out asynchronous boundaries close to the user, service interfaces, and service agents, to isolate your service from external dependencies.
  • If you need to expose functionality as a synchronous operation, evaluate whether you can wrap an internally asynchronous operation as described in the following discussion
  • Composition
  • Avoid using dynamic layouts that are difficult to load and maintain.
  • Be careful with dependencies between components. Use abstraction patterns when possible to avoid issues with maintainability.
  • Consider creating templates with placeholders. For example use the Template View pattern to compose dynamic web pages to ensure reuse and consistency.
  • Consider composing views from reusable modular parts. For example use the Composite View pattern to build a view from modular, atomic component parts.
  • Use well-known design patterns to implement a composite interface containing separate modules or user controls where appropriate.
  • Modules should not directly reference one another or the application that loaded them.
  • Modules should use services to communicate with the application or with other modules.
  • Modules should not be responsible for managing their dependencies.
  • Modules should support being added and removed from the system in a pluggable fashion.
  • Concurrency and Transactions
  • Treat threads as a shared resource.
  • Pool shared or scarce resources.
  • Acquire late, release early.
  • Consider efficient object creation and destruction.
  • Consider resource throttling.
  • Reduce contention by minimizing lock times.
  • Balance between coarse- and fine-grained locks.
  • Choose an appropriate transaction isolation level.
  • Avoid long-running atomic transactions.
  • Configuration Management
  • Protect your administration interfaces.
  • Protect your configuration store.
  • Maintain separate administration privileges.
  • Use least privileged process and service accounts.
  • Coupling and Cohesion
  • Partition application functionality into logical layers.
  • Choose the proper locality for your objects based on your reliability, performance, and scalability needs.
  • Design for loose coupling.
  • Design for high cohesion.
  • Use early binding where possible.
  • Evaluate resource affinity.
  • Data Access
  • If your application uses a single database, use the database-specific data provider.
  • If you need to support multiple databases, you generally need to have an abstraction layer, which helps you transparently connect to the currently configured store.
  • Consider resource throttling.
  • Consider the identities you flow to the database.
  • Separate read-only and transactional requests.
  • Avoid unnecessary data returns.
  • Exception Management
  • Avoid revealing sensitive data to users.
  • Do not use exceptions to control application flow.
  • Use validation code to avoid unnecessary exceptions.
  • Do not catch exceptions that you cannot handle.
  • Be aware that rethrowing is expensive.
  • Preserve as much diagnostic information as possible in your exception handlers.
  • Logging and Instrumentation
  • Instrument your code up front.
  • Make your logging configurable.
  • User Experience
  • Measure effectiveness against scenarios.
  • Improve user responsiveness where possible.
  • Model from effective user design.
  • Validation
  • Validate for length, range, format, and type.
  • Constrain and reject input.
  • Sanitize output.
  • Don’t rely on client-side validation.
  • Workflow
  • Determine management requirements. If a business user needs to manage the workflow, you’ll need a solution that provides an interface that the business user can understand.
  • Determine how exceptions will be handled.
  • With human workflow, you need to consider the un-deterministic nature of humans. In other words, you can’t determine when a task will be completed, or if it will be completed correctly.
  • Use service interfaces to interact with external workflow providers.
  • If supported, use designers and metadata to define the workflow instead of code to define the workflow.
  • How To Provide Feedback
    We're still banging through the frame.  There's some rough spots.  We want to make sure we can map problems, principles, patterns, assets, and technologies to the right hot spots.  We want a prioritized list over a laundry list so we're still deciding what's in and what's out.  We'll add it to CodePlex shortly.  You can either comment here on my blog or wait until the frame is on CodePlex, and then provide comments in the Wiki.

    Additional Resources


    My Related Posts

  • J.D. Meier's Blog

    App Types

    • 6 Comments

    As part of our patterns & practices App Arch Guide 2.0 project, we've created a set of application archetypes ("app types" for short.)   You can see our app archetypes on our Application Types (Archetypes) Index page.  To keep it simple, we focused on a small set of common application types that customers identify with.  Here's the cool part ... for each application type, we're taking a principle-based approach, then showing relevant patterns, p&p solution assets, and Microsoft technologies.  Keep in mind we're still hashing it out.

    Application Types

    • Mobile
    • Rich Client
    • Rich Internet Application
    • Service
    • Web Application

    Mobile
    A mobile application will normally be structured as a multi-layered application consisting of user experience, business and data layers.

    AppTypeMobile

    When developing a mobile application you may choose to develop a thin web-based client or a rich client. If you are building a rich client, the business and data layers are likely to be on the device itself. If you are building a thin client the business and data layers will be on the server.

    See Mobile Application Type (CodePlex)

    Rich Client
    Rich client user interfaces can provide high performance, interactive, and rich user experiences for applications that must operate in stand-alone, connected, occasionally connected, and disconnected scenarios.

    AppTypeRichClientApp

    Windows Forms, WPF, and Office Business Application (OBA) development environments and tools are available that allow developers to quickly and easily build Rich Client applications. While these technologies can be used to create standalone applications, they can also be used to create applications that run on the client machine, but communicate with services exposed by other layers (both logical and physical) that expose operations the client requires. These operations may include data access, information retrieval, searching, sending information to other systems, backup, and related activities.

    See Rich Client Archetype (CodePlex).

    Rich Internet Application (RIA)
    A Rich Internet Application (RIA) runs in the browser in a sandbox.  The benefits of a RIA application include richer user experience, better responsiveness and network efficiency over traditional Web applications.

    AppTypeRIAApp

    See Rich Internet Application Archetype (CodePlex).

    Service
    A service is a public interface that provides access to a unit of functionality. Services literally provide some programmatic ‘service’ to the caller who consumes them.

    AppTypeServicesApp

    Services are loosely coupled and can be combined from within a client or within other services to provide more complex functionality. Services are distributable and can be accessed from a remote machine as well as from the local machine on which they are running. Services are message oriented, meaning that service interfaces are defined by a WSDL file and operations are called using xml-based message schemas that are passed over a transport. Services support a heterogeneous environment by focusing interoperability at the message/interface definition. If components can understand the message and interface definition they can use the service regardless of their base technology.

    See Service Application Archetype (CodePlex).

    Web Application
    The core of a Web application is its server-side logic.  The Web application layer itself can be comprised of many distinct layers.  The typical example is a three-layered architecture, comprised of presentation, business, and data layers.

    AppTypeWebApp

    See Web Application Archetype (CodePlex).

    Template for Application Type Guidance
    Here's the approach we're using to organize the guidance for each archetype:

    • Overview
    • Design considerations
    • Frame of Hot Spots / Categories
    • Category X
    • Category Y
    • Category Z
    • Presentation Layer Considerations
    • Business Layer Considerations
    • Data Layer Considerations
    • Services Layer Considerations
    • Performance Considerations
    • Security Considerations
    • Deployment Considerations
    • Pattern Map
    • Technology Considerations
    • patterns & practices Solution Assets
    • Additional Resources

    You can walk the Web application example to see it in action.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Key Software Trends

    • 7 Comments

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

    Key Notes On Trends

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    My Related Posts

  • J.D. Meier's Blog

    The Story of the Engineering Practices Frame

    • 2 Comments

    I shared the story of our patterns & practices Engineering Practices Frame on Shaping Software.  In a nutshell, the Engineering Practices Frame is a set of categories to organize software development knowledge.  The idea behind the frame is to help collect and share principles, patterns, and practices for life cycle activities and artifacts.  It's meant to play well with SWEBOK, various Microsoft efforts around life cycle practices, and our customers and field in the trenches.  The Engineering Practices Frame is also the foundation for our ALM Frame.

  • 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.

  • Page 1 of 1 (25 items)