J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Top 10 Lessons in Happiness

    • 1 Comments

    I have a guest post from bestselling author, Gretchen Rubin on The Top 10 Lessons Learned in Happiness on Sources of Insight.  Gretchen is a former lawyer from Yale, turned writer.  What’s interesting to me about Gretchen is that she studied happiness by making it a project.  During The Happiness Project, Gretchen spent a year test-driving every principle, tip, theory, and scientific study on happiness she could find.  Her guest post is a summary of her top 10 lessons.

     

    Read Gretchen’s Top 10 Lessons Learned in Happiness.   If you like that, also check out Keys for Skilled Happiness.

  • J.D. Meier's Blog

    How To Be a Successful Individual Contributor at Microsoft

    • 0 Comments

    I wrote up my top 10 lessons learned in how to be a successful individual contributor at Microsoft on Sources of Insight.  Really, these lessons apply just about anywhere, and they especially apply in our new skills-for-hire economy.  Here is a quick summary of my lessons:

    • Lesson 1. Focus on strengths, limit liabilities.
    • Lesson 2. Scale yourself.
    • Lesson 3. Know what’s valued.
    • Lesson 4. Follow the growth.
    • Lesson 5. Model the best.
    • Lesson 6. Balance the hot spots.
    • Lesson 7. Manage your plate.
    • Lesson 8. Stay in the game.
    • Lesson 9. Drive or be driven.
    • Lesson 10. You’re the sum of your network.

    For elaboration on these lessons, check out my post Proven Practices for Individual Contributors.  If you like the post, be sure to check out my related posts:

    1. Patterns and Practices for New Hires
    2. Lessons Learned in patterns & practices (Shaping Software)
  • J.D. Meier's Blog

    Discover the How to Your Why

    • 0 Comments

    I have a guest post by Janine de Nysschen on how to Discover the How to Your Why at Sources of Insight.  This is a follow up to Janine's previous guest post, Discover Your Why.  It's basically about putting your purpose into action.  When you lead with your why and your how, you can bring your best game wherever you go.  What you do is simply a channel for unleashing your best why and how.  You’ve probably noticed this in the movies you see, or the stories you read.  The context for the story might change, but you connect with the underlying themes.  It’s the journey and the destination.  This post is about leading your journey with your why and how for getting results at work and life.

  • J.D. Meier's Blog

    Lessons in Software from Mike de Libero

    • 1 Comments

    I have a guest post, Lesson in Software from Mike de Libero, on Shaping Software.  Mike was a security tester on the Microsoft Office team and has a variety of experiences under his belt.   Here is a summary of his lessons:

    • Lesson 1. All software is flawed.
    • Lesson 2. Check-in often.
    • Lesson 3. Tests, gotta love them.
    • Lesson 4. Refactor, check-in and repeat.
    • Lesson 5. Coding is easy, humans are tough.
    • Lesson 6. The more eyes on your code the better.
    • Lesson 7. Keep learning and improving.
    • Lesson 8. Simple is beautiful.
    • Lesson 9. Learn software development not coding.
    • Lesson 10. Think about your audience.

    You can read an explanation of the lessons in his post, Lesson in Software from Mike de Libero.

  • J.D. Meier's Blog

    PM Skills for Life

    • 4 Comments

    I wrote a post on PM Skills for Life on Sources of Insight.  PM is short for “Program Manager.”  I’ve been a PM for the past several years, and learned a ton along the journey.  I attempted to do a roundup of some of the key skills and how they help with skilled living.  Enjoy!

  • J.D. Meier's Blog

    Discover Your Why

    • 0 Comments

    Do you know why you do what you do?  Your why defines the difference you want to make in this world, and it inspires everything you do.  For example, I originally joined Microsoft to help change the world and improve the quality of life for people through software.  In fact, a lot of fellow Softees, joined Microsoft with the hopes to build a better world.  When you live your why, a lot of other things fall into place.  Sounds great, but how do you actually discover your why …

    Well, I have a guest post from Janine de Nysschen on how to Discover Your Why on Sources of Insight.   Janine is the founder of Whytelligence and has more than 25 years of experience in the strategy and intelligence arena.

    Even if you already know why you do what you do, check out Janine’s advice to be sure you don’t fall into the logic trap – you should be emotionally connected to your purpose.  So put on your curiosity cap and read discover your why with an open mind.  Discovering your why, just might change your life.

  • J.D. Meier's Blog

    Proven Practices for Getting Results

    • 3 Comments

    My other blog, Sources of Insight is focused on effectiveness.  I launched it as a way to put more focus on getting results and to help give my mentees a more focused path (I’m a mentor at Microsoft and regularly carry ~8 mentees.)  One of the mantras on Sources of Insight is “Stand on the shoulder’s of giants!”  The idea is that I share the best insights and actions I can find for work and life, from books, people, and quotes, along with my experience both inside and outside Microsoft. 

    Given my history on the patterns & practices team, my blog is heavily geared towards principles, patterns and practices to help people make the most of what they’ve got.  I don’t care whether you’re an architect, an engineer, a tester, or whatever … we’re all in this together, and life throws curve balls.  The purpose of the blog is to give you an unfair advantage, by sharing the world’s best insight and action for work and life.  It’s ultimately a collection of patterns and practices for skilled living.

    One of the things I haven’t been happy with is my tag line on Sources of Insight.  I’ve tested several flavors but they didn’t resonate for one reason or another.  My latest one seems to be working out pretty well.  It’s simple and to the point:  “Proven Practices for Getting Results!”  It was actually a challenging exercise to find a tag line that actually worked for my readers.  I bounced it against a broad set of people for feedback, from marketing experts to developers to you name it.  I wrote up some of my lessons learned in designing an effective tagline in my post, The Design of an Effective Tagline.

    Be sure to stop by and say hi.   Feel free to introduce yourself and let me know any hot issues you’d like to see information on and, if it’s on topic, I’ll see if I can work it in.  The main focus in the blog is a set of hot spots for life: mind, body, career, emotions, financial, relationships, and fun.

  • J.D. Meier's Blog

    Lessons in Software from James Waletzky

    • 0 Comments

    I have a guest post, Lessons in Software from James Waletsky, on Shaping Software.  James is a Development lead at Microsoft, with several years of coaching teams on Agile practices and software engineering under his belt.  Here is a summary of his lessons:

    • Lesson 1.    Keep it simple.
    • Lesson 2.    Define ‘done’.
    • Lesson 3.    Deliver incrementally and iteratively.
    • Lesson 4.    Split scenarios into vertical slices.
    • Lesson 5.    Continuously improve.
    • Lesson 6.    Unit testing is the #1 quality practice.
    • Lesson 7.    Don’t waste your time.
    • Lesson 8.    Features are not the most important thing.
    • Lesson 9.    Never trust anyone.
    • Lesson 10.    Reviews without preparation are useless.

    You can read an explanation of the lessons in his post, Lessons In Software from James Waletzky.

  • J.D. Meier's Blog

    Lessons Learned from Bruce Lee

    • 3 Comments

    I have a post on Lessons Learned from Bruce Lee on Sources of Insight.  Bruce Lee was one of my early inspirations.  He was a patterns and practices kind of a guy.  In fact, Bruce influenced my software engineering approach.  Rather than lock into a single style, he took the best techniques from various martial arts and measured against effectiveness.  For example, he took a boxer's hands and a wreslter's grappling skills.

    Here is a summary of my lessons from Bruce:

    • Be YOUR best.
    • Absorb what is useful.
    • Keep an open mind.
    • Aim past your target.
    • Stay flexible.
    • Focus on growth.
    • Master your mind and body.
    • Apply what you know.
    • Make things happen.

    My favorite Bruce Lee quote is "Absorb what is useful, Discard what is not, Add what is uniquely your own.”  It's all about finding what works for you and not blindly adopting things.

    I've included a more exhaustive list of my favorite Bruce Lee quotes in my post, Lessons Learned from Bruce Lee.  Whether you're a Bruce Lee fan or on a path of personal development, I think you'll enjoy the tour of Bruce's insight and words of wisdom.

  • J.D. Meier's Blog

    Acceptance Test Engineering Guide Beta 2 Now Available

    • 2 Comments

    Our patterns & practices Acceptance Test Engineering Guide, Volume 1 (Beta 2) is now available on CodePlex.  The working definition that the team is using for acceptance testing is the planned evaluation of a system by customers and customer proxies to assess to what degree it satisfies their expectations.

    Common Scenarios
    Here are the key scenarios the guide addresses:

    • How to Plan for Acceptance Testing
    • What Kinds of Acceptance Tests to Run
    • How to Create and Run Acceptance Tests
    • Defining What “Done” Means
    • How to Justify Your Approach
    • How to Streamline Your Acceptance Process

    Parts

    • Part I - Thinking About Acceptance
    • Part II - Perspectives on Acceptance
    • Part III - Acceptance Software

    Chapters

    • Chapter 1            The Acceptance Process
    • Chapter 2            Decision-Making Model
    • Chapter 3            Project Context Model
    • Chapter 4            System Requirements Model
    • Chapter 5            Risk Model
    • Chapter 6            Doneness Model
    • Chapter 7            Business Lead’s Perspective
    • Chapter 8            Product Manager’s Perspective
    • Chapter 9            Test Manager’s Perspective
    • Chapter 10          Development Manager’s Perspective
    • Chapter 11          User Experience Specialist’s Perspective
    • Chapter 12          Operations Manager’s Perspective
    • Chapter 13          Solution Architect’s Perspective
    • Chapter 14          Enterprise Architect’s Perspective
    • Chapter 15          Legal Perspective
    • Chapter 16          Planning for Acceptance
    • Chapter 17          Assessing Software
    • Chapter 18          Managing the Acceptance Process
    • Chapter 19          Streamlining the Acceptance Process

    Team
    Here is the authoring team:

    • Grigori Melnik
    • Gerard Meszaros
    • Jon Bach

    Contributors / Reviewers
    Here are the key contributors and reviewers:

    • Michael Puleio
    • Rohit Sharma
    • RoAnn Corbisier
    • Hakan Erdogmus
    • Dennis DeWitt

    Key Links

  • J.D. Meier's Blog

    Lessons in Software from Alok Srivastava

    • 0 Comments

    I have a guest post, Lessons in Software from Alok Srivastava, on Shaping Software.  Alok is a solution architect at Microsoft with several years of experience in large scale, distributed systems.  In this post, he shares his lessons learned in software.  Here is a summary of his lessons:

    • Lesson 1. Software development is a team sport.
    • Lesson 2. More lines-of-code does not mean better software.
    • Lesson 3. The Cloud is an inflection point.
    • Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
    • Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
    • Lesson 6. Software maintainability is a key to longer life for any software.
    • Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
    • Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
    • Lesson 9. A great software engineer never stops working.
    • Lesson 10. Know the keys to writing great software; magic isn’t one of them.

    You can read an explanation of the lessons in his post, Lessons In Software from Alok Srivastava.

  • J.D. Meier's Blog

    Six Sources of Influence

    • 1 Comments

    If you need to be a change agent at work, or make things happen in your life, Six Sources of Influence is for you.  I wrote up a post on Six Sources of Influence on my Sources of Insight blog.  The Six Sources of Influence was my favorite part of my Influencer Training here at Microsoft.   The focus of the training was to improve my skills at analyzing and executing change, especially for persistent or resistant problems.  I'm a fan of the model and I'm using it almost daily.

    The power of the Six Sources of Influence is that rather than get stuck in a default pattern or a one-trick pony routine, you can get a better lens on the situation by evaluating the six sources.  To visualize the model, think of a simple two-column table of motivation and ability, sliced in 3 parts: personal, social, and structural.  You can then walk the model to figure out the key leverage points or centers of gravity.  Instead of lucking into success, you can target your time and effort to actually produce more effective change and get results.

    Check out my post on Six Sources of Influence and take it for a test drive.

  • J.D. Meier's Blog

    Patterns and Practices of Lean Software Development

    • 1 Comments

    I have a guest post on Shaping Software from Corey Ladas on Patterns and Practices of Lean Software Development.  This is a follow up to Corey's previous post, Introduction to Lean Software Development.   Several readers had ask for more information on the principles, patterns, and practices of Lean Software Development.  Corey's latest guest post is in response to this request and provides a map and narrative of how some key principles, patterns, and practices can help support Lean Software Development.

    Read Corey's post, Patterns and Practices of Lean Software Development.

  • J.D. Meier's Blog

    Sources of Insight is 10 Months Old

    • 0 Comments

    My other little blog is growing up so fast ... Sources of insight is 10 months old.   I originally started it to improve my blogging skills as well as to put more focus on personal development.  I mentor a lot at work, so I used Sources of Insight as a channel to share patterns and practices for improving effectiveness.  I named it Sources of Insight because I draw from books, people, and quotes, as well as other sources (such as movies.)  It also reflects a lot of my learning on the job and experience from the school of hard knocks.  I try to keep the tone less technical so more people can enjoy it, while still providing deep insights.

    I've learned a lot along the way.  The biggest lesson I've learned is that working on a blog is working on your life.  It's like getting up to bat and each post is a chance to hit the ball out of the park, or maybe get a single or double, or maybe just strike out.  There's a definite ebb and flow to it, just like life.  I think that's what I like about it.

    If you stop by Sources of Insight, be sure to say, "hi."  Tell me what you like, don't like or want more of.  The key goal on Sources of Insight is to share the best patterns and practices for personal development.   If you don't know where to start, I recommend starting with the About, then You 2.0, and then Living Your Process.   If you need a boost of motivation, cherry pick your favorites from my list of Motivation Quotes.   If you want to fill your quiver with some of the best techniques for getting results, then be sure to read Rituals for Results.   It's a fast tour of some sure-fire ways to improve your results.

  • J.D. Meier's Blog

    Lean Software Development

    • 2 Comments

    I'm honored to have a guest post on Shaping Software from Corey Ladas on Introduction to Lean Software Development.  Corey is a product development methodologist and the author of Scrumban: Essays on Kanban Systems for Lean Software Development.

    In the post, Corey explains the principles of Lean Thinking, the origins of Lean Thinking,  the metaphor school of Lean Software Development and the workflow school of Lean Software Development.

    Read Corey's post Introduction to Lean Software Development.

  • J.D. Meier's Blog

    Influencer - The Power to Change Anything

    • 1 Comments

    Whether you need to change something in your life or make changes at work, influence is your friend.  I just finished a 2 day course on influence.  It exceeded my expectations.  It was jam packed with insight and action I can use on the job.  I walked away with an effective framework for diagnosing problems of all shapes and sizes.  I think of it as "skilled change management."  Rather than push on a problem from one angle or throw one solution at it, I can inspect the problem from multiple dimensions and find the best leverage points.  The heart of the approach is thinking in terms of motivation and ability, and then analyzing from a personal, social, and structural perspective.  Another key is finding and focusing on vital behaviors that exponentially improve your results.

    I wrote up my notes from my training, put them on my other blog, Sources of Insight.  The post is Influencer - The Power to Change Anything.  So far, I've shared my notes from day 1, but I still need to write up and share notes from day 2.

    Enjoy.

  • J.D. Meier's Blog

    Productivity Personas

    • 3 Comments

    I wrote a post on Productivity Personas at Sources of Insight.  It's simply a way to identify and label some common behaviors you see in yourself and others when it comes to producing results.  Once you know the personas, you can effectively switch hats and use the right personas for the job.  Using these personas, you can also better analyze team performance.  For example, if you have a bunch of "starters" but no "finishers" you might be in trouble bringing things to closure.  Here's a list of the personas:

    • Starter
    • Finisher
    • Thinker
    • Doer
    • Simplifier
    • Maximizer
    • Critic
    • Can do
    • Opportunist
    • Perfectionist
    • Details
    • Big Picture
    • Facts and figures
    • Controller
    • Tinkerer
    • Marketer
    • Achiever
    • Randomizer
    • Daydreamer
    • Procrastinator

    For a quick summary of the personas, check out Productivity Personas.

  • J.D. Meier's Blog

    You 2.0 Free E-Book

    • 3 Comments

    You20

    Personal Development is one of my passions.  I find and share the principles, patterns, and practices that work.  I have some draft thinking that I'm sharing in my You 2.0 E-Book.  I turned a slide deck into a PDF to make it easier to share.  It's brief (25) pages and quick to flip through.  More importantly, it captures a mash up of some of the most important principles, patterns, and practices for leading from the inside out.  When you drive from the inside out, you amplify your impact and improve your effectiveness.  It also gives you a strong foundation for dealing with life's curve balls.

    Why You 2.0
    Here are a some key benefits:

    • Success by design.  Rather than luck into success, you’ll know your personal combination for results.
    • Living your purpose.  Nothing fuels life like knowing what you want.
      Living your values.  Living your values help you enjoy more moments in your life, a moment at a time.
    • Playing to your strengths.  When you play to your strengths, you improve your energy, and you amplify your results.  It’s the simplest way to get more impact each day.
    • Improved results.  You’ll improve your results.  A little self-knowledge goes a long way.  You’ll be a better, faster, stronger you for whatever you want.

    Read my post and download the You 2.0 E-Book on Sources of Insight.

  • J.D. Meier's Blog

    Dr. K on How To Design a Fulfilling Life

    • 1 Comments

    I'm honored to have a guest post on Sources of Insight from Dr. Rick Kirschner (aka Dr.K on How To Design a Fulfilling Life.  Dr. K is the best-selling author of Dealing with People You Can't Stand.  If you're an engineer or simply like doing things by design, Dr. K shares some of his thoughts on how to live a life by design vs. by default.  Here's a summary of his lessons:

    • #1: Self Protection is the priority mission.
    • #2: Self Maintenance is the secondary mission.
    • #3: Create Something is your third mission.
    • #4: Connection is the fourth mission.
    • #5: Service is the fifth mission.

    For me, the guiding rule that helps me shape my life is, "give your best where you have your best to give."  It forces me to focus on my strengths and lift others up.

    Read How To Design a Fulfilling Life.

  • J.D. Meier's Blog

    Lessons Learned in patterns and practices

    • 1 Comments

    I'm a fan of continuous learning.  My post Lessons Learned in patterns & practices on Shaping Software summarizes some of my best lessons.  It's from the school of hard knocks.  I've been lucky enough to have some great mentors that have really helped me unleash my best.  I've also been lucky enough to work on a variety of challenging projects that have grown my experience and capabilities beyond what I ever expected.  The post is my attempt to both remind myself of the key lessons and to share those lessons with you.  Absorb what is useful.

    Top Ten Lessons
    Here's a list of the top 10 lessons:

    • Win the heart, the mind follows.
    • Know the tests for success.
    • Fix time, flex scope.
    • Use the system to educate.
    • Work with the right people, on the right problems, making the right impact.
    • Have the right people in the room asking the right questions.
    • Sell the vision.
    • Make it a project.
    • Know what you're optimizing.
    • Turn chickens into pigs.

    One of the ways I've learned to carry lessons forward is to turn them into terse little guidelines.  It makes them sticky and easier to recall.  I also find that some of my best mentors tend to have a way with words and they share their advice as pithy sayings.

    For more lessons and elaboration check out my post, Lessons Learned in patterns and practices.

  • J.D. Meier's Blog

    Dr. K on Top 10 Lessons in Interpersonal Skills

    • 5 Comments

    I'm honored to have a guest post on Sources of Insight from Dr. Rick Kirschner (aka Dr.K) on Top 10 Lessons in Interpersonal Skills. Dr. K is the best selling author of Dealing with People You Can't Stand.   I think that communication skills improve your effectiveness in just about any situation.  I find this is especially true in software development given how much of the work is about collaboration, teamwork, and getting things done with other people.  You can luck into communication success or you can learn key skills.  Dr. K does a great job of giving actionable, prescriptive advice for bringing out the best in people.

    Here's a summary of the top 10 lessons in interpersonal skills:

    • Lesson #1: Make Useful Assumptions
    • Lesson #2 Assume Positive Intent
    • Lesson #3: Know What You Want
    • Lesson #4: Meet People Where They Are
    • Lesson #5: Listen To Go Deep
    • Lesson #6: Choose Your Words Carefully
    • Lesson #7: Relationships Are About Perception
    • Lesson #8: Project and Expect The Best
    • Lesson #9: Keep Your Wits About You
    • Lesson #10: Create Change In Stages

    Read Top 10 Lessons on Interpersonal Skills for more on these lessons.

  • J.D. Meier's Blog

    Customer Connected Engineering

    • 2 Comments

    I posted slides on how we do Customer Connected Engineering at patterns & practices to Shaping Software.  Customers Connected Engineering (CCE) is how we engage customers throughout our product development. We formally engage customers during the planning, development, and release of our deliverables to help make sure our deliverables are customer-driven.  Customers supply the scenarios, help prioritize, and provide feedback helping reduce the gap between what we build and what customers actually need.  It's effectively a prosumer model where the producer pairs with the consumers to improve the results.

    Find out more about Customer Connected Engineering including key activities and guiding principles.

  • J.D. Meier's Blog

    Motivation Quotes

    • 5 Comments

    I added a set of my favorite motivation quotes to Sources of Insight.   You never know where you might find just the inspiration you need. 

  • J.D. Meier's Blog

    A Language for Architecture

    • 5 Comments

    ALanguageForArchitecture

    My Architecture Journal article is live, A Language for Architecture.   I wrote the article to share the map of application architecture we created during our patterns & practices Application Architecture Guide 2.0 project.  It's a simple language for helping you get in the ballpark when you're traversing the very large space of software architecture.   By framing and naming the space, we can more effectively share our principles, patterns, and practices for application architecture.   This also helps consolidate all the great information spread over time and space and threads and heads.   More importantly, if we simplify how we talk about architecture, we can move up the stack as well as pave paths for others and help mentor others in our field.  Instead of asking basic questions like what is architecture, we can ask things like how do we define archetypes for the cloud or how do improve product line engineering for common systems and application types? In our case, we're using the language to help rationalize our portfolio of assets in our patterns & practices product line.

    Why the Map
    There's an explosion of concepts in the architecture space.  While working on the Application Architecture 2.0 Guide, we needed a simple, but effective bird's-eye view of the space.  By framing and naming the space, we created a shared vocabulary, helped avoid information overload, and made it easier to find, organize, and share principles, patterns, and practices with customers, field, and product teams.  It's good for the ecosystem.

    Usage Scenarios
    Here's some usage scenarios:

    • Heat Map.  If you do product planning or competitive analysis you can use the map and language to create heat maps and create a "consumer reports" for the space you are in.  You can identify key hot spots and quickly drill in or evaluate the level of maturity in that domain.  You can use the map to find the most important areas to invest.  That's key, especially in today's economic landscape.
    • Hot Spots.   By mapping out hot spots you build a catalog of your key engineering decisions.  These become your focus points.  By focusing efforts you improve your results.  For example, if cloud computing is a hot spot, you might identify manageability within that and then you might invest your energy in reducing friction or creating opportunity in that hot spot.
    • Solution Engineering.   If you build applications you can use the map and language for quickly traversing key engineering decisions.  You can use it to quickly identify your key risks as well as explore potential solution options.  It helps you identify what you know, don't know and need to know next.  It also helps you quickly rip through technology decisions.
    • Architectural Exploration.   You can use the map as a way to explore existing systems.  By chunking up architectures into things like archetypes, qualities, hot spots ... etc. you can drill into them more effectively.  For example, you might go on an architectural expedition to build a catalog of common application patterns for your group.
    • Whiteboarding.   Effective whiteboarding is an art.  That said, whiteboarding is one of the most important tools in our industry when it comes to sharing knowledge and getting people on the same page.   You can use the language, maps, and frames to improve your whiteboarding skills by using common elements from the map.
    • Product-line engineering.  If you build software, you can use the map to get more precision over your product line by defining the scenarios, the requirements, the archetypes and hot spots.  You can also use these to differentiate.
    • Slideware.  If you have to build slides, you can use the map, the language, and the visuals to more effectively share what's important.
    • Prescriptive Guidance.   If you're in the decision improvement business, then using a common map and frames will help you organize and share patterns and practices more effectively.  What if we could easily traverse the common data access patterns for RIA applications from a security, performance or manageability perspective?  We get closer to the capability when we share common maps.

    Key Concepts
    Here's some key concepts behind the map and language:

    • Hot Spot driven.  Rather than exhaustive, the maps, language, and frames are hot spot driven.  If you can see the forest from the trees, you have a better vantage point and can more selectively drill down or elaborate as needed.   Hot spots are also where the action is.  See Security Hot Spots and Performance Hot Spots.
    • Expandable by design.  The maps are expandable by design.   You can unfold, elaborate or expand each area as needed.   You can tailor it for your context.  The maps gives you a baseline of hot spots to start from so you don't have to start from scratch.
    • Overlays.   The maps, language, and frames are backdrops.  This means we can overlay principles, patterns, and practices.  This also means we can overlay products or technologies or solution assets, such as reusable code.
    • Whiteboard oriented.    The maps, language and frames are oriented towards whiteboard usage, simply because it's one of the most universal tools in our field.  By optimizing around whiteboard usage and humans over tools, we reduce friction around sharing basic information.
    • Plays well with others.   No matter what your favorite framework or mental models are, you can leverage the maps, language and frames.  We didn't set out to build an exclusive set.  Instead, we set out to map out an inclusive set of concepts that can easily stretch to fit.  It's platform agnostic and if anything, it's most tightly bound to the knowledge areas of software architecture.  In the words of Bruce Lee, "absorb what is useful."
    • Real-world over academic.   We chose to optimize around the language, maps, and frames we see in practice.  We needed it to be simple to explain whether we're in a team full of developers or a doing a presentation for business decision makers.  It's a simple way to look at the legos and  organize them in a meaningful way.

    The Map
    The key components of the language include:

    • User, Business, and System Perspective.   Architecture is a constant balance of user, business, and technical concerns.  For example, the user wants a response time of x, but the cost and impact on the system side have to make business sense.  When you group by user, business, and system stories you get more precision around the drivers and goals and you can include the right people for the right decisions, as well as keep checks and balances.  See What are the User, Business, and System Goals.
    • Architecture Frame.  This is the main map that includes the context, the app types, the architectural styles, and the application feature frame.  The context is expressed with scenarios, requirements / constraints, and quality attributes.
    • Application Archetypes (App Types).  Application Types are simply blueprints for classes of applications.  In our Application Architecture Guide 2.0, we called out mobile, RIA, Web, Rich Client, and Services.  Those are technical types.  You could also call out a set of business types. or a set of core system archetypes.  The key is to identify a set of types for your business so you can think in terms of a product-line.  See Application Types.
    • Quality Attributes.   This includes system, run-time, design, and user qualities.  For example, a run-time quality would be availability, while a design quality would be conceptual integrity.  See Quality Attribute List.
    • Scenarios.  You can't design or evaluate an architecture in a vacuum.  Scenarios give you the context.  The scenarios are a really important element.  In terms of architecture, the architecturally significant use cases are vital to making the right trade-offs.  You can find architecturally significant scenarios by looking at the intersections of quality attributes or hot spots with application features.  See App Types, Verticals, and Scenarios and What's a Scenario?.
    • Architectural Styles.  Architectural styles are simply sets of principles that shape the software.  We grouped styles by  big decision areas: communication, deployment, domain, interaction and structure.The beauty of architectural styles is we can talk about higher-level goals before getting into specific technologies.  For example, if you choose SOA as your architectural style for your communication, you can then evaluate whether WCF or ASMX helps you implement those principles.  Every app is a mash up of styles. 
    • Requirements and Constraints.   Requirements and constraints are simply what's required of the system.  Again, this is where user, business, and system perspectives matter.  We called out functional, non-functional, technological, and constraints.  Non-functional would include quality attributes and constraints would include organizational and industry compliance.  See Requirements Types and  User Requirements vs. System Requirements.
    • Application Feature Frame.   This is a set of hot spots focused on a common set of key engineering decisions.  We called out Caching, Communication, Concurrency and Transactions, Configuration Management, Coupling and Cohesion
      Data Access, Exception Management, Layering, Logging and Instrumentation, State Management, Structure, Validation, and Workflow.  These are  the types of decisions you don't want to make up on the fly and you want to avoid do-overs.  You'll also notice our industry is rich with principles, patterns, and practices in these categories, as well as reusable components.  For example, you can overlay Enterprise Library on several of these areas.   See Application Infrastructure Frame.
    • Application Frames.   These are hot spots based on a given application type.  For example, for Web applications, we defined Authentication, Authorization, Caching, Exception Management, Logging and Instrumentation, Navigation, Page Layout (UI), Page Rendering, Presentation Entity, Request Processing, Service Interface, Session Management, Validation.  Notice that the map has a lot of similar categories to the core application infrastructure frame.  The key is context.  Now we are talking about validation within Web applications.  Also notice that some hot spots are more Web centric such as page layout and page navigation.  Also notice that we can overlay key Web patterns on these hot spots.  Instead of a laundry list of patterns, we can find, organize, and share key patterns for these hot spots.
    • Layers, Components, and Tiers.  We called out layers, components, and tiers so that we could have a common backdrop with the various existing bodies of work.   We kept layers logical and tiers physical (a precedent set back in 2001 to help untangle confusion.)  We called out the presentation, business, data, and service layers.  You can extend that for things like productivity layers or manageability layers.  Keep in mind that layers are fractal, in other words you might have a service that has a presentation, business, and data layer within it.  Effectively you can think in terms of macro and micro levels.  For components we called out presentation components (user interface, user process), business components (application facade, business, business entity, business workflows), data layer components (data access logic, data helpers/utilities, service agents), and service layer components (service interfaces, message types).  For tiers, we called out 2-tier, 3-tier, and N-tier.
    • Pattern Maps.  We created pattern maps based on the frames.  For example, for each application type (Web, RIA, Mobile ... etc.) we used the hot spots to overlay relevant patterns.  This helped us surface up the most important patterns for a given topic and avoid information overload.
    • Product and Technology Maps.   We created product and technology maps organized by scenarios, application types, and hot spots.  The key here was making it easy to traverse the problem space and overlay the solution space.
  • J.D. Meier's Blog

    The Elegant Code Cast on PRISM 2.0

    • 1 Comments

    Bob Brumfield and Blaine Wastell from our patterns & practices team talk about Prism 2.0 with the Elegant Code Cast in Code Cast 26 - Prism 2.0.   Prism 2.0 is our patterns & practices Composite Client Application Guidance.  It's prescriptive guidance to help you build modular Windows Presentation Foundation (WPF) and Silverlight client line of business (LOB) applications.

    My Related Posts

Page 28 of 45 (1,117 items) «2627282930»