J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    How To: Create a “Hello World” WCF Service Using Visual Studio

    • 6 Comments

    Here's a quick step through of using WCF in Visual Studio 2005.  In this case I used a local machine, running Windows 2003, for the service and the client. 

    There's lot of possible paths, and this is just one path through.  I focused on "Hello World" to run through the basic mechanics, but chose a path to touch enough things that might be interesting to explore another day.

    Scenario
    Use Visual Studio 2005 to do a dry run of creating a WCF service hosted in IIS and calling it from a console application on your local development workstation.  (Note that you don't need to host WCF in IIS; for example, you could use a surrogate console application.)

    Preparation
    In my case, I needed the .NET 3.0 components and the WCF extensions for Visual Studio:
    1. .NET 3.0 Runtime Components
    2. WCF and WPF extensions for Visual studio

    Summary of Steps

    • Step 1.  Create the test service
    • Step 2. Add a Hello World Method
    • Step 3.  Test your WCF service
    • Step 4.  Enable meta-data for your WCF Service.
    • Step 5.  Create the test client.
    • Step 6.  Add a Web Services reference to your WCF Service.
    • Step 7.  Add the namespace to your
    • Step 8. Call your WCF service

    Step 1.  Create the test service
    In this step, we'll create a WCF service that uses HTTP bindings, for backward compatibility (non-.NET 3.0 clients)

    1. In Visual Studio, click File -> New Web Site
    2. Select WCF Service
    3. Browse to a directory to store your project: (e.g. D:\Dev\WCF\Test1\Serve )
    4. Enable wsHttpBinding.  To do so, right-click Web.config and click Edit WCF Configuration ... Expand Services > expand MyService -> expand Endpoints.  Click (Empty Name).  Change wsHttpBinding to basicHttpBinding
    5. Create the virtual directory.  In your File Manager, right-click your Server folder (i.e. D:\Dev\WCF\Test3\Server) and click Properties, then Web Sharing, and click Share this folder, then click OK.

    Step 2. Add a Hello World Method
    In Service.cs, you'll add your Hello World method:

    1. Add the HelloWorld operation contract below public interface: [ServiceContract()]
      public interface IMyService
      {
          [OperationContract]
          string MyOperation1(string myValue1);
          [OperationContract]
          string MyOperation2(DataContract1 dataContractValue);
          [OperationContract]
          string HelloWorld();
      }
    2. Add your HelloWorld method below public class MyService : public class MyService : IMyService
      {
          public string MyOperation1(string myValue1)
          {
              return "Hello: " + myValue1;
          }
          public string MyOperation2(DataContract1 dataContractValue)
          {
              return "Hello: " + dataContractValue.FirstName;
          }
          public string HelloWorld()
          {
              return "Hello World";
          }
      }

    Compile and debug any errors.
    Step 3.  Test your WCF service

    1. In IIS Manager, under Default Web Site, right-click expand Server (the virtual directory you just created)
    2. Right-click Service.svc and click Browse

    There's two issues you might hit here:

    1. You don't have ASP.NET installed/enabled.  To fix this, first run aspnet_regiis /i from your .NET installation directory (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727)  Then, allow ASP.NET in your IIS Manager.  To do so, in IIS Manager, expand Web Service Extensions, select ASP.NET v.2.0.50727 and click Allow.
    2. You might see "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service."  To fix this, first enable anonymous access.  In IIS Manager, right click your v-dir (Server), click Properties, click Directory Security, click Edit under Authentication and Access control, click Enable Anonymous Access, then OK your way out of the dialogues.  Next, recycle IIS.  In a command prompt, type IISreset.  If successful, when you browse your Service.svc file from IIS Manager (e.g. http://localhost/service/service.svc). you'll get a message that starts with the following:
      This is a Windows© Communication Foundation service. 
      Metadata publishing for this service is currently disabled.

    Step 4.  Enable meta-data for your WCF Service.

    1. In VSTS, right-click Web.config and click Edit WCF Configuration.  In WCF Configuration, expand Advanced, then expand Service Behaviors, then
      right-click returnFaults and click Add Service Behavior Element Extension.  Select serviceMetadata and click Add
    2. In WCF configuration, select serviceMetadata and change HttpGetEnabled to True.  Close the dialogue and save changes.
    3. Test your service again.  Browse to http://localhost/Server/Service.svc and this time you should see your service (e.g. MyService Service).  You
      will see a message that starts with the following:
      "You have created a service."

    Step 5.  Create the test client.
    In this step, we'll create a quick console app to call the WCF service:

    1. In Visual Studio, click File -> New -> Project
    2. Select Console Application.
    3. Browse to a directory to store your test client:  (e.g. D:\Dev\WCF\Test1\WCFClient)

    Step 6.  Add a Web Services reference to your WCF Service.
    In this step, we'll add a Web Services reference. 

    1. Right-click References      
    2. Click Add Web Reference ...
    3. In the Add Web Reference dialogue, add the path to your WCF Service (http://localhost/Server/Service.svc)
    4. Click Add Reference to close the dialogue.  You should then see your Web Service reference show up under Web References.

    Step 7.  Add the namespace to your   

    1. Browse to your Reference.cs file.  You'll find the file below Reference.map under your Web service reference.  You might need to click the Show All Files button on the Solution Explorer so you can see the files under your Web service reference. 
    2. Find the namespace.  You'll see a line similar to the following:
              namespace ConsoleApplication1.localhost
    3. Add the using statement to your Program.cs file.
                      using ConsoleApplication1.localhost;

    Step 8. Call your WCF service
    In your test client, call your WCF service:
            static void Main(string[] args)
            {
                MyService service = new MyService();
                string foo;
                foo = service.HelloWorld();
                Console.WriteLine(foo);
            }
    When you compile and run your console application, you should see the following:
    Hello World
    Press any key to continue . . .

    Additional Resources

    Hopefully this step through helps you quickly see some of the bits and pieces you can play with.

  • J.D. Meier's Blog

    40 Hour Work Week at Microsoft

    • 4 Comments

    "Eight hours work, eight hours sleep, eight hours play, make just and healthy day." - King Alfred the Great

    One of the most important lessons at Microsoft was learning the value of a 40 hour work week.  I’ve been on time, on budget for 10 years on projects ranging from grass-roots or “best efforts” to $ million+ investments.  In my first few years, I was on time, on budget through heroic effort.  That’s not sustainable and folks don’t want to sign up for that more than once.  Luckily, I learned early on how to drive more effective results by fixing time and flexing scope, while flowing value, and optimizing team health.  I also learned the value of figuring out effective product-lines, managing portfolios of investments, finding the best “Hot Spots” on heat maps of customer pain and opportunity, and mastering the art of the WBS (work breakdown structures) and cuttable scope.

    For some people that have experienced effective 40 hour work weeks on a regular basis, this will be “no-duh.” For those that haven’t, this may be unfathomable, so I’ll share what I’ve learned so at least it can give you food for thought and potentially help give you a mental model of what success can look like.  I originally slanted this for individuals and 40 hour work weeks, but I realized it’s more effective if more team leaders drive 40 hour work weeks so that everybody wins.

    Why a 40 Hour Work Week
    It’s not that I just want happier, healthier, more effective colleagues.  I want a more effective Microsoft.

    In my experience, a 40 hour work week is a benchmark of the most effective teams.  They have work-life balance.  They have buffer to respond to opportunity and to deal with crunches.  They have processes in place, they invest in their learning and growth, and they move up the stack instead of always solving the basics.  Instead of perpetual fire-fighting, they are more deliberate about planning and strategy and they anticipate their customers and the market (through empathy and staying connected to customers.)  They learn and respond and can turn on a dime.  They have a dashboard, they know the score, and they can change their approach.

    There’s another reason that cuts right to the chase.  If budget cuts will break you, then the first way to build a firm foundation and execution machine is to master the 40 hour work week.  It’s a forcing function that fixes a lot of underlying execution issues that you just cannot see if your organization throws time at problems.  If you can’t see it, you can’t fix it.  When you bound it by time, you can start testing more effective ways to produce results.  To make this actionable, make it an initiative.

    60-80 Hour Week of Ineffectiveness
    Here are some of the attributes of teams that lead and drive 60-80 hour weeks of ineffectiveness and inefficiency:

    • Throwing time at things (this shows up as longer days or weekends and adding more and more meetings.)
    • Nothing is a priority because everything is a priority (this is a sign of lacking metrics people believe in or a relevant scoreboard or dashboard of results or a lack of setting expectations or a lack of clarity on the end in mind or inability to flow incremental value.)
    • Working faster and harder to make up for bad planning.
    • Work on the wrong things faster or longer.
    • Lots of meetings because there’s more time to throw at them.
    • Lack of priorities because there is no forcing function like time.
    • Lack of focus because of a lack of priorities and throwing time at problems.
    • Bad estimation because it’s spread out over too much work or too much time or too ambitious.
    • Bad resource planning because of bad estimates and lack of clarity or feedback loops on results.
    • Scope drives everything, so scope creep is a way of life.
    • Ship cycles are spread so far apart that nobody wants to version or push to the next version so everything has to fit this time around through death marches and endless fitting square pegs into round holes.

    Ultimately, it’s a lost of waste on multiple levels.  Mostly, it’s a waste of human potential.

    40 Hour Week of Effectiveness
    Here are some of the attributes of teams that lead and drive 40 hour work weeks of effectiveness:

    • Get smart people on a cadence.  If there is a regular rhythm of results or a regular ship cycle or a regular time when the trains leave the station, you can always improve everything else.  The worst mistake is having timelines of jello.  When you have a cadence, people can version things, they can tune and improve processes, they can scope and chunk things down, they can ruthlessly prioritize, etc.
    • The team is fully engaged in the work they do.  They co-create the future they buy in to the journey and path, and believe in the end-in-mind.  They give their best where they have their best to give.
    • Ruthlessly prioritize value.  It’s not “how much can we do” … it’s “what’s the next best thing to do?”  This also means following the 80/20 rule and focusing on the 20% of the work that gets you 80% of the value.
    • Learn your capacity and throughput.  Throughput is simply the amount of work you can do in a given time period.
    • Have the right people in the right roles.  A sign of a strong team is they *feel* they can run towards the problem versus want to run away.  The two simplest way to kill an otherwise effective team are to have somebody out of position (e.g. catcher playing third base), or missing a key player (e.g. no pitcher.)
    • Spend more time in strengths.  Strengths are NOT what you are simply good at.  Strengths are your natural thinking, feeling, and doing patterns.  This is going with the flow or going with the grain versus against the grain.  If you are always fighting your natural patterns, then you aren’t leveraging your strengths or making the most of what you’ve got.  Instead, you are creating a liability.  This often happens by having people out of position or lack of the right resources.  By spending more time in your strengths, you amplify your impact, you renew your energy, and you grow faster in your strengths than you possibly can in your weaknesses.
    • Spend less time in weaknesses.    This is the Hedgehog Concept in action.   Stop doing what you’re not good at.  Do this by spending more time in what you are great at.  You can shave and slough off the time you spent in weaknesses by deliberately carving out more time to spend in your strengths.  Again, this will help keep your energy strong, which is the key to great results in less time.  Keep in mind that if you have serious liabilities, then you need to reduce them, but you don’t get great by improving your weaknesses, you get great by growing your strengths.
    • Push the bottleneck around.  Every team or organization has something that gates them.  It can be a lack of money or the right ideas or the right people.  In my experience, I often see heavy handed processes that made teams ineffective.  I also see the lack of the right vital few people (like playing baseball without a pitcher or playing hockey without a goalie.)  I also see a lack of the right investments, which is usually a sign of either a lack of clarity on the end-in-mind or a lack of understanding about the nature of the work (such as what it takes, how long it takes, who can do it, how to make it more efficient or effective, etc.)  There is always a bottleneck and if you can put your finger on the most important one, and you eliminate it or change the bottleneck, you can exponentially amplify your results.  My favorite lens for looking for productivity bottlenecks is the Theory of Constraints.

    While these insights and lessons might seem easy, intuitive, or simple, they are actually hard-earned and they are directly from the school of hard knocks.  It took multiple managers, testing with multiple teams over multiple years, and a lot of trial and error to figure out what actually works.

    Cornerstone Concepts for More Effective and Efficient Weeks
    There are some fundamental concepts and shifts to understanding why and how a 40 hour work week is more effective than a 60 or 80 hour work week.   You need a few concepts under your belt to help guide you through change:

    • Energy is the key to productivity, not time.   Give me four Power Hours over 40 hours of suck-the-life-force-slowly-out-of-me any day.  A Power Hour is where you are in the zone or in your flow and your energy is strong, while your creative juices are flowing or you are your most resourceful and solve problems with ease.    You get more Power Hours by people working in their strengths, playing to their passions, getting sufficient rest, enjoying work-life balance, and feeling valued for the work they do.
    • It's value delivered, not time spent.  Spending more time does not mean creating more value.  If you’re metric is “butts in seats” or “*** in chair,” you’re missing the point.   You want to measure value, and value is not a linear line of widgets you just crank out in the knowledge arena.
    • Shifting from Industrial Age thinking to the Knowledge Age.  In the Industrial Age, spending more time, meant producing more widgets.  Not so in the Knowledge Age.  Now it's about coming up with new ideas, new ways, changing the game, and responding to demand in more creative ways.  Knowledge and ideas are our main source of economic growth.  It's about turning knowledge from ideas in the mind, into valuable things and making things happen, through networks and systems of collective intelligence.
    • Intrinsic Value vs. Market Value.  For the sake of argument, let’s say a can of soda has an intrinsic value of $1.00.  It should never be worth more than that, at the intrinsic level.  Put that same can of soda in the desert, and now it’s market value is $50 or $100.   This gap between intrinsic value and market value is why bubbles burst or why customers that were paying $50 or $100 over here, can suddenly pay $1 over there.   Your opportunity for innovating in both your processes and your products comes from knowing the intrinsic value of things.  At some point, you’ve found the bottleneck or the glass-ceiling.  The key is to make sure your costs are close to intrinsic value and that if your market value is over-inflated to know that somebody, somewhere around the world can beat you on cost if you’re playing the cost game (A pattern I keep seeing is cost is losing, quality is winning for the long-haul – quality and brand are hard to copy.)
    • Sustainable pace.   Effectiveness is not about random acts of heroic effort or regular fire righting or reacting to perpetual surprises that could have been anticipated.  Effectiveness is also not about reacting to bad planning or over-estimating or unrealistic expectations.  A sustainable pace comes from setting a bar, in this case a 40 Hour Work Week, and designing for it.  It means biting off what you can chew within that chunk of time.  It means ruthless prioritization and focus by focusing on the smartest things that have the most value and letting the rest go.  It means having clarity on the end-in-mind, knowing the path or waypoints, and correcting course as you go.
    • Smart BI (Business Intelligence).   In an online, connected world, there is no reason to be flying blind.  You can guess at what works, or you can instrument, test, and measure.  This is the key to Amazon’s online success.  They can learn and respond.  By using BI effectively, you can figure out exactly what customers want, how much they want it, how they are looking for it, and where they are finding it.  Don’t “push” products.  Find the “pull.”  You can find the appetite or the demand to help drive and shape your supply.
    • Prosumer Model.    The prosumer model is where the producer joins forces with the consumer or user of their product.  Involve your customers earlier in the cycle and co-create the future with them.    You can’t miss.  However, don’t let the tail wag the dog.  For example, if Henry Ford asked customers what they wanted, they would say a “faster horse.”  Use customers to find their problems and what they would pay for or what they value.
    • It’s a Darwin world.   Along the lines of the book, Good to Great, you have to compete at what you can be the best in the world at.  In the physical world, you can compete on location.  On the Web, you really want to be number one for your niche or micro-niche.  Customers have slots in their mind, and you want to be pole position for whatever your slot in their mind is (positioning isn’t just position in the market, it’s position in the mind.)  If you compete at what you can be the best in the world at, you improve your sustainable pace and your competitive advantage.

    My Story
    One of my toughest lessons to learn at Microsoft was the value of a forty hour work week.  I'm known for being a workhorse.  16-20 hour days, 7 days a week was just a way of life for me.  Long ago, I heard the saying you'll have plenty of time to rest when you're dead and it stayed with me ever since.

    To make it worse, when I joined Microsoft, I was surrounded by passionate people who also worked well beyond a forty hour work week.  I was in the zone.  Not just that, I was spending my time in my passion, so I never burned out.  Throwing hours at problems was no sweat and I liked the pace.

    My first taste that this was a problem was when my first manager sat me down and said that my perpetual over-time was a problem.  He said I was throwing off the head count.  I was doing the work of multiple engineers.  It made it hard for him to argue for heads if the work was getting done, and he worried that I would burn out.  Luckily, I never burned out.  It turns out the primary ways you burn out are by trying to solve the same problem over and over like a broken record with no results, or by spending time in things that drain you.  The simplest cure for burnout is spending more time in your passions or moving to new problems or changing your container.

    My second taste that this was a problem was when I joined patterns & practices.  After my first few projects, my manager told me I needed to find a way to work 40 hours and produce the same or better results.  Additionally, I had to get more effective results from the rest of the larger team.  In other words, I wasn’t setting a good example, I set an impossible bar, and I had to make the most of the team (Oh, and did I happen to mention that this larger team was always a distributed team around the world, from UK to Argentina to India and the US?)  The good news is, the story has a happy ending …

    To bottom line it, by setting a constraint around the 40 hour mark, it dramatically improved team processes, improved clarity on impact, and it helped flow value versus waiting for big bang.  This also had an amazing set of by-products, including achieving work-life balance for all team members, helping people spend more time in their passion and strengths, reducing downstream risk and surprises, and keeping the energy strong across the team in a more durable way.  It also helped us improve our daily, weekly, and monthly rhythms of results while improving our team practices and procedures.  We basically moved up the effectiveness stack and it got faster each time we had to build a new team.

    The basic approach I used is what I call Monday Vision, Daily Outcomes, and Friday Reflection.   I did “show and tells” on Thursdays as a forcing function to drive results but to also give folks on the team a chance to show off their work and get feedback earlier versus later.

    Call to Action
    Make a 40 Hour Work Week an initiative, for yourself, for your team, or for your organization.  Start small.  Lead by example.  Start with yourself, then help other people.  Focus on finding more effective ways to do things, focusing on the vital few things that matter the most, playing to your strengths, and improving your energy.  Know what counts and be able to put your finger on it.

    You can explore the system in Getting Results the Agile Way.   The Scenarios and Solutions for Getting Results and the Guidelines for Getting Results are fast tours of the landscape and rich with strategies and tactics for changing your game.

  • J.D. Meier's Blog

    ASP.NET Code Samples Collection

    • 14 Comments

    image

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

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

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

    image

     

    ASP.NET Code Samples Collection

    Category

    Items

    Sample Applications

    ASP.NET MVC

    AJAX / jQuery

    All-in-One Code Framework

    Code Gallery

    Microsoft Support

    Authentication

    Code Gallery

    Customer Support

    Authorization

    Code Gallery

    CSS 2

    Data Access

    All-in-One Code Framework

    Code Gallery

    Exception Management

    Code Gallery

    Microsoft Support

    JavaScript / JSON

    Code Gallery

    Logging and Instrumentation

    patterns & practices

    MVC

    Code Gallery

    Navigation

    Codeplex

    Request Processing

    ASP.NET Developer Center (www.ASP.NET)

    State / Session Management

    Code Gallery

    Validation

    Code Gallery

    Visual Studio and ASP.NET Development

    Code Gallery

    Microsoft Support

     

    My Related Posts

  • J.D. Meier's Blog

    Application Architecture Visios Now Available

    • 12 Comments

    We added our Application Architecture Diagrams (Visios) to our Application Architecture Knowledge Base (KB) on CodePlex.  You can download the Visios and customize for your own presentations or documents.

    Application Architecture Figures
    Here’s the figures available:

    • Architecture Meta Frame (AMF)
    • User, Business, and System Perspectives
    • Agile Architecture Method
    • Layered Architecture
    • Layered Architecture with Services Layer
    • Layered Architecture with Multi-Clients / Multi-Channel
    • Web Application Archetype
    • Mobile Application Archetype
    • Rich Internet Application (RIA) Archetype
    • Rich Client Archetype
    • Service Archetype

    Architecture Meta Frame (AMF)

    Architecture Meta Frame

    User, Business, System Perspectives

    User Business System

    Agile Architecture Method

    Agile Architecture Method

    Layered Architecture

    Layered Architecture

    Layered Architecture with Services Layer

    Layered Architecture with Services Layer

    Layered Architecture with Multi-Client / Multi-Channel

    Layered Architecture with Multi-Client 

    Web Application Archetype

    Web Application Archetype

    Mobile Application Archetype

    Mobile Application Archetype

    Rich Internet Application (RIA) Archetype

    RIA Application Archetype

    Rich Client Archetype

    Rich Client App Archetype

    Service Archetype

    Service Archetype

  • 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

    How To Use Time Boxing for Getting Results

    • 7 Comments

    Time boxing is a way to chunk up time and get results.  If you continously miss windows of opportunity or spend all of your time in one area of your life at the expense of others, time boxing can be one of your best tools.   A time box is simply a limited set of time to accomplish a result.  Think of it as how much work can you get done in a given block of time.  I use it to organize my day, drive project results, make incremental progress on problems and spend time on the right buckets in my life.

    Why Use Time Boxing
    Using time as a constraint and forcing function for results is extremely effective:

    • Avoid missing windows of opportunity.  Time's a limited resource.  If you don't treat it this way, you end up blowing project schedules, missing windows of opportunity, or doing too little, too late.
    • Spread your results across key areas.   If you spend all of your time in one area of your life at the expense of another, you can use time boxes to allocate time for important areas (such as career, mind, body, social, spiritual ... etc.)
    • Prioritize more effectively.  If you know you only have three months for that project, you can be smarter about what you bite off that you can actually finish.
    • Chunk up a problem.  Use time boxes to slice a problem down to size.  This works well if you have a daunting problem that seems too big to take on.  Timeboxes are also a more realistic way to deal with problems that spread over time.  If you can't solve a problem in a single session, then figure out the right-size time chunks to throw at the problem.  How do you eat an Elephant?  One timebox at at time ;)
    • Deliver incremental results.   You can use a time box to show progressive results.  For example, rather than all-or-nothing thinking, use time boxing to make incremental progress on a problem. 
    • Increase focus.  Giving yourself dedicated time boxes to focus on a problem help you avoid task switching, and help you stay engaged on the problem.  If you find yourself wandering too much, then chunk your timebox down even further. See
    • Increase motivation.  Make a game of it.  For example, how many sit ups can you do in 60 seconds?  Between splitting problems down to size, staying engaged on the problem and making a game of it, time boxing is a sure-fire way to build momentum and results.
    • Improve your effectiveness and efficiency.  use time boxing to tune your results.  Using a time box can help you identify areas to improve as well as refine your approach.  If you're not getting enough done within your timebox, experiment with different approaches, while you tune your effectiveness and efficiency.
    • Version your results.  It can be very liberating if you think in terms of revisiting a problem over a period of time, versus trying to get it all right up front.
    • Defeat analysis paralysis.  Analysis paralysis can be the worst enemy of results.  Use a time box to switch gears from think mode to execution.

    Summary of Steps
    Here's some prescriptive guidance for creating and using time boxes effectively:

    • Step 1.  Identify candidate areas for time boxing.
    • Step 2.  Identify your objectives.
    • Step 3.  Identify the appropriate time box. 
    • Step 4.  Execute results within your time box.
    • Step 5.  Evaluate and adapt. 

    Step 1. Identify candidate areas for time boxing.
    Identify candidates for time boxing.  This could be anything from work projects to personal projects.  Personally, I've found it the most effective to start with something small, such as starting a new exercise program.  I've also found it effective to use it to tackle my worst time bandits (any area where I lose a bunch of time, with either little ROI or at the expense of another area.)

    Step 2.  Identify your objectives.
    In this step, ask yourself what you need to accomplish with time boxing.  Examples include:

    • Meet a deadline.
    • Show incremental results.
    • Make incremental progress on a tough problem.
    • Build momentum.

    Step 3.  Identify the appropriate time box.
    In this step, figure out what a right-sized time box would be.  For example, you might have a project due in three weeks.  Within that three week time box, you might decide that if you allocate 2 hours a day, you'll produce effective results.

    The right-sized time box largely depends on what you determined in Step 1.  You might need to grow or shrink your time box depending on whether you're trying to build momentum, show results or just make progress on a problem.
     
    Step 4.  Execute results within your time box.
    Execute within your timebox and stop when you run out of time.  This can be tough at first because you might be on a roll.  This can be really tough if you are used to doing things until they are done.  What you're learning at this step is how to stay completely focused, how to treat time as a limited resource, and how to tune your results.  You're also learning how to make time boxes effective for you. 

    Start with your time box as a baseline so you can evaluate your results.  The worst mistake is to give yourself an hour for results, spend two hours, and then say what a great job you did in your one hour timebox.  Instead, do the hour, then figure out whether you need longer time boxes or if your approach needs to change.
     
    Step 5.  Evaluate and adapt.
    If it's not working, change your approach.   Using time boxing is one of the most effective ways to experiment with different techniques to find the most efficient.

    Examples of Effective Timeboxing
    Here's some examples of putting timeboxes into practice:

    • Software development.  Because our teams within patterns & practices do iterative and incremental development, we make heavy use of time boxing.  For example, within a two-week iteration, how much value can we deliver?
    • Feed reading.  Give yourself a 10 minute window and see how many useful feeds you can read.  See how you tune your feed reading skills, including choice of reader, how you prioritize, and how you choose posts to read, as well as what links to follow.  You might choose to factor your exploratory, pleasure feed reading from your personal and professional development feed reading.
    • Email.  Use time to help you outsmart your inbox.  For example, if you allocate 30 minutes for your email, but you're falling behind, instead of throwing more time at the problem, experiment with different approaches.
    • Time bandits.  Set limits on how much time you'll throw at your worst time sinks.  For example, do you spend too much time in meetings?  Do you spend too much time stuck in analysis paralysis and not enough time in execution?  Tackle your time-bandits with some hard limits.    

    Additional Resources

    My Related Posts

  • 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

    7 Habits of Highly Effective Program Managers

    • 6 Comments

    What does it take to be an effective Program Manager at Microsoft?  I'm responding to some requests for my take on what it takes to be an effective PM.  I figured I could use a familiar 7 habits approach to help frame out a start. 

    To pick a set of habits, I started with a set of reference examples.  I used the most effective and ineffective PMs that I've seen over time.  I considered their track record, their ability to influence, and their leadership skills.  Most importantly I looked at their ability to ship and make the right impact for customers.  Next, I looked for the underlying patterns (I'm a principles, practices and patterns guy).  I used the ineffective PMs to think of the anti-patterns and the practices of what not to do.  This contrast helped me clarify the distinctions between effective and ineffective.

    Here's what I found to be the 7 habits of highly effective program managers:

    • Habit 1, Frame problems and solutions.
    • Habit 2, Sell visions.
    • Habit 3, Deliver incremental value.  
    • Habit 4, Manage communication.
    • Habit 5, Connect with customers.
    • Habit 6, Execute. 
    • Habit 7, Leverage the system.

    Habit 1, Frame problems and solutions.  Frames are the things mental models, metaphors, and conceptual frameworks are made of.  Simply put, they're frames of reference.  Effective PMs create useful ways of looking at the problems and solutions.  They create shared frames of reference that help narrow and focus, while keeping perspective.  Frames help chunk up the problem or the solution.  Frames also help share information quickly as well as avoid information overflow.  The secret here is that frames provide contextual reference.  Without context, it's hard to evaluate problems or solutions.    

    Habit 2, Sell visions.  The most effective PMs dream up great ideas and they sell them.  They sell them in the hall, they sell them to co-workers, they sell them up the chain.  They have an elevator pitch that resonates.  They can paint a vivid picture of how the world will be different.  Sometimes a PM has an idea that people aren't ready for.  Sometimes a PM has an idea they just aren't selling right.  Sometimes a PM has an idea that ... well ... just isn't ready for market or planet Earth.  Selling visions involves both thought leadership and people leadership.  I think the secret here is effective PMs sell visions by answering "what's in it for you" for stakeholders and customers.

    Habit 3, Deliver incremental value.   How do effective PMs go from zero to Rome?   While the big bang can make a lot of impact, the problem is the longer they delay, the more project risk adds up over time -- visions change, people change, markets change, stakeholders change, perceptions change … etc.   Anything that isn't built in a day needs a serious chunking strategy.  The sooner they can start delivering value, the sooner they can get feedback and adapt and change.  Also, they have better chances of hitting key windows of opportunity. 

    The most effective PMs can chunk their solutions.  This is non-trivial, particularly in software.  It means knowing what the minimum shippable chunk is.  It means right-sizing their chunks so that each one delivers value for the right customers.  It means unbundling dependencies to remove unnecessary project risks.

    I think the secret of effective PMs here is thinking in terms of value rather than quantity, as well as knowing dependencies.  What can they cut and truly gain time and resources without risking quality?  Here's a true test ... if their 12 month project were cut into 6 ... or their 6 month project cut into 3 ... what would they cut and what would they deliver?  If the success of their project depends entirely on shipping everything in their plan for the full project cycle, that's a recipe for failure. 

    Habit 4, Manage communication.  This is a crucial skill since this means managing perceptions, managing expectations,  brokering knowledge, and making sure the right people are involved.   This is why some PMs fail where others succeed.  The most effective PMs make sure the right people are involved on the right problems.  They also setup forums and channels for communication.  I think there are a few secrets here.  The first secret is, they tailor the language for their audiences.  For example, for stakeholders, they know their relevant currency (time? budget? resources? business value?).  For engineers, maybe it's how does it work or why.  For customers it might be features, scenarios or value.  The second secret is, they use a variety of communication tools.  Effective PMs make use of a range of SharePoint portals, Wikis, Mind Maps, whiteboards, blogs, forums, etc.  The third secret is, they use the right mediums for the message.  Effective PMs consider whether their message is best delivered in slides, mail, meeting, phone, etc.  For example, slideware is often more effective than a long email. 

    Habit 5, Connect with customers.   This is where the rubber meets the road.   The most effective PMs have strong customer connections.  Not only do they work with customer directly, but they have a useful representation across relevant segments.  The mistakes I usually see here include the following: no customers, pretend customers, one customer size fits all, or assuming their internal scenario can be generalized to typical customer scenarios.  The secret here is that it is not the number of customers, rather it is scenario representation and trusted sounding boards with key customers.

    Habit 6, Execute.  Execution makes life easier at Microsoft.  The most effective PMs have great work breakdown structures and the right resources working on the right jobs.  I know this sounds overly simple, but there's a secret here.   I've seen work breakdown structures that are focused on activities versus outcomes.  If a PM does not have a good work breakdown structure, then that means they don't know the work to be done.  If they don't know the work to be done, then their estimates are off.  If they don't have a good work breakdown structure, then it's also easy to have the wrong people doing the wrong jobs.

    Habit 7, Leverage the system.  Effective PMs know the system they are operating in.  For example, they know their product cycle, software development life cycle, key milestones, and key events.  They also know who or what influences who.  Basically, they know how the system works.  While they could paddle down the river without a map, this map helps them anticipate the obstacles and opportunities.  The secret here is that experience alone doesn't create this map.  Anybody can start making their own map by asking questions about the system they're working in.

    While this list of habits above is not a comprehensive list, I thought it would be a good start.  I'd actually like to hear from you what you think are the habits of the most effective PMs.

  • J.D. Meier's Blog

    Structuring Projects for Team Foundation Server

    • 14 Comments

    I've seen a few customers asking how to structure projects for Team Foundation Server.  I don't blame them.  Finding a structure that works well for you can be tricky, particularly if you don't have the benefit of hind-sight or a bunch of reference examples to draw from.

    My team spent some time this past week evaluating various approaches and lessons learned from various projects  We boiled it down to something that seems to be working well, and distills what's worked for some teams.  With the caveat that we're still evaluating, here's what we learned ...

    Solution
    Local File System

    C:\MyApp
    	\MyApp.sln
    	\Source
    		\MyAppWeb
    		\ClassLibrary1
    


    Source Control (Team Foundation Server)

    /Main
    	/Build
    	/Docs
    	/Source
    		/MyApp
    			MyApp.sln
    			/Source
    				/MyAppWeb
    				/ClassLibrary1
    			/UnitTests
    				/MyAppWebTests
    				/ClassLibrary1Tests
    	/Tests
    


    Key points
    Here's a few highlights about this approach:

    • On the client side, we explicitly creat our solution file up front instead of rely on defaults
    • The project folder containts one master solution. 
    • The project has source and unit tests.  Loading the solution for the project, loads the source and unit tests
    • The Main folder in TFS holds the project assets (Build, Docs, Source, Tests).  Using Main lets us create other folders for potential branches (Development, Production, Maintenance ... etc.)

    Repro Steps
    Here's a brief walkthrough to test using a file-based Web:

    1. Create a blank solution in VSTS
    2. Create a source folder on the file system (C:\MyApp\Source)
    3. Add new Web project (C:\MyApp\Source\MyAppWeb)
    4. Add new Class Library (C:\MyApp\Source\ClassLibrary1)


    Verify your folder structure on your File System:

    C:\MyApp
    	\MyApp.sln
    	\Source
    		\MyAppWeb
    		\ClassLibrary1
    


    Adding to TFS

    1. Add your solution to source control
    2. Create a Main folder
    3. Create a Source folder beneath Main

    Verify your folder structure in Source Control Explorer

    /Main
    	/Source
    		/MyApp
    			/MyApp.sln
    			/Source
    				/MyAppWeb
    				/ClassLibrary1
    

    More Information
    You should know that while I talked through the single solution scenario, there are additional patterns.  Here's the key patterns we see:

    1. Single solution
    2. Partitioned single solution
    3. Multi-solution

    You can find more on these patterns at Team Development with Visual Studio .NET and Visual SourceSafe.  You should also know that we have a few How Tos on structuring your projects coming your way.  We'll post them to our VSTS Guidance Project.

    Share Your Story
    If you've got lessons learned the hard way or practices to share, I'd like to hear them.   Now's a great time to share since we're actively building guidance.  Either comment here or write a post and leave a link. 

  • J.D. Meier's Blog

    Ward and the Wiki Way

    • 1 Comments

    When Ward Cunningham was on our team, I learned a lot about building Wikis.  He walked me through my first Wiki page.  He probably didn't expect that 4 days later, I'd have more than 500 Wiki pages (he added a counter to my wiki!) 

    Ward told me Wiki Wiki was Hawaiin for fast, and he wanted to simplify publishing (the writeable web). This explained away my initial complaints of formatting and features, and I adopted the mindset of shapable content you can evolve over time.  I thought of Wikis as notepad for the Web.

    Ward and I had a lot of insightful conversations around various Wiki issues: one Wiki vs. many, choosing namespaces, choosing names, collaboration ... etc.  The most important lesson for me was to think in terms of great pages.  This meant, choosing better page names and make pages that matter.  How to eat an elephant? ... one bite at a time.  How to build a useful Wiki? ... one page at a time.

  • J.D. Meier's Blog

    Trends for 2010

    • 18 Comments

    “The best way to predict the future is to create it.” – Peter Drucker

    This is my summary of key trends to watch for 2010.  Putting it together is a time-consuming exercise, but it’s one of the most important things I do for the year.  It helps me see the bigger map.  With the bigger map, I have a simpler way to understand what’s going on, anticipate what to expect, respond more effectively, and most importantly – make better bets on where to spend my time.

    Don’t read this as a definitive list.  Draw from it to help you create your own lens to make sense of the landscape and find your path forward.  It’s long, I tried to keep it as scannable as possible.  I didn’t want to cut it short for the sake of simplicity.  Instead, I wanted to provide a solid map with sources you can draw from as you plan your road ahead.

    Key Sources
    I primarily draw from my own experience working with customers, and paying attention to what they’re paying attention to,  as well as paying attention to my mentors and smarties across the company, and whoever they tell me to pay attention to.  I also draw from the following:

    • Jim Carroll – Jim helps me see the trends across industries and look to patterns.  He’s also great at identifying where the growth and opportunities are, and more importantly how to frame the landscape in a way that makes it actionable instead of analysis paralysis.
    • Trend Hunter – It’s effectively “crowd-sources insight” and it’s a great source for consumer trends.  I’m a big believer that consumer trends pave the path for Enterprise trends.  By watching consumer trends, I learn what to expect.  I then watch how it shows up as I work with my customers.  This pattern serves me well.
    • 10 Web Trends to Watch in 2010” by Pete Cashmore – I liked the simplicity of it and the fact that it resonated with other sources.
    • Economy + Internet Trends by Morgan Stanley – This is a very nice report.  While it reinforces the “jobless economic recover,” it does show IT sector growth, and calls out key tech trends.
    • 8 Big Trends - It’s a free e-book by Jim Carroll and I think the insights are trends that continue and are highly relevant for today’s landscape.
    • Key Software Trends – It’s my summary post of trends across application, infrastructure, performance, and software development that I saw while working on the patterns & practices Application Architecture Guide 2.0 book.
    • The Enterprise of the Future – This amazing compilation by IBM is based on insights and wisdom from interviews of more than 1,000 CEO’s.  I think the key trends from here still hold true, and I like that they boiled it down into 5 key attributes: Hungry for Change, Innovative Beyond Customer Imagination, Globally Integrated, Disruptive by Nature, and Genuine, Not Just Generous.

    Aside from these, I also scoured the Web and scanned bloggers, industry luminaries, and any relevant and significant insight I could find.

    The Short List – 5 Keys to the Future
    Before the longer list, I want to shin the light on 5 key things:

    1. Agility.  Agility means the ability to respond to change.  This is crucial for both personal survival as well as surviving and thriving in a business landscape.
    2. Business intelligence.  Data-driven decisions win over guesswork.  It’s tough, especially when statistics lie and we want to trust our instincts over our indicators.  Start by asking, how do the great businesses drive their great decisions?  Between information markets and crowd sourced intelligence and social networking, the real issue is how you leverage the data and turn it into intelligent decisions and smart feedback loops, and how you learn and respond.
    3. Cloud and virtualization.   This is a key growth spot.  How else do you keep up in a rapidly changing world and deliver services and disruptors and bring new game changers to market faster than ever before?  It’s the cloud.  It marks the commodization of IT and computing.
    4. User Experiences.    Great user experiences drive adoption and make things stick.  This is a great area for innovation, patterns, and practices.  When you think about the possibilities of rich media, touch, speech, location-aware services, and “you-as-the-remote control” (think Wii), the possibilities for amazing and immersive experiences are endless.  More importantly, we can finally start showing how software improves productivity, effectiveness, efficiency, and fun.  It’s gamer + education + business + life.
    5. Mobile.  This is another growth spot – mobile Internet growth.  It’s emerging as a powerful platform and ecosystems that bring the power of software to everyday scenarios, anywhere and everywhere.

    Key Trends for 2010
    Here is my summary of key trends for 2010:

    • 3 screens and a cloud.  Rather than get lost in device explosion, think in terms of a little screen, like a phone, a mid-sized screen, like a laptop or net book or PC, and a bigger screen, like a TV or multimedia projection, and a cloud that serves them all.  See Three Screens and a Cloud by Steve Clayton.
    • Agile Process.    Cycles of change are faster.  How do you keep up?  By adopting agile processes, such as Scrum, XP, and Lean.
    • Apps move up the stack.   As the market matures, things move up the stack.  An example would be the growth of SharePoint as a rapid application platform.  This pattern should accelerate along with cloud adoption.
    • Business intelligence.  How do you make your best decisions?  You test them and you use real data in real time.  That’s how Amazon drives an effective online business.  They don’t depend on a smart user experience person to make things pretty.  They do A/B testing to experiment and test which online experience produces the best results.
    • Cloud Computing and Virtualization.   If you want to stay relevant, you have to be thinking about your cloud and virtualization story.  The opportunities here are amazing from the one-man band code slinger who spins up a Web farm for their app that changes the world to businesses that expose new capabilities to the World and help build the programmable Web.  It’s also a way to simplify computing and move up the stack.
    • Competitive advantage.   Darwinism is brutal in a global marketplace.  Sink or swim.  How do you find your competitive advantage in today’s world.  According to Jim Carroll, the four key drivers of completive advantage in today’s landscape are: Velocity, Agility, Complexity, and Flexibility.
    • "Consumerization" of IT.  A while back, Gartner said Consumerization Will Be Most Significant Trend Affecting IT During Next 10 Years ... I think we see that accelerating.
    • Global distributed development.  Competing in a global market means finding and using the best resources at the best price, anywhere in the world.
    • Jobless Economic Recovery.   This sucks.  It really does.  The upside is that businesses are getting leaner and more effective.  The downside is it’s a sign that we’re not innovating or creating enough growth, and our model for the world isn’t working.  The opportunity here is, software engineers can change the world (remember that Bill Gates guy?)  The world needs a new model.
    • Skills-for-Hire Economy.   Specialization, market maturity and rapid cycles of change drive a demand for key skills.  The key is to balance “generalist” skills in business and technology, along with specialized skills that the market values.
    • Location based services.   Talk about relevancy in action.  It’s all about specialization + location.  Location, location, location takes on new meaning and relevancy.  For example, in Where’s the Growth?, Jim Carroll identifies “Consider the concept of a “location-intelligence professional.” Today, this involves someone working within the insurance industry, learning how to link the extensive data-sets of geographic oriented information – think Google Maps – with existing insurance underwriting information, and with other statistical databases.”
    • Micropayments and virtual currencies.  Second Life really set the trend here a while back, but it’s becoming more important in today’s world.  This paves the way for real money for micro-transactions.  It also creates a model for reputation based systems, which is important in a reputation-based economy.
    • Mobile internet.    If you want to stay relevant, you have to be thinking about your mobile story.
    • Parallel computing.  On the systems side, there’s a whole new game in town.  On the user experience side, expect to have richer, more immersive and more responsive applications.
    • Reputation based.   It’s reputations that cut through the clutter and rise to the top, helped by word-of-mouth marketing and raving fans.
    • Standards / open systems.  One of the way so win in today’s world is to build great experiences on top of open standards.  Optimize for open over closed.
    • The fall of walled gardens.  It's not just B2B or B2C anymore – it’s whatever makes the most sense.
    • The rise of Social media / social networking.   Between world-of-mouth marketing, raving fans, and real time information markets for customer feedback that can make you or break you, embrace and leverage the power of the people.
    • The system of systems in the Enterprise is your OS.  Your Enterprise is your emerging mash up of systems and services.  Find a way to create an effective portfolio for analyzing what you’ve got and be thinking in terms of business capabilities, infrastructure capabilities and application capabilities.
    • The Web is the OS.  It’s the programmable Web.   Imagine how your service or capability can be exposed to the World and thrive.  Remember, it’s survival of the fittest.  Be the best or go home.
    • User empowerment.  It’s the rise of the spider and the fall of the starfish in a federated world.
    • User experiences.   This is where reputations are built and raving fans are won.  Think speed, simplicity, immersive experience, visualization, how you feel … etc.  Design working backward from the end experience in mind.  If the resulting experience suck will suck, don’t even start to build it.

    My synthesis -- stay customer connected, create value for society (it’s not a vacuum), create raving fans, build to change over build to last, learn and respond through effective business intelligence, think in terms of platforms/ecosystems/execution, be the best in the world at what you do (on the Web, you don't need a bunch of #2s),  stay flexible and adaptable, and build the network and relationships that support you and your ecosystem.

    With that in mind, here are some more keys to watch for …

    Trends to Watch in 2010 by John John deVadoss
    John runs our Microsoft patterns & practices team.  He’s great at boiling things down, spotting trends, and his super skill is providing insight for technical strategy.  Here are some of his insights for 2010:

    1. Trends to Watch in 2010 #1 - 'Bring Your Own PC'
    2. TRENDS TO WATCH IN 2010 #2 'WHITHER PRIVATE CLOUDS (THE MY CLOUD PATTERN)?'
    3. TRENDS TO WATCH IN 2010 #3 'RICH CLIENT REDUX'
    4. TRENDS TO WATCH IN 2010 #4 'CLOUDING OF THE FRONT-OFFICE' OR WHY THE FRONT-OFFICE CONTINUES TO BE THE EARLY SWEET SPOT FOR THE CLOUD
    5. TRENDS TO WATCH IN 2010 #5 'THE CLOUD AS PLUMBING VERSUS THE CLOUD AS APPLICATION PLATFORM'

    Economy + Internet Trends by Morgan Stanley
    Economy + Internet Trends  is a very nice report by Morgan Stanley.  While it reinforces the “jobless” economic recovery, it does show growth in the IT sector, and it calls out some key tech trends:

    1. Key Theme # 1 Mobile Internet Usage Is and Will Be Bigger than Most Think
    2. Key Theme # 2 Apple Mobile Share Should Surprise on Upside Near Term
    3. Key Theme # 3 Next Generation Platforms (Social Networking + Mobile) are Driving Unprecedented Change in Communications + Commerce
    4. Key Theme # 4 Mobile in Japan + Desktop Internet Provide Roadmaps for Mobile Growth + Monetization
    5. Key Theme # 5 3G Adoption / Trends Vary by Geography
    6. Key Theme # 6 Carriers in USA / W. Europe Face Surging Network Demand But Uncertain Economics.
    7. Key Theme # 7 Regulators Can Help Advance / Slow Mobile Internet Evolution
    8. Key Theme # 8 Mobile-Related Share Shifts Will Create / Destroy Material Shareholder Wealth

    I also like some of their distillations, such as “Facebook = unified communication + multimedia repository in your pocket.”

    Web 2.0 Trends from Scoble
    Kevin Skobac  put together a short presentation interpreting Scoble’s “principles of the 2010 web” from a user perspective:

    1. it's in real time
    2. it's mobile'
    3. it's decentralized
    4. it's in pre-made blocks
    5. it's social
    6. it's smart
    7. it's powerful infrastructure

    Key Questions I Ask to Find and Rationalize Trends
    These are some of the basic questions I ask to find and rationalize key trends:

    • Where are the investments?
    • Where's the growth?
    • Who are the pillars in the relevant niches and what are they saying?  … more importantly, what are they doing?
    • What are the results?
    • What’s the data say?
    • What are consumers doing?
    • Is it a real trend or just a fad? … and does it matter?

    The Meta-Pattern for Trends
    These are some of the patterns I’m noticing about the patterns of the trends:

    • Absorb what is useful.  Do it Bruce Lee style -- take what you need, adapt it, and throw out the rest.
    • Agility.  Stay adaptable.  Flexibility is your friend.  See The better adapted you are, the less adaptable you tend to be.
    • Be the Best on the Web.  there’s no room for #2.  Be the best at what you’re the best at.  This is Good to Great in action.
    • “Built to Change” Over “Built to Last.”  Again, this goes back to shifting from a static world, to a dynamic world and embracing change over fighting it.  Run with it.
    • Compete where it makes the most sense.  Compete on price, or quality or customer and don’t mix them up.  This depends on which stage of the maturity cycle you are in, what the state of the market is, and what you can be the best at.  For example, in a commodity market, don’t be the most expensive.  Turn competition into collaboration and find the win wins to really change your game and rock the world.
    • Consumer patterns drive Enterprise patterns.  At the end of the day, people are consumers and the patterns show up in the Enterprise.
    • Decentralize and federate.   Think starfish and spider.
    • Differentiate.  Differentiate by giving your best where you have your best to give.  Compete by dividing the niche and small is the new big (so you win with a portfolio that’s flexible and responsive to market demand.)
    • Execution is king.  Operational efficiency and innovating in your product cycle is how you survive and thrive.
    • Prosumer.  Think Consumer + Producer.  Get your customers into your production cycle earlier so they help you create and innovate in your product line.
    • Pull vs. Push.  Know the mental model from push to pull.  In Push Me, Pull You--Dueling Business Models, Steve Bosserman says, “Through the three hundred-year reign of the Industrial Age, businesses “pushed” their products and services onto consumers. Limited choice accompanied by considerable marketing hype was enough to make the consumer buy. It was a sellers’ market. Now, thanks largely to the Information Age, consumers are evolving into customers who can select what they want from a variety of providers. It is becoming a buyers’ market.”
    • Relevancy is king.  Google taught us this.
    • Reputation and brand are king.   In a social networked world, it’s the network that says who the authority is and what works and what doesn’t. 
    • Simplicity.  Simplicity always win in the long run when it comes to adoption.  Find ways to reduce friction and make things simple out of the box.  Design for simplicity and keep things simple where you can.
    • Social Value / Community Good.  In a green world, if you’re business doesn’t play well with green values, it’s not a sustainable path.
    • Results are king.  Talk is cheap.  Results speak for themselves.

    There are a lot of kings here.  In checkers, it’s easier to win when you have a lot of kings.

    The Way Foreword
    What’s past is past and the future

    • Build a firm foundation.  Know Maslow’s hierarchy and prioritize taking care of your basic needs.  Know your “monthly burn” and be mindful of your decisions to support your firm foundation.  The stronger your foundation is, the more you can help yourself and others when they need it most.
    • If it doesn't help you be your best, cut it out.   This means living your values, and playing to your strengths.  It also means giving your best where you have your best to give, as a person, and as a company.  It’s how your survive, and it’s how you go from surviving to thriving.   Any other way drains you in the long run and you get priced or pushed or competed out of the market.  It’s the sustainable path. 
    • Follow the growth.  Follow your own growth, and follow the growth in the market.  For example, in the tech industry some growth areas are mobile and cloud.  Along these lines, create the growth.
    • Get back to the basics.  Practice the fundamentals.  They work.  Among the chaos, there are always core principles, patterns, and practices that you can bank on.
    • Hone your personal brand.  Make the most of what you’ve got and make sure your differentiation is obvious.  For example, one of my differentiators is “getting results.”
    • Invest in yourself.  Inner-engineering always pays off.
    • It's your network and what you know.  People sort and sift through people they know.  In a skills-for-hire economy, your network is how you find the opportunities. 
    • Know the cycles of things.  For example, know the Four Stages of Market Maturity, the Technology Adoption Life Cycle, and the Diffusion of Innovations.
    • Lead yourself from the inside out.   Follow your values, play to your strengths, and follow your purpose.  It’s the sustainable path.
    • Learn and respond.  Your ability to learn and respond will drive your best results.  Innovate in your process and your product.
    • Look ahead.  Build your anticipation skills.  Know the system.  Things don’t just happen.  The more you know the system and the ecosystem, the more you can anticipate what’s coming down the line.  Pay attention to market leaders, trend setters, patterns, and cycles.  Everything happens in cycles whether it’s growth or decline.

    What else is important that I should know about or have on my radar and heat map?

  • J.D. Meier's Blog

    TFS Guide Beta 1 is Available

    • 20 Comments

    Today we released our Beta 1 of Team Development with Visual Studio Team Foundation Server Guide.  It's our Microsoft playbook for TFS.  This is our guide to help show you how to make the most of Team Foundation Server.  It's a distillation of many lessons learned.  It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.

    Contents at a Glance

    • Part I, Fundamentals
    • Part II, Source Control
    • Part III, Builds
    • Part IV, Large Project Considerations
    • Part V, Project Management
    • Part VI, Process Guidance
    • Part VII, Reporting
    • Part VIII, Setting Up and Maintaining the Team Environment


    Chapters

    • Introduction
    • Ch 01 - Introducing the Team Environment
    • Ch 02 - Team Foundation Server Architecture
    • Ch 03 - Structuring Projects and Solutions
    • Ch 04 - Structuring Projects and Solutions in Team Foundation Server
    • Ch 05 - Defining Your Branching and Merging Strategy
    • Ch 06 - Managing Source Control Dependencies in Visual Studio Team System
    • Ch 07 - Team Build Explained
    • Ch 08 - Setting Up Continuous Integration with Team Build
    • Ch 09 - Setting Up Scheduled Builds with Team Build
    • Ch 10 - Large Project Considerations
    • Ch 11 - Project Management Explained
    • Ch 12 - Work Items Explained
    • Ch 13 – MSF Agile Projects
    • Ch 14 - Process Templates Explained
    • Ch 15 - Reporting Explained
    • Ch 16 - Team Foundation Server Deployment
    • Ch 17 - Providing Internet Access to Team Foundation Server

    About Our Team

    • Prashant Bansode - Prashant's an experienced guidance builder and a master of execution.  He's a solid pillar on the team.
    • Jason Taylor - Jason's a master of results.  I've worked with Jason across a few projects.  He always hits the ground running and accelerates from there.
    • Alex Mackman - I worked with Alex on Building Secure ASP.NET Applications, Improving Perf and Scale, and Improving .NET Performance and Scalability, so it's great to have him back.
    • Kevin Jones - Kevin is new to our team, but getting up to speed fast.  He brings a wealth of Visual Studio Team System experience to the table.


    Contributors and Reviewers
    Here's our contributors and reviewers so far:

    • Microsoft: Ajay Sudan; Ajoy Krishnamoorthy; Alan Ridlehoover; Alik Levin; Bijan Javidi; Buck Hodges; Burt Harris; Doug Neumann; Edward Jezierski; Eric Charran; Graham Barry; Jeff Beehler; Julie MacAller; Ken Perilman; Mario Rodriguez; Marc Kuperstein; Matthew Mitrik; Michael Puleio; Nobuyuki Akama; Paul Goring; Pete Coupland; Peter Provost; Rob Caron; Robert Horvick; Rohit Sharma; Sajee Mathew; Siddharth Bhatia; Tom Hollander; Venky Veeraraghavan
    • External: David P. Romig, Sr; Eric Blanchet; Leon Langleyben; Martin Woodward; Quang Tran; Sarit Tamir; Tushar More; Vaughn Hughes; Michael Rummier

     

  • J.D. Meier's Blog

    10 Ways to Use Evernote More Effectively

    • 2 Comments

    This post will give you some Evernote tips and tricks for how to use Evernote as a Personal Information Manager or as a personal knowledge base.

    I think of Evernote as an "Agile Knowledge-Base."  It's like a simple Wiki, with folders and pages.  The big deal is "access anywhere" and "friction-free" notes.   The beauty is the simplicity and the focus.  As a user of blogs and Wikis, I'm a fan of simple notes.  Plain-text is my preferred note format.

    I've used Evernote for years (sidenote -- I drove a tool similar to Evernote, before Evernote, so I very much appreciated when Evernote showed up on the scene, and I empathized with some of the same technical challenges and user experience issues the Evernote team faced.)  I should also mention that I’ve created tens of wikis (if not hundreds) with many thousands of pages, tens of SharePoint sites with many thousands of documents, and tens of blogs with hundreds of posts.  In my early days of Microsoft, I‘ve created hundreds of Knowledge Base articles and managed thousands of Knowledge Base articles.  I’ve managed many thousands of pages for Microsoft patterns & practices (aside from co-authoring eight technical books.)  I’ve also created information architectures for very nasty and complex information problems to simplify them.  I regularly coach people and teams on how to keep their email at zero (I call it Zen of Zero Mail.)  

    The bottom line is -- I slice and dice information overload down to size for breakfast, and I simplify complex information.

    I've been using Evernote since 2008.  I must use it a lot since I have more than 7,000 notes.  Keep in mind, when I moved to Evernote, I started from scratch with a fresh start (or it would be many thousands of notes larger.)  I've used so many ways to store my personal knowledge base over the years, and I've learned a lot about keeping it simple, keeping it useful, and keeping it flexible and adaptable.  I’d like to share some tips and tricks with you, that might improve your Evernote experience. 

    Here we go …

    10 Ways to Use Evernote More Effectively

    1. Keep it flat.  Keeping a flat set of folders (“Notebooks”) is a simpler experience.   A folder with notes in it keeps things simple.
    2. Focus on fast browsing over creating dynamic views.  Sure you can tag things and get clever.  In my experience, focusing on naming folders better, and naming notes better, and having a place for things is way better than trying to create fancy views.   In the long run, simple folders and simple notes are easier to manage as batches if apples are with apples and oranges are with oranges.
    3. Carve out “action” from “reference.”  You can broadly think of your information as either "actionable" or "reference."  Actionable information would be things like checklists, To-Do lists, step-by-step How Tos, etc.   Theses notes help you do stuff.  Reference information is anything else.  It's all the conceptual information or raw information that you might look up or refer to.   When you carve out action, you make it easier to actually use.
    4. Keep your titles short. Keep your titles simple and sticky.  Sound them out.  When you say your title out loud, you can find a simpler name.  Name your notes what you would search for.  Whatever comes to mind is probably right, because they are your notes.  Ask yourself, "If I had to find this again, what would I look for?"
    5. Name your notes with YYYY-MM-DD.   For date-based things, this is a great way to name your notes fast.  It also makes it easy to sort and sift through them.  I like to use this for my "To Do" lists.   For example, for a To-Do list for May 18, 2012, I would simply name it, “2012-05-18.”
    6. Have a "Notes" folder.  I have one folder that is effectively my notes dumping ground.  It is my main place to stick anything and everything by default.  I don't have to think.  If it's a note, I stick it there.  I can always move it later, but it's my friction-free place to put information.
    7. Use keywords in titles to cluster your notes.   Within my “Notes” folder, I have thousand of notes.  To cluster things together, I simply use a keyword in the title.  For example, I have a bunch of unique ideas that pop into my head.  To group them, each time I write a note, I prefix it with “JD – “ … for example, “JD – How to Create a 1,000 New Jobs”, “JD – How To Be an Infopreneur”, “JD – How To Change the Cloud Game”, etc.   So when I browse my big dump of notes, I can easily scan and browse this set.  It’s a proven practice.  I’ve used it for years.  I actually learned it from the Microsoft Knowledge Base for dealing with massive mounds of information and keeping it all findable over time.
    8. Have a "Pics" folder.  I have a place to put pictures.  I always see things I want to remember, so I dump my visuals there.  Maybe I should have called it Visuals (it's easy to rename), but I like having a folder that when I browse it, it's all images.
    9. Have a "Projects" folder.  I have a projects top-folder ("Notebook Stack"), with a notebook per project.  This is my fast place to put quick notes on the things I work on.  It's "one-place to look."
    10. Periodically refactor your knowledge base.  Take the time to rework your knowledge base if it's not working for you.  Rename your folders.  Change your keywords or prefixes.  Do this periodically.  For example, once a month, see if your folder names are working for you.  Maybe you need to consolidate.  Maybe you need to take a whole batch of folders and shove them under a parent folder called Archive.  Get stuff out of your way, and surface the stuff you need.  Focus on speed and simplicity.

    Example of My Evernote Notebooks
    Below is a snapshot of my Evernote folders.  Use it to inspire your own customization of your Evernote.  That's another beauty of Evernote -- you can make it work for you.  If you're wondering what that top cluster of folder is under my "Action" folder, that's how I implement Getting Results the Agile Way.  (See How To Use Getting Results the Agile Way with Evernote.)

    image

    You Might Also Like

  • J.D. Meier's Blog

    Patterns and Practices for New Hires

    • 9 Comments

    Whether you're a new hire or taking on a new job, here's some principles, patterns and practices to be more effective.  They're lessons learned from the school of hard knocks and they represent some of the proven practices that have worked for others and have stood the test of time.   This is a limited, but prioritized list (I gave myself a 20 minute window.)  I'll drill into areas in upcoming weeks, depending on where there's interest.

    Personal Productivity

    • Timebox your day.  Carve your day into time budgets.  Figure out how much time you should spend on administration, work time, meeting time, and think time.  Start with a day.   For example, some of the most effective people spend 1 hour on admin, 1 hour on think time, 4 hours on work time, and 2 hours on meetings.  You need to find the pattern that works for you.  The trap is to not know when the day ends and over-spend time in areas you should allocate to others.   See Timebox Your Day.
    • Manage your meetings.  You'll likely spend a lot of time in meetings.  Value your time.  Find out the meeting you must go to versus should or could.  Use meetings to build your network.  The most effective meetings have agendas and the right people.  Some meeting are more about connection versus results, so if you know that up front, you can reset your expectations.  Nothing's worse than trying to get results in a connection meeting.  One thing to remember is that connection precedes results.  You get more done with rapport (think "rose colored glasses")       
    • Manage your mail.  Doing a day of email doesn't mean you did a great day of work.  Timeboxes help.  See Clearing Your Inbox.
    • Manage your action.  Think in terms of daily results working towards larger outcomes.  See Execution Checklists and Using Scannable Outcomes with My Results Approach.
    • Manage your plate.  Underpromise and over-deliver.  It's better to nail a few things well, than take on a bunch and never finish.  Think of it like a buffet -- rather than over-flow your plate and get bogged down, take smaller plates and more trips.  The fast eat the slow.
    • Master information management.  The most important concept is to factor reference information from action.  Always use the RAT test on information you get (relevant? accurate? timeley?)  Use trusted sources and trusted people for finding the best, most distilled information.
    • Manage your energy.  You can throw a lot of time at a problem, but it's your energy that will give you the power hours.  See Manage Energy, Not Time.

    Results

    • Know what's important.  Your manager and peers will tell you if you ask.  Sanity check when you hear one thing, but see another.  Usually folks are doing what's on their commitments, so walk the commitments stack up the chain to see how and where you fit in.
    • Manage your results.  Microsoft rewards "smart and gets results."  Focus on outcomes over activities.  Think in terms of value delivered over activity performed.  You can do lots of activities but that doesn't necessarily translate into meaningful results.
    • Walk an instance end-to-end.  Know what you're getting yourself into.  Whatever your team delivers, walk an instance from start to end.  Knowing the bigger picture will quickly help you orient where you are in the bigger picture.  This will help you anticipate.  You'll also know how to pace yourself for the race (walk, jog or run.)
    • Avoid analysis paralysis.  It's really easy to fall into the trap of mistaking great throughts for great actions.  Take action and improve.  Analyze enough to start taking action, getting results and improving.  Figure out your higher risks earlier versus later.  Fail fast.
    • Learn project management.  Knowing how to do a work breakdown structure, timeline, work estimates and how to allocate resources gives you an advantage in getting results.  You can apply these skills to a micro-level (personal productivity) or to a macro-level (getting large projects done.)
    • Play to your strengths.  You have your strengths.  Use them.  Find a way.  If you find yourself doing a job and you know you really could be more effective, figure out whether it's your approach.
    • Use reference examples.  Find the best reference examples and work backwards from there.  Whatever you need to do, chances are, somebody's paved a path or there's an example you can find.  You can leapfrog results if you don't always start from scratch.
    • Know the tests for success.  Nothing's worse than to finish a major project only to find you missed the mark.  Figure out the tests for success earlier versus later.  They're might not be a lot of clarity in the beginning, but continuously refine figuring out what good looks like.
    • Deliver incremental results.  If you can chunk it down, you have a better chance for success.  Show progress along the way.  Always have a great end in mind, but be able to chunk it up and make progress on the bigger picture.
    • Think in terms of value delivered.  You can think in terms of time (daily, weekly, monthly).  You can think in terms of value (how important is this).  Just the act of thinking in terms of value delivered will help you prioritize your personal queue. 

    Communication

    • Create the driver's guide for your manager.  Your manager has a high-correlation to your job satisfaction and your success in Microsoft.  What's their communication style?  Do they like email, voice or dialogue?  How frequently should you meet with them to stay on the same page?  How do they want status?
    • What's their story?  Be careful when you jump to conclusions.  When somebody doesn't do something as you expect, it's good to checkpoint assumptions.  See What's Their Story? 
    • Speak in the right currency.  Know what matters to your audience and the terms they use.  Use their terms where you can to bridge the communication gap.
    • Use metaphors and mental models.  The better you can simplify complex information into a mental model or visual, the more effective you'll be.
    • Use stories.  Use short stories to convey a point.  By short, something you can say in a few sentences.  It should be relevant and have an emotional aspect.  If just stating a point, doesn't make the point hit home, sometimes telling the right story can.
    • Use a whiteboard.  The power of the whiteboard is that people tend to put down what's important versus get lost in the details.  You can also drill in or step back as needed.
    • Speak in slides.  A slide is a great forcing function to make you consolidate your point.  At Microsoft, it's easy to pass slides around.  I use One-Sliders.

    Intellectual Horsepower

    • Ask better questions.  Thinking in just asking and answering questions.  If you want better answers, ask better questions.  You can ask question in terms of time, meaning, assumptions, truth, causes, effects and actions.  One thing I like to do is think in terms of what do I know, don't know and need to know next.  See Cutting Questions.
    • Test it versus debate it.  There's a lot of opinions on a lot of things.  You'd be surprised how quickly a simple repro test can cut through debate.  Find empirical evidence where you can.
    • Learn thinking techniques.  There's lots of thinking patterns and techniques.  You can study Disney's imagineers such as Michael Michalko, or practices such as Neuro Linguistic Programming (NLP.)

    Learning / Improvement

    • Change your approach.  Stay adaptable.  If you're not getting results, change your approach.  The best way to get unstuck is to change your approach.  You learn the most from trying something different.  Sometimes this is uncomfotable, but that's what growth feels like.
    • Model the best.  Find the people that get results.  Have at least a few examples of people that have both continuous improvement and balance.  For balance, that means both work and home, and at work it means, balance between connection and results. 
    • Take key training.  Obviously, you'll want relevant technical training, but you'll want training to make you more effective in your day to day success at Microsoft.  While I've had great tech training, some of my most useful training has been in effective meetings, personal productivity, interpersonal communication, negotiation skills, influence, leadership, and thinking techniques.
    • Use everybody as a mentor.  Everybody can teach you something.  Everybody.  Find something each person does well and find out how they do it.  Success leaves clues.
    • Use a personal sounding board.  Find some folks you trust to give you the tough feedback.  Sanity check your ideas with your personal sounding board.
    • Improve strengths, but limit liabilities.  If you spend all your time working on your weaknesses, you won't get the benefit of your strengths.  Continously improve your strength, while you master you craft.  Every day at work is a chance to practice.  Reduce your liabilities, but don't ignore improving your strengths. 

    Networking

    • If you don't know, ask.  If you ask a precise enough question, you can stretch your network over time and space.
    • Build your network.  Your network naturally waxes and wanes.  Your results are a combination of what you know and who you know.  Building your network will help you get more done over time.  It's a long-term investment that builds on itself.
    • Play tradesees.  It's easier to network when you bring something to the table.  You can trade what you know or your expertise in an area with somebody elses.  This is how a lot of effective people get results.  They build a network of complimentary skills and experience. 
    • Use WIIFY.  What's In It For You (WIIFY) is a simple, but effective way to communicate.  If you always ask yourself, what's in it for the person you're brokering in, you're off to a better start.  Point out to them what's in it for them if it's not obvious.  If there's nothing it it for them, then that's a flag.  Challenge yourself to find a way for their to be something in it for them and you'll get further.

    My Related Posts

  • J.D. Meier's Blog

    Using Live.com for RSS

    • 11 Comments

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

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

    Adding a New Page

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

    Adding Feeds

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

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

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

  • J.D. Meier's Blog

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

    • 1 Comments

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

    SaaS PaaS and IaaS

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

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

    For my related posts on cloud, see:

  • J.D. Meier's Blog

    Agile Architecture Method

    • 11 Comments
    AgileArchitecture

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

    To summarize, it’s a technique that:

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

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

    Input
    Here’s the key input into the process:

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

    Output
    Here’s the key output of the process:

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

    Summary of Steps

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

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

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

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

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

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

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

    WhiteboardingYourDesign

    An application overview consists of the following steps:

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

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

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

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

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

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

    • Baseline / Candidate Architectures
    • Architectural Spikes

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

    My Related Posts

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

  • J.D. Meier's Blog

    Application Architecture Guide 2.0 Final Release

    • 14 Comments

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

    Key Links

    Key Changes Since Beta 2

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

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

    ArchitectureMetaFrame

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

    Key Scenarios for the Guide

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

    Key Features of the Guide

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

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

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

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

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

    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

    Now Available: patterns & practices Application Architecture Book

    • 12 Comments

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

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

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

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

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

    Chapters

    Appendices

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

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

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

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

  • J.D. Meier's Blog

    Performance vs. Load vs. Stress Testing

    • 5 Comments

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

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

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

  • J.D. Meier's Blog

    My Personal Approach for Daily Results

    • 16 Comments

    I'm dedicating this post to anybody who's faced with task saturation, or needs some new ideas on managing their days or weeks... 

    One of the most important techniques I share with those I mentor, is how to manage To Dos.  It's too easy to experience churn or task saturation.  It's also too easy to confuse activities with outcomes.  At Microsoft, I have to get a lot done and I have to know what's important vs. what's urgent, and I have to get results.

    My approach is effective and efficient for me.  I think it's effective because it's simple and it's a system, rather than a silver bullet.  Here's my approach in a nutshell:

    1. Monday Vision.
    2. Daily Outcomes.
    3. Friday Reflection.

    Monday Vision
    Monday Vision is simply a practice where each Monday, I identify the most important outcomes for the week.  This lets me work backwards from the end in mind.  I focus on outcome not activities.  I ask questions such as, "if this were Friday, what would I feel good about having accomplished?" ... "if this were Friday, what would suck most if it wasn't done?" ... etc.  I also use some questions from Flawless Execution.

    Daily Outcomes
    Daily Outcomes is where each day, I make a short To Do list.  I title it by date (i.e. 02-03-07).  I start by listing my MUST items. Next, I list my SHOULD or COULD.  I use this list throughout the day, as I fish my various streams for action.  My streams include meetings, email, conversations, or bursts of brilliance throughout the day.   Since I do this at the start of my day, I have a good sense of priorities.  This also helps me deal with potentially randomizing scenarios.  This also helps batch my work.  For example, if I know there's a bunch of folks I need to talk to in my building, I can walk the halls efficiently rather than have email dialogues with them.  On ther other hand, if there's a lot of folks I need to email, I can batch that as well.

    Friday Reflection
    Friday Reflection is a practice where I evaluate what I got done or didn't and why.  Because I have a flat list of chunked up To Do lists by day, it's very easy to review a week's worth and see patterns for improvement.  It's actually easy for me to do this for months as well.  Trends stand out.  Analyzing is easy, particularly with continuous weekly practice.  My learnings feed into Monday's Vision.

    It Works for Teams Too
    Well, that's my personal results framework, but it works for my teams too.  On Monday's I ask my teams what they'd like to get done, as well as what MUST get done. I try to make sure my team enjoys the rythm of their results.  Then each day, in our daily 10-minute calls, we reset MUSTs, SHOULDs, and COULDs.  On Fridays, I do a team-based Lessons Learned exercise (I send an email where we reply all with lessons we each personally learned).

    Why This Approach Works for Me ...

    • It's self-correcting and I can course correct throughout the week.
    • I don't keep noise in my head (the buzz of all the little MUSTs, SHOULDs, COULDs that could float around)
    • Unimportant items slough off (I just don't carry them forward -- if they're important, I'll rehydrate them when needed)
    • I manage small and simple lists -- never a big bloated list.
    • It's not technology bound.  When I'm not at my desk, pen and paper work fine.
    • Keeping my working set small, let's me prioritize faster or course correct as needed.
    • It's a system with simple habbits and practices.  It's a system of constantly checkpointing course, allowing for course correction, and integration lessons learned.
    • My next actions are immediate and obvious, in relation to SHOULDs and COULDs. 

    Why Some Approaches I've Tried Don't ....

    • They were too complex or too weird
    • They ended up in monolithic lists or complicated slicing and dicing to get simple views for next actions.
    • I got lost in activity instead of driving by outcome.
    • They didn't account for the human side.
    • Keeping the list or lists up to date and managing status was often more work than some of the actual items.
    • Stuff that should slough off would, woulddn't, and would have a snowball effect, ultimately making the approach unweildy.

    I've been using this approach now for many months.  I've simplified it as I've shown others over time.  While I learn everyday, I particularly enjoy my Friday Reflections.  I also found a new enjoyment in Mondays because I'm designing my days and driving my weeks.

    My Related Post

  • 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

    Application Patterns for Application Architecture

    • 7 Comments

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

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

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

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

    Scenario

    Pattern Solution
    Here's our pattern overlay:

    PatternsSolution (2)

    Tech Solution
    Here's our technology overlay:

    TechnologySolution (2)

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

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

    Feedback

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

    My Related Posts

  • J.D. Meier's Blog

    Reference Models, Reference Architectures, and Reference Implementations

    • 0 Comments

    "All models are wrong, but some are useful." -- George Box

    I often see confusion over reference models, reference architectures, and reference implementations.  In this post, I’ll share my experience and learnings and observations:

    • Reference Model - A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes.  It’s like holding up a diamond and looking at the different facets.  It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives.  They are also useful for pulling together a bird’s-eye view of a domain or problem space.  A well-known example is the OSI model.  Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context.  By using a model, you can focus on higher-level concepts, ideas, and decisions.
    • Reference Architecture - A reference architecture provides a proven template solution for an architecture for a particular domain.  It’s the high-level “blue prints” for putting the pieces of the puzzle together.
    • Reference Implementation - A reference Implementation goes beyond a reference architecture and is an actual implementation.  This is where the rubber meets the road and it serves as an exemplar down at the implementation level.

    I think the confusion is usually because the argument usually hinges on whether a reference architecture or reference implementation needs to be in code, when that’s really just a form factor decision.  The distinction is actually the focus and concern, independent of how you share it, although code can help illuminate a reference implementation and a reference architecture.  The other confusion is often around how big or small it needs to be to determine whether it’s a reference architecture or reference implementation, but that’ also a herring.  Again, it goes back to what the focus of the example is.  If it’s an exemplar of the architecture, it’s a reference architecture.  If it’s an exemplar of the implementation, then it’s a reference implementation, and each serve different purposes, and require different levels of detail or abstraction.

    Reference Model Examples
    Reference models give us a quick way to see and talk about a given problem space.  Here is an example of a simple reference model that does nothing more than frame out some cornerstone concepts for cloud computing.  In this case, it’s a visual model for cloud computing:

    image

    This is another of my favorite reference models.  In this case, this is a continuum of moving up the stack with types of cloud services from IaaS to PaaS to SaaS :

    image

    I also like a few of the cloud reference models, especially how they can be used for overlaying security concerns.

    Reference Architecture Examples
    The beauty of the reference architecture is that you can shape the application before you implement it.  One of the simplest ways to achieve this is to whiteboard it.  When you put it on the whiteboard, you can focus on key engineering decisions and avoid getting lost in the details.  You can focus on a conceptual, physical, or logical view, … you can focus on the business perspective, user perspective, or technical perspective … and you can move up and down the stack to zoom in or zoom out … but the main point is to show how the bits and pieces should fit together.  The power of a reference architecture is that it creates a shared mental model for the architecture and design and it can help you identify the key decisions and key risks early on.  This helps you both shape a skeleton solution as well as identify what you need to prototype, especially in terms of cross-cutting concerns, or tracer-bullets.  From an agile perspective, the Reference Architecture complements the system metaphor and it helps you identify potential areas to spike on.  Here are a few examples …

    One of my favorite reference architecture examples is the reference architecture from the ESB Toolkit.

    image

    Another of my favorite reference architectures is the reference architecture for the PetShop Sample Application:

    image

    One approach I like to use for sharing reference architectures is what I call Application Scenarios or Scenarios and Solutions.  It’s a whiteboard sketch of the end-to-end solution.  Here is an example:

    image

    Another of my favorite approaches is to use what I refer to as Application Patterns.  It’s like the Application Scenarios, but I overlay patterns on top.  Here is an example:

    image

    image

    image

    The real key of reference architectures is that they help you explore the thinking and design at a higher-level before getting lost in the weeds.  Getting lost in the weeds is a common problem with reference implementations.  That’s why it’s helpful when they include a reference to their corresponding reference architecture.

    The best combinations I find for nailing a problem space include a reference model + reference architecture + reference implementation.

  • Page 1 of 43 (1,064 items) 12345»