J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    The Changing Landscape of Competitive Advantage


    In the article, The Strategy Accelerator, Alfred Griffioen shares some specific examples of how today’s landscape changes the competitive arena:

    • Online auctions replace relationship-based purchasing processes.
    • Small, innovative companies can offer their services and compete with larger players.
    • Faster product rationalization -- fast distribution technologieis increase the competition among products, while prices decline.
    • Transparency has increased, moving investment decisions from a company level to an activity level.
    • Knowledge can be obtained more easily, relevant components and partners can be found all over the world, and financial. resources can be obtained more easily for a good idea.
    • Small, specialized organizations with high added value activities can lead the new economy.

    I’ve seen this in action, and I like how Alfred called these out.  It helps us not just see the landscape, but start to form new rules for the road.

    My Related Posts

  • J.D. Meier's Blog

    Brand is the Ultimate Differentiator


    One town that all roads seem to lead to, is that … brand is the ultimate differentiator.

    It’s a reflection of the perception of perceived value, the emotional benefits, the intangibles and the culture and the values that the brand stands for.  In fact, a good way to test your brand is to figure out the three to five attributes that it represents.  

    Brand is a powerful thing because it’s a position in the mind.  For some categories, especially on the Web, sometimes you only need one brand at the top, and the rest don’t matter.  That’s why sometimes the only way to play, is to divide the niche, or expand to a new category.

    As an individual, your brand can serve you in many ways at your company, from opening doors to creating glide paths … especially, when your reputation proceeds you in a good way.

    The trick as an individual is, how do you fit in, while finding ways to stand out and sharing your unique value?

  • J.D. Meier's Blog

    Trends for 2011


    I put together a trends map in my trends for 2011 post.

    I took a look across consumer trends, Enterprise trends, market trends, and what's on the minds of CIOs, CFOs, and CEOs.  I also drew from my experience from talking with key folks on what's going on, including many customers and what they're focused on.  I included a round up and distillation of many sources, so you can drill into even more.

    The post is long, but I've saved you several hours, if not days, of research and bubbled up several key sources that will help you create your own map of trends.  I designed the post to be very scannable so you can hop around pretty fast.

    Trends are your extreme advantage. By knowing where the action is, you can focus your energy for better results.  You also avoid surprises.  You can also reshape your job to be more relevant, and you can use market insights to follow the growth, or create new growth.   As cycles of change get shorter, one of your best skills to build is anticipation.  Anticipation helps you respond over react.  Key tip – The Art of the Long View teaches us to have multiple long views.

    Explore trends for 2011.


  • J.D. Meier's Blog

    Windows Phone Developer Guidance Map


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

    The Windows Phone Developer Guidance Map helps you kill a few birds with one stone:

    1. It show you the key sources of Windows Phone content and where to look (“teach you how to fish”)
    2. It gives you an index of the main content collections (Code Samples, How Tos, Videos, and Training)
    3. You can also use the map as a model for creating your own map of developer guidance.

    Download the Windows Phone Developer Guidance Map

    Contents at a Glance

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

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


    Special Thanks …
    Special thanks to Adam Grocholski, Allison Kent, Constanze Roman, Dan Reagan, Dragos Manolescu, Georgia Pettigrove, Kevin Lam, Mark Chamberlain, Paul Enfield, Pete Brown, Srinivas Iragavarapu, and Will Clevenger for helping me find and round up our various content collections.

    Enjoy and share the map with a friend.

    My Related Posts

  • J.D. Meier's Blog

    Lessons Learned in Execution


    I’ve been thinking about execution and the lessons learned.   I’ve summarized some insights and reminders.

    I’ve been lucky enough to grow up with patterns & practices over the last 10 years, so I’ve been able to see what works, what doesn’t, and the difference that makes the difference. 

    The Vital Few
    Here are the vital few lessons:

    1. Portfolios, Programs, and Projects.  The portfolio helps paint the map of investments at a glance.  It’s your heat map of opportunity, where to invest, and de-invest.    Programs connect the projects to simple themes and big bets.  Your execution is gated by how many projects can run in parallel at a healthy rate.  For example, “each year, we can produce 5 big projects, and 3 small ones”, or “every six months, we can do 3 big things, or 10 little ones”, etc.
    2. Product Line and Catalog.  Internally, you have a product line – the “things” you make.  Externally, you have a “catalog” which organizes your products in a meaningful way for customers.  Customers can ask for “xyz” in the catalog.  An effective model for catalogs is organizing by “topic or category” and “type of thing”  The closer you can map your portfolio to your catalog, the easier it is to see execution, results, and customer impact.  Your product line helps you know at a glance, roughly how long a given product takes to build.  A good product line is also a way to ensure that the interfaces across your product line and the key relationships among your products is well understood.
    3. Project cycles and product cycles.  Having a distinction between the project and product cycle help you optimize and use the right tool for the job.  For a simple example, Scrum is more of a project process, while XP is more of a product development process.  The project cycle is important at the business level.  It’s the cadence of the projects.  It’s where the vital few milestones are established in terms of start, key checks, ship, and post-mortem.  Product cycles on the other hand, are geared towards the product development.  The secret sauce here is that the work breakdown structure (WBS) is shaped by the product line, and maturing your work breakdown structure is how you streamline execution.  The WBS is also a way to share tribal knowledge and promote success across teams.  It’s how we know how to build patterns, or build a guide, or build a Reference Implementation versus make it up as we go, do it ad-hoc, or just wing-it.  It’s also how we know the right people and skills to have on the project, understand the nature of the work, know the key bottlenecks, and know the basic timeline.
    4. Vendor partners you trust.     This is the key to scaling execution.  It’s the key to keeping engaging work.  It’s the key to moving up the stack.  It’s the key to keeping up with a changing landscape.  The partnership is also key though, versus throwing over the wall.  Sharing values, principles, patterns, and practices helps optimize the execution.  One way to improve execution here is to have the right relationships in place (such as an account owner).  Another way to dramatically improve results is simple checklists that help share tribal know-how.
    5. Project teams and resource pools.   If project work is how we get things done, then the model for the project team is essential.  Time and again, projects fail because they didn’t have the right skills or capabilities on a team, and too many dependencies or risks, that weren’t obvious.  The key though is having resource pools of the right disciplines that support having the right project teams.  The keys to effective project teams are: roles, responsibilities, capabilities, accountabilities, empowerment, processes, and tools.

    20 Additional Game-Changers …
    Here are some additional ways to improve execution:

    1. Planning Frameworks.    This is the heart of the portfolio planning and creates buy-in from the top down, and an execution framework for the bottom up.  What’s important is that you have an agreed planning framework and that’s easy to change.  Additionally, it should be responsible to learning from the bottom up and by people in the trenches.
    2. Organizational model.  This is the heart of the execution engine.  The key here is reducing decision making complexity, pushing autonomy to the end leaf nodes, and providing a clear escalation path for cross-team issues.
    3. Feature/Scenario crews.  This is the unit of execution for projects.  It’s the assembly of the key roles and disciplines into a functional team, for a product, feature, or scenario.  In patterns & practices, our “solution” or feature crews consisted of program manager, product manager, architect, developers, testers, user education, and vendor support.
    4. Cadence and communication.   This is where project milestones, checkpoints, and communiqué or newsletters, as well as quarterly business reviews help make a difference.
    5. Know your Worst Bottleneck.  TOC (Theory of Constraints) boils down to knowing what you’re gated by: ideas? People? Money? Time? … where’s the friction?   If you had X, how much more Y could you do?
    6. Rhythm of the Business (ROBs).   ROBs help create a cadence and a framework for enforcing accountability.  Minimally, this translates into quarterly business reviews.
    7. Measures, metrics, and Scorecard.  The key here is having a small frame around both internal success and external success.  For example, external success is measuring awareness, adoption, and sat.  Internal success might be around product impact, execution excellence, team health.
    8. Dashboards.  Dashboards are a simple way to reflect back to everybody how we’re doing.  A good dashboard helps confirm what you know, reveal surprises, and helps create a spirit of momentum and learning.
    9. Customer Success Metrics.  This is crucial for online success.  It’s about having one measure that you can use to evaluate customer success.  For example, with Amazon, they can measure completed transactions.  That means somebody found what they wanted and voted for it by paying, and Amazon successfully fulfilled the need.  When you have the one simple measure of success, then you can experiment with your online strategy and do A/B testing to see whether you improve or reduce success against the one guiding metric – it’s your North Star of online success.
    10. The Pie and the Slices.  This is about knowing at a glance, how big the pie is, and what your slices are, that you can impact.  This impacts charter and helps establish boundaries and collaboration, and reduce or change competition in a healthy way.  
    11. Innovate in your process and product.  Innovation in your process is what enables innovation in your product … otherwise, you end up to expensive or get pushed out by a competitor’s approach.
    12. Pilots and experiments.   This is a way to reduce risk, while setting the stage for innovation.  The simplest way to reduce the risk is to timebox it, constrain resources, or set a budget limit, or a combination thereof.  The key to getting results is knowing what your pilot or experiment is testing for.  Start with hypotheses so you can guide your work and make the most of it.
    13. Raving fans.  Measure results by building raving fans and brand loyalty.   Net Promoter score and customer satisfaction scores are keys.
    14. Customer-Proof Points.    These give you a quick way to tell stories of customer success, and to boil down to two simple numbers: 1) a change in satisfaction, and 2) a change in customer confidence. 
    15. Customer-Connected Engineering.  Co-create the product with the customer.  Rather than build it and they will come, or throw it over the wall to see what sticks, pair with customers up front.  See Customer-Connected Engineering.
    16. Surveys are the short-cut.   Surveying customers up front to influence the investments and where to invest, helps ensure hitting the customer sweet spots.  It’s part of Customer-Connected Engineering for creating feedback loops.
    17. Scenario Maps.  Create maps of questions and tasks from customers.  This is one of the most effective ways to gain a solid handle on the problem space.  What you lose in time from execution, you make up in time by working on the right things (and more importantly, by not wasting time on the wrong things.)  It’s a focus on the vital few, while having a shared map of the larger context of the problem space.
    18. Measure against effectiveness.  This is the short-cut to intrinsic value.  Rather than chase perception, you can cut right through and measure customers against performing concrete/actionable tasks with the product.  This provides actionable feedback to improve your product, and it improves customer success, effectiveness, and satisfaction along the way.
    19. Quality gates and inspections.  A simple way to streamline the execution and to avoid downstream do-overs is to inject just enough quality gates and inspections that bake in the learnings.
    20. Templates and tools.  Templates speed up projects.  By having templates for scorecards, vision scopes, and checkpoints, it makes it easier to scale section across the team, and make success more systematic and repeatable.  It also makes it easier to fine-tune the process since there is a common backdrop.
  • J.D. Meier's Blog

    Leadership Blogs


    I added a map of Leadership Blogs, A- Z at http://sourcesofinsight.com/2010/12/06/leadership-blogs/.

    Here is my short list:

    1. 800.CEO.Read
    2. David Zinger on Employee Engagement
    3. Extreme Leadership, Inc., by Steve Farber
    4. HBR.org (Harvard Business Review)
    5. How To Change the World, Guy Kawasaki
    6. Lead by Example, by John Baldoni
    7. Michael Hyatt on Intentional Leadership
    8. Seth’s Blog, by Seth Godin
    9. The Art of Change, by Dr. Richard Kirschner
    10. The Blog of Tim Ferris

    Do you have a favorite blog on leadership I should know about?  Tell me about it – I think of my collection of leadership blogs as a living list.

  • J.D. Meier's Blog

    Guidance Product Model for Domain “X”


    Here is a sketch of the mental model I use when thinking through how to address a space with prescriptive guidance:


    At a high level, it’s a “stack,” and by having a model of the stack, you can choose how far up the stack to go:

    • Domain Knowledge – This is about breaking the problem space down into useful nuggets.  The most useful nuggets I’ve found are: frames, application types, qualities, hot spots, design guidelines, principles, patterns, and capabilities.  Frames would simply be mental models or ways to look at the space.  Hot Spots are areas within the problem space that get a lot of attention, either because they create a lot of pain, or create a lot of opportunity, or they are simply high use.   Qualities would be quality attributes like security, performance, reliability, etc.  These cross-cutting concerns shape the solutions within the space.
    • “Blue Books” – This is a way to package, share, and scale the expertise within a given domain.  It’s a collection of the key principles, patterns, and practices for that domain, packaged into a cohesive whole.  This action-guide, or prescriptive guidance, creates a bird’s-eye view of guiding principles that help govern solutions within the space.  By sharing the common application types, hot spots, frames, deployment patterns, technology maps, etc., it creates a way to make sense of the problem domain, and serves as a firm foundation for more specific solutions.  It’s like the driver’s guide for the space.  See The Power of Blue Books for Platform Impact.  They have been the most effective way I’ve been able to transfer large amounts of know-how to the developer and architect communities.
    • Playbooks – These are like thin “Blue Books.”  A playbook can be used to target a specific scenario or set of scenarios.  These are effectively “thin” Blue Books.  They build on the generalized guidance and make it more specific, by walkthrough through instances or examples to light up the guidance.
    • Knowledge Base (KB) – I’m a fan of a “thin guide” + “thick KB” approach.  The knowledge base serves as a clearing house for the nuggets of insight and action within the domain.   They are more of a random access collection of useful solutions or insight into key concepts, without having to be packaged into a guide.
    • Tooling – There are many ways to provide tooling.  The ideal scenario is to have flexible tools that codify the patterns and practices by having better defaults, starter templates, starter code, guiding principles, baselines that can easily be tailored, etc.  Ideally, the tooling is connected to a live stream, where it can continuously evolve based on the knowledge from the community.  For example, “building code” would be very specific guidelines, such as technology recommendations or scenario-based patterns.  Ideally, these can turn into either rule-checkers or at least provide support for manual inspection.
    • Community – This is where the magic can happen.   By providing enough of these raw materials in the form of mental models, principles, patterns, etc. it’s easier for folks in the trenches, thought leaders, and anybody with a passion in the space to build on the knowledge and stretch and evolve it into new directions, and continue to advance the knowledge in the domain.  A key to enable this though, is having places to go where people feel like their contributions can actually make a difference, and help influence or impact the greater good.

    One thing I didn’t explicitly show in the model, is the idea of media, such as videos and slides, and train-the-trainer material.  To really get adoption, the media and train-the-trainer material help spread the word.  They make it easier for raving fans to adopt and to help spread, as well as to help teach others.

    Together, all these parts work to create a “platform” and an “ecosystem” for prescriptive guidance.  While it’s not a hard and fast model, it has helped me both figure out the opportunities, as well as evaluate competition, and it helps me see where various types of deliverables fit into a bigger backdrop for impact.

  • J.D. Meier's Blog

    Just Enough


    I happened to look over to my bookshelf and noticed that I have two books that landed together by chance:

    1. Just Enough Project Management
    2. Just Enough Software Architecture

    I’m a fan of “just enough.”  One of my mentors liked to quiz me with the question: 

    “How much process do you need?”

    The answer was always, “just enough.”

    The question, of course, then becomes, how much is “just enough?”  The answer to that is, it depends on what’s the risk? … what’s at stake?  It should be commensurate to risk.

    I always liked the example we gave regarding how much to invest in performance modeling:

    “The time, effort, and money you invest up front in performance modeling should be proportional to project risk. For a project with significant risk, where performance is critical, you may spend more time and energy up front developing your model. For a project where performance is less of a concern, your modeling approach might be as simple as white-boarding your performance scenarios.”

    Just enough not only helps you eliminate waste, in the form of unnecessary overhead, but it frees you up to better balance your other trade-offs and priorities.

  • J.D. Meier's Blog

    Why Does Culture Matter?


    I saw the Facebook privacy issue on the news. I remember somebody saying, developers should just be responsible.  A common practice is to "make it work, then make it right."  The problem is, you don't always get a chance to "make it right."  That very much depends on what your organization values.  The values define the culture.

    I flashed back to our early values in patterns & practices.  The thing to know about values, is that values flow down.  It's what the leaders say, it's what they reward and punish.  It reminded me of why our collective set of values was so important.

    If you value cost …

    1. You might find that nobody that makes the stuff, cares about the stuff.
    2. Your customers only love you while you're the cheapest.
    3. You might be chasing a losing battle, or win a battle to lose the price war ... another person, team, company, country is always cheaper.
    4. If it's all about cost, nobody will be excited about making great things, or fixing the stuff that gets in the way of great.

    If you value execution …

    1. You might ship a bunch of stuff.
    2. You might spend all your time on the wrong things.
    3. You might find nobody cares about the stuff, including your customers.
    4. You might ship at a rate, that nobody can absorb.
    5. You might ship a bunch of problems that your users have to deal with.
    6. You might ship a bunch of stuff, but lack the impact that counts.
    7. You give yourself a chance to iterate your way to goodness and greatness.

    If you value learning …

    1. You might find the problems, before your customer do.
    2. You might fix the problems, your customers tell you about.
    3. You might prevent your problems in the first place.
    4. You might evolve your process and your product enough to stick around.
    5. You attract continuous learners, who like to improve what's around them.
    6. Your learning loops create a path to greatness.
    7. You might invest in innovation and R&D, in a way that changes the game, or at least your game.

    If you value quality …

    1. You might change your game.
    2. You attract people with a passion for excellence.
    3. You create trust and reputation (good things in a reputation world.)
    4. You improve your people, process, and product as a natural by-product.
    5. You prioritize time and energy to "make it right."
    6. Your quality becomes a differentiator that's hard to copy.

    If you value customer-connection ...

    1. You might value, what your customers value.
    2. You might know how to price your stuff.
    3. You might figure out, what they don't like, maybe even before they do.
    4. You might ship the things that your customers care about.
    5. You might find more ways to create value, in ways that match your customer's world.

    When I look back to the values we had in patterns & practices, I see how they helped pave the way for great:

    • Continuous Learning - Continuous learning, innovation and improvement - We have a bias toward action (over more planning) and customer engagement and feedback (over more analysis.)
    • Customer-Connected - Open, collaborative, relationships with customers, Microsoft field, partners, and Microsoft teams.
    • Execution - we take strategic bets, but we hold ourselves accountable for creating value, shipping early and often, and delivering results that have impact with customers and in Microsoft.
    • Transparent - Explicit, transparent, and direct communication with customers and with our team and others in our company.
    • Quality - Quality over scope - no guidance is better than bad guidance.

    If you don't think you, your team, your company, etc. are on a path to great, check the values for clues.  It’s not about having this value or that (after all, all values are … well … valuable) ... the magic is in the blend, and often the difference is in what’s missing or out of balance.

  • J.D. Meier's Blog

    Lessons Learned from Bill Gates


    I shared some lessons learned from Bill Gates.   He sets a high bar and pushes the envelope of what's possible in a lifetime.  That's what's great.  Thinking back, he was one of the key reasons I joined Microsoft.  He'd rather be making impact, than sitting on the beach.  His passion is contagious.  He set the bar for “smart and gets results.”

    Read lessons learned from Bill Gates and if you have a lesson or insight from Bill, be sure to share.

  • J.D. Meier's Blog

    Windows Azure Whitepapers Roundup


    While hunting and gathering cloud-related white papers, I found a nice collection of our Windows Azure white papers:

    For more whitepapers, see the Windows Azure Home at http://www.microsoft.com/windowsazure/whitepapers/default.aspx

    If you know of some great Windows Azure or cloud-related whitepapers, please share in the comments.

  • J.D. Meier's Blog

    User Stories for Cloud Enterprise Strategy


    This is a collection of user stories for the cloud.  This collection is a simple way to share the most common scenarios that Enterprise Architects, business leaders, and IT leaders will be facing as they adopt cloud technologies.

    I decided to kill two birds with one stone.  First, I wanted to share a simple example of how to share user stories.  User stories are a powerful way to identify and enumerate the problems, wants, and needs within a given domain.  Having a bird’s-eye view helps you see the forest from the trees so that you can better prioritize as well as see trends and patterns.  Second, I wanted to share a real example that’s relevant and easy to relate to.  In this case, I’m sharing cloud user stories.  I can’t think of a more relevant body of knowledge for this significant inflection point in our industry.

    There are two key outcomes from this post: 1) You can effectively share user stories for a problem space, and 2) You have a good understanding of some of the key challenges facing Enterprise Architects, business leaders, and IT leaders in terms of cloud technologies.

    An example is worth a 1000 words, but one of the things I want you to notice in the user stories below, is the wording.  The secret to wording effective user stories is to use persona-based scenarios with goals.  For example, “As an Enterprise Architect, I want to …” or “As an IT Leader, I need to ….”  Yes, this looks simple, but this phrasing is powerful.  It makes it easy to collect user stories in a fast way.  The mistake is to have a bunch of user stories that are over-generalized and over-loaded.  With user stories, the key is to be clear, simple, and straightforward.  Clever is the enemy.  It should be easy for anybody to read the user stories and easily make sense of them without having to do a bunch of mental gymnastics or parsing.   The simpler the better.

    If you see key stories that I’m missing, feel free to share in the comments.  The beauty of having a map of user stories is that it’s easy to add or reshape the map.   This is the key to being able to leverage multiple smart people in an organized way.


    • Awareness / Education
    • Architecture
    • Availability
    • Competition
    • Cost
    • Governance and Regulation
    • Industry
    • Integration
    • Operations
    • People
    • Performance
    • Planning
    • Risk
    • Security
    • Service Levels / Quality of Service
    • Solutions
    • Sourcing
    • Strategy
    • Support

    Cloud Enterprise Strategy Scenarios Map



    Awareness / Education

    • As a Business Leader, I want Microsoft to define their perspective on Cloud Computing and provide a holistic view of how their products, technologies and services help me
    • As an Enterprise Architect I want to know how the cloud architecture supports my business goals and enterprise architecture
    • As an IT Leader I want details on training and educating my staff in the use and support for the service

    View More…

    • As a Business Leader, I want to understand why I wouldn't go to a proven partner that has a history of doing this for my competition, one that is already providing a similar service as part of our outsourcing agreement
    • As an Enterprise Architect I want to understand how the cloud architecture reduces complexity
    • As an Enterprise Architect, I want a way to see what my peers are doing, to learn and support each other
    • As an Enterprise Architect, I want actionable guidance for prioritization of ground apps to cloud apps. How do I work out the balance for what should go into the cloud?
    • As an Enterprise Architect, I want education on the content myself so that I am well versed in the specific items that apply to my customer
    • As an Enterprise Architect, I want to know the good, bad, and ugly so that I am not misrepresenting this to the customer based on marketing material
    • As an Enterprise Architect, I want to understand why I would even consider moving to the cloud. What we have works, why change?
    • As an Enterprise Strategy Architect, I want to understand the perceptions of customers and assumptions they will have that lead to preconceived ideas – and how do I ‘unlearn’ them to get to a better discussion
    • As an Enterprise Strategy Architect, I want to understand the right sequence of steps to educate a customer on cloud
    • As an IT Leader, I want to know where the complexity is in the cloud. Every new paradigm claims to be simpler but still has to deal with the same operational baggage – where is the complexity in cloud solutions?
    • As an IT Leader, I want to know why I wouldn't just go to a traditional outsourcer
    • As an IT Leader, I want to understand how I manage corporate data that may span multiple cloud scenarios
    • As an IT Leader, I want to understand why I would introduce yet another environment into my services and the associated complexity


    • As an Enterprise Architect, I want to see reference architecture for compelling cloud scenarios that will help me build a desired end-state for my specific customer scenario
    • As an Enterprise Architect, I want to see case studies of both success and failure
    • As an Enterprise Strategy Architect, I want to learn about proven Reference Architecture patterns for the cloud.

    View More…

    • As an Enterprise Architect, I want to understand Microsoft’s reference models for cloud concepts and terms.
    • As an Enterprise Strategy Architect, I want data movement and management patterns and best practices
    • As an Enterprise Strategy Architect, I want to identify Cloud System Integration Patterns (Cloud-To-Ground, VendorCloud-To-Ground, OurCloud-ToVendorCloud, VendorCloud-to-VendorCloud-to-Ground, etc)


    • As a Business Leader, I want to understand geographical redundancy
    • As an Enterprise Architect, I want to know how to handle disaster recovery in the cloud
    • As an IT Leader, I want to understand the same details I would expect from my own data center (fault tolerance, back up procedures, disaster recovery etc.)

    View More…

    • As a Business Leader, I want to know what happens when the next country decides to block Internet access
    • As an Enterprise Architect, I want to learn how to evaluate cloud services for availability across all regions I need to cover. (What is the performance? What about support in a global environment?)


    • As a Business Leader, I want to know how Microsoft’s cloud offerings compare to the competition, and especially Amazon Web Services
    • As a Business Leader, I want to understand how cloud offerings can give me a leg up on my competition
    • As an Enterprise Architect, I want a way to know what competitors are saying and how it should be addressed


    • As a Business Leader, I want to understand the cost structure for cloud solutions
    • As an Enterprise Architect, I want a way to create a realistic cost model based on the current workload
    • As an IT Leader, I want to know if I need to migrate or rewrite my apps and what are the costs associated with this

    View More…

    • As a Business Leader, how do I manage the transition period in which I probably have to pay twice?
    • As a Business Leader, I want a consistent cost of service so that I can manage against my budget
    • As a Business Leader, I want to know how to manage cloud service subscriptions across a large enterprise to optimize subscription costs
    • As a Business Leader, I want to know that I am not going to incur a large spike in my costs as part of the migration to the cloud
    • As a Business Leader, I want to know what geographic redundancy does to my bandwidth usage and costs
    • As an Enterprise Architect, I want a way to assist with the customer presentations and planning discussions
    • As an Enterprise Architect, I want a way to identify areas in IT where cost reductions can be had with relatively low risk
    • As an Enterprise Architect, I want the costs to be known and predictable so that I can budget accordingly
    • As an Enterprise Architect, I want to learn how to manage cloud service subscriptions across a large enterprise to optimize subscription costs
    • As an Enterprise Architect, I want to understand how to build the cost model for the customer
    • As an Enterprise Architect, I want understand the taxation impact on Cloud based Transactions (state, Federal, inter-nation)
    • As an IT Leader, I want a clear cost breakdown contrasted against my current costs or if I used my existing environment
    • As an IT Leader, I want to understand how I can implement chargeback within my IT environment to provide more transparency on costs
    • As an IT Leader, I want to understand the cost structure for the cloud solutions

    Governance and Regulation

    • As a Business Leader, I want to know how to manage government regulations related to where certain info can be stored. (For large enterprise that have subsidiaries in several countries. A single cloud service may not be able to comply with each countries various regulation needs)
    • As an Enterprise Architect, I want a way to address all regulations and restrictions that may be realized for my customers in all areas they do business
    • As an Enterprise Architect, I want to ensure I am meeting regulatory requirements

    View More…

    • As a Business Leader, I want to know how to adhere to the various government regulations related to pricing and information storage
    • As a Business Leader, I want to understand the environmental impact of moving to the cloud. How will this impact my green initiatives?
    • As an Enterprise Architect, I want to learn how to adhere to the various government regulations related to pricing and information storage.
    • As an Enterprise Architect, I want to learn how to manage government regulations related to where certain information can be stored.
    • As an Enterprise Architect, I want to understand the jurisdiction issues with the cloud and how to mitigate them for my region(s)


    • As an Enterprise Strategy Architect, I want to identify the relevant cloud industry trends for the business.


    • As a Business Leader, I want to understand how I integrate with my existing systems
    • As an Enterprise Architect, I want to understand how to integrate cloud solutions with my existing processes
    • As an IT Leader, do I need to move all my integrated apps to the cloud or can I do this progressively? What does this mean when apps are integrated (data, web services…)?


    • As an IT Leader, I want to know how many environments do I need and what are the implications and costs (dev/test/pre-prod/prod)
    • As an IT Leader, I want to know how to integrate cloud reporting into my existing reporting infrastructure
    • As an IT Leader, I want to understand release management requirements to ensure they fit with our current procedures or do not create undue overhead

    View More…

    • As an IT Leader, I want to know what the reporting capabilities of the service are. This provides visibility to the business on how the services are performing.
    • As an IT Leader, I want to understand a holistic view on management that spans all cloud scenarios
    • As an IT leader, I want to understand how I model the health of applications that may span private and public clouds or fully deployed in public cloud to ensure I can have better control on service levels.
    • As an IT Leader, I want to understand how I model the health of applications that may span private and public clouds or fully deployed in public cloud to ensure I can have better control on service levels
    • As an IT Leader, what is the flexibility of an organization to decide of when upgrades are appropriate based on their priorities and rhythms and how can I test my environment before upgrading the production environment?


    • As a Business Leader, I want to understand how my workforce must evolve to embrace the cloud
    • As a Business Leader, I want to understand how the cloud impacts my user base globally
    • As an Enterprise Architect, I want to know what this means to IT teams (Do I need to get rid of people or repurpose the teams -- which means here up leveling, training)

    View More…

    • As a Business Leader, I want to understand how various cloud scenarios impact my workforce levels
    • As an Enterprise Strategy Architect, I want guidance for measuring the impact of moving a system to the cloud (business and IT)


    • As a Business Leader, I want to understand how my service level management processes need to cater to online service redelivery
    • As an Enterprise Architect, I want to know what are the availability, reliability, and scalability of the cloud (What do the SLAs mean? Do they still hold the same commitments?)
    • As an IT Leader, I want to know that I can make quick patches to address immediate quality of service issues

    View More…

    • As an Enterprise Architect, I want the cloud to provide elasticity for my business as it expands and contracts to address seasonal load
    • As an IT Leader, I want to know how to more effectively manage capacity requirements to avoid underutilized infrastructure and leverage online service more effectively
    • As an IT Leader, I want to understand the level of service I can expect for all of my user base


    • As a Business Leader, I want to understand how I test the solution before deployment
    • As a Customer, I want to know how to work out the balance for what should go into the cloud – I accept it’s not 0% and not 100% - but how do I find the right balance?
    • As an Enterprise Architect, I want to develop some guiding architectural principles to help me build strategy and roadmap around Cloud Computing

    View More…

    • As a Business Leader, I want to determine the effort needed to migrate our existing solution. Is this a lift and shift? Is this a rewrite, do we extend?
    • As an Enterprise Architect, I want a way to determine the items in the cloud offerings that are relevant to my customer
    • As an Enterprise Architect, I want my application portfolio management to inject cloud relevant criteria to decide what moves to the cloud and when (if it all)
    • As an Enterprise Architect, I want to ensure we are not impacting the ability to realize change
    • As an Enterprise Architect, I want to know how I can reduce my IT infrastructure burden by bursting capabilities into the cloud when I can’t outsource the whole service to the cloud
    • As an Enterprise Architect, I want to know what maturity levels for what capabilities I need to ensure to better enable leveraging cloud scenarios
    • As an Enterprise Architect, I want to understand how I can treat my physical infrastructure assets as more of a fabric and abstract the complexities of OEM devices


    • As a Business Leader, I want to know how I can retrieve my IP/Data should I decide to move provider (service lock-in)
    • As an Enterprise Architect, I want to understand the areas of risk that I am accepting by trusting an external data center and service
    • As an IT Leader, I want to know the blockers that lead to implementation failure

    View More…

    • As a Business Leader, how comfortable is a European company to host in a datacenter that is in the US?
    • As a Business Leader, I want to know what happens if the service is not reliable. What are my options? Can I easily find another solution and get out of the contract?
    • As a Business Leader, I want to understand the risks of depending on a single partner to run my business
    • As a Business Leader, I want to understand what is involved if we decide to return to our existing service
    • As an Enterprise Architect, I want to be able to test with low risk opportunities if we decide to proceed
    • As an Enterprise Architect, I want to know how to avoid vendor lock in
    • As an Enterprise Architect, I want to understand how to identify low risk opportunities for the cloud
    • As an IT Leader, I want to know the blockers for adoption that cause decision paralysis
    • As an IT Leader, I want to know where the complexity is in cloud based solutions


    • As an Enterprise Architect I want to understand what new security risks exist in the cloud and what old risks have been mitigated
    • As an Enterprise Architect, I want to know how I manage identity across cloud scenarios considering I’ve already invested heavily in my internal IT
    • As an Enterprise Architect, I want to know how to manage privacy and integrity of the data if it’s hosted in the cloud. (How do I restrict access to the data by the hoster, and what do I do about a local copy of the data that is synchronized regularly?)

    View More…

    • As an Enterprise Architect, I want to know how to manage accessing cloud services from within the various heterogeneous internal networks
    • As an Enterprise Architect, I want to understand a holistic view on security that spans all cloud scenarios
    • As an Enterprise Architect, my company has invested in a common directory (AD/SSO). How does this work in the cloud?

    Service Levels / Quality of Service

    • As a Business Leader I want to understand who is liable in the event of a service failure
    • As a Business Leader I want to understand who is liable in the event of a security breach
    • As an Enterprise Architect, I want to understand what level of technical support is available to myself and my team

    View More…

    • As an Business Leader, I want to know if I’ll have to change my SLA with customers
    • As an Enterprise Architect, I want to know how the cloud infrastructure is supported


    • As a Business Leader, I want to try before I buy and have access to a proof of concept
    • As an Enterprise Architect, I want access to experts that can do analysis on creating solutions to determine the issues, risks, and costs for migration
    • As an IT Leader, I want to understand the balance for what should go in the cloud; I accept it’s not 0% and not 100%, how do I find the right balance

    View More…

    • As an Enterprise Architect, I want a way to assist with the proof of concept
    • As an Enterprise Strategy Architect, I want to know how I can backup our Ground based HPC with the Cloud for on demand scale
    • As an IT Leader, I want my IT strategy to reflect Cloud computing, on-premises and off-premises capabilities


    • As an Enterprise Architect, I want to know how to do partnership management in the cloud. (Managing a partner is hard and when this comes down to the fact that the service can be unavailable it is even more important to do a good job)
    • As an Enterprise Architect, I want to know how to evaluate whether the application or system is considered core to my business and could be sourced to a partner in the cloud (Can the system or application be hosted outside of the intranet?)
    • As an Enterprise Strategy Architect, I want to know how to use the Cloud for our DR plan. (i.e. fail from Ground to Cloud)


    • As an Enterprise Architect, I want to understand Microsoft’s strategy for cloud


    • As a business leader, I want to know how we integrate with our existing help desk for escalation
    • As a Business Leader, I want to know if there is a reliable support structure (24x7)
    • As an IT Leader, I want to know what happens if something goes wrong; how fast will I be notified of an issue, how long will it take to be addressed, what priority will I be given contrasted against the other consumers of the service?

    View More…

    • As a Business Leader, I want to know what the support implications are in a global environment
    • As an Enterprise Architect, I want to know how to evaluate or enforce a 24x7 support model with the cloud
    • As an Enterprise Architect, I want to know who I call if I am experiencing an issue with the hosted solution
  • J.D. Meier's Blog

    How To Use Getting Results the Agile Way with Evernote


    One of the most common questions I get with Getting Results the Agile Way is, “What tools do I use to implement it?”

    The answer is, it depends on how "lightweight" or "heavy" I need to be for a given scenario.  The thing to keep in mind is that the system is stretch to fit because it's based on a simple set of principles, patterns, and practices.  See Values, Principles, and Practices of Getting Results the Agile Way.

    That said, I have a few key scenarios:

    1. Just me.
    2. Pen and Paper.
    3. Evernote.

    The Just Me Scenario
    In the "Just Me" scenario, I don't use any tools.  I just take "mental notes."  I use The Rule of Three to identify three outcomes for the day.  I simply ask the question, "What are the three most important results for today?"  Because it's three things, it's easy to remember, and it helps me stay on track.  Because it's results or outcomes, not activities, I don't get lost in the minutia.

    The Pen and Paper Scenario
    In the Pen and Paper scenario, I carry a little yellow sticky pad.  I like yellow stickies because they are portable and help me free up my mind by writing things down.  The act of writing it down, also forces me to get a bit more clarity.  As a practice, I either write the three results I want for the day on the first note, or I write one outcome per note.  The main reason I write one result per sticky note is so that I can either jot supporting notes, such as tasks, or so I can throw it away when I've achieve that particular result.  It's a simple way to game my day and build a sense of progress.

    I do find that writing things down, even as a simple reference, helps me stay on track way more than just having it in my head.

    The Evernote Scenario
    The Evernote scenario is my high-end scenario.  This is for when I'm dealing with multiple projects, leading teams, etc.  It's still incredibly light-weight, but it helps me stay on top of my game, while juggling many things.  It also helps me quickly see when I have too much open work, or when I'm splitting my time and energy across too many things.  It also helps me see patterns by flipping back through my daily outcomes, weekly outcomes, etc.

    It's hard to believe, but already I've been using Evernote with Getting Results the Agile Way for years.  I just checked the dates of my daily outcomes, and I had switched to Evernote back in 2009.  Time sure flies.  It really does.

    Anyway, I put together a simple step-by-step How To to walk you through setting up Getting Results the Agile Way in Evernote.  Here it is:

    If you’re a OneNote user, and you want to see how to use Getting Results the Agile Way with OneNote, check out Anu’s post on using Getting Results the Agile Way with OneNote.

  • J.D. Meier's Blog

    Adam Grocholski on Timeboxing


    Adam Grocholski has a great post on timeboxing.  In his post, he shares his secrets of how he’s applied Getting Results the Agile Way to take control of his time.  One of my favorite parts is where he explains how he made a business case with his customers to spend less time in meetings, and more time producing results.

    Check out Adam’s post on Timeboxing.

  • J.D. Meier's Blog

    MSDN Library Home Adds Quick Links


    Jeff Braaten let me know that the MSDN Library Home is now featuring Quick Links … and it’s poetry in motion:


    The point behind the Quick Links is to help you jump quickly to some of the most popular areas of the MSDN Library.

    App Types / Platform Technology Clusters
    The links are clustered around key application types and platform technology areas:

    • Cloud Development
    • Data Development
    • Desktop Development
    • Game Development
    • Phone Development
    • Web Development

    API Reference, Code Samples, and How Tos by Technology
    At a glance, you can quickly jump to API references, Code Samples, and How Tos for some of your favorite technologies:

    • ADO.NET
    • ADO.NET Entity Framework
    • ASP.NET
    • Azure Tools for Microsoft Visual Studio
    • CSS
    • HTML
    • Internet Explorer
    • JavaScript
    • LINQ
    • Silverlight (out-of-Browser Support)
    • Silverlight for Windows Phone
    • SQL Azure
    • SQL Server
    • WCF
    • WCF Data Services
    • WCF RIA Services
    • Windows Client
    • Windows Phone Developer Tools
    • WPF
    • XNA

    Enjoy browsing the Quick Links!

  • J.D. Meier's Blog

    How Microsoft IT Does Cloud Computing


    While researching some cloud topics, I came across a nice resource on TechNet called How Microsoft IT Does It.

    It’s an insider’s look showcasing how our Microsoft IT department plans for, deploys, and manages our enterprise solutions across the business lines using our Microsoft product and technology platforms.

    Here is a roundup of the cloud-focused resources.




  • J.D. Meier's Blog

    Six Steps for Enterprise Architecture as Strategy


    One of my new favorite books is, Enterprise Architecture as Strategy, by Jeanee W. Ross, Peter Weill, and David C. Robertson.  My colleague, Danny Cohen recommended it as one of the best books on enterprise strategy and I agree.

    A big focus of the book is on execution and how to build a strong foundation for execution.  The key is an effective enterprise architecture.  With an effective enterprise architecture, you can improve business agility, achieve higher profitability, reduce time to market, lower IT costs, improve access to shared customer data, lower the risk of mission-critical systems failures.  Enterprise architecture as strategy means your enterprise architecture is addressing two key challenges: 1) integration and 2) standardization across the company.

    Six Steps to Build a Foundation for Execution
    Here are six steps Ross, Weill, and Robertson identify for re-thinking a foundation for execution and creating and effective enterprise architecture:

    • Step 1 –Analyze your existing foundation for execution.
    • Step 2 – Define your operating model.
    • Step 3 – Design your enterprise architecture.
    • Step 4 – Set priorities.
    • Step 5 – Design and implement an IT engagement model.
    • Step 6 – Exploit your foundation for execution for growth.

    Summary Table and Notes
    In this table, I  summarized key notes along with each step:

    Step Notes
    Step 1 - Analyze your existing foundation for execution
    • Identify digitized processes.
    • Figure out which processes are mission critical transactions.
    • Identify elements of IT that are world-class.
    • Evaluate the reach, security, data access, and flexibility you need.
    • Identify the strengths and weaknesses in your foundation.
    Step 2 - Define your operating model
    • Identify the processes that differentiate you competitively
    • Envision your ideal customer experience.
    • Determine how you want to grow (acquire or grow related businesses, expand globally, acquire competitors, offer more products and services.)
    Step 3 - Design your enterprise architecture.
    • Map out the essence of your business – your foundation for execution (companywide business processes, shared data, key technologies, and critical customer interfaces.)
    Step 4 - Set priorities.
    • Highlight priorities on the core architecture diagram (the base that the future capabilities depend on)
    • Align the project portfolio to match the enterprise architecture
    Step 5 - Design and implement an IT engagement model.
    • Create a formal IT engagement model (1) IT governance at senior levels, 2) disciplined project management across all major projects, 3) linkages that ensure IT governance and project management reinforce each other.
    Step 6- Exploit your foundation for execution for growth.
    • Plan to cash in on the benefits.
    • Allocate generous funding for training and development.
    • Align incentives so people are motivated to exploit the foundation.
    • Encourage and reward creativity.
  • J.D. Meier's Blog

    Reference Models, Reference Architectures, and Reference Implementations


    "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:


    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 :


    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.


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


    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:


    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:




    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.

  • J.D. Meier's Blog

    Change is Good


    "All projects experience changing requirements.  Traditional projects view this as bad.  Agile projects embrace it."  -- Steven Thomas, BBC

    Kelley Hunsberger writes about embracing scope creep, rather than fight it in her article “Change is Good”, in PM Network.

    According to Hunsberger, scope creep can create three key opportunities:

    1. Clients can figure out exactly what they want - clients figure out what they really want through the process
    2. The project team discovers a thing or two - the technical team is figuring out what works and what doesn't.
    3. Flexibility pays off - the ability to react to something late in the cycle is a competitive advantage.

    In my experience, this tends to be true, especially for knowledge work or where the work is not well known.  Change is a good thing, especially when it means acting on windows of opportunity, and delivering more value, in a timely way.  Customers tend to embrace the change when they are involved throughout the process.

    My favorite point in the article is about shaping scope as you go -- "With every sprint or iteration in agile, you are adding more clarity to the project's scope and reacting to it.  But just because you are changing the scope of a project doesn't mean you are adding more scope to it."

  • J.D. Meier's Blog

    Test-Driven Product Design


    One way to drive more effective product design is to start with scenarios.  One way to think of this is “Persona-based scenarios with goals.”  You can use the scenarios as test cases.  The scenarios can help you evaluate the design and they can help you evaluate implementation.  Simply put, “Can the persona or user perform the particular scenario effectively?”  You can then use criteria to evaluate.

    It’s test-driven product design.

    You can imagine how you can start with key themes and then break those down into more specific groups or frames. You end up with unit tests for experiences or scenarios and you can evaluate key things.  For example, if you were doing a competitive assessment, you might evaluate against the following criteria:

    • Complexity
    • Time to implement
    • Out of the box experience
    • Compliance with best practice

    The frames approach is a common approach for how platform competitive assessments are performed.  That’s why we adopted it as an approach for how we do prescriptive guidance … it’s a proven practice for mapping out the problem domain within a given domain or space.

    Example Scenarios Map
    This is an example of mapping out core scenarios, in this case, developer scenarios for source control:


    Example of Sub-Scenarios
    This is an example of elaborating the core Branch/Label/Merge scenarios above:


    There are many ways to gather, organize and use scenarios.  In the end, what’s important is that you have the user scenarios validated with the actual users, and that you use them as a hub to bring together the customer, the developers, and the testers.

    The beauty is that you can re-use the scenarios, whether it’s to explain your product, write documentation, or create prescriptive guidance.

  • J.D. Meier's Blog

    Evaluation Criteria Example


    I often find myself sharing examples of evaluation criteria in the prescriptive guidance space.  Here are some examples of criteria from one of my favorite platform assessments:

    • Best practice compliance. For a given analysis topic, to what degree did the platform permit implementation of best practices? Factors influencing best practice compliance include transparent integration (the default behavior enforces best practices automatically), user-assist features in the IDE, and degree of clarity of configuration.
    • Implementation complexity. How difficult was it for the developer to implement the desired feature? Factors influencing implementation complexity include the ease of use of the feature (as implemented in a tool), amount and length of code (if any was needed) Quality of documentation and sample code . How appropriate was the documentation? If examples were supplied with the documentation, were they sufficient to illustrate the concept, and did they exhibit best practices?
    • Developer competence. How skilled did the developer need to be in order to implement the security feature? To ensure an apples-to-apples comparison, prior knowledge of the tools platform is not assumed.
    • Time to implement. How long did it take to implement the desired feature or behavior?
    • The search cost. How long did it take for the user to find information on how to use the feature? Was the information shipped with the product or was it found externally on a vendor website or via search engine?
    • The implementation time. How long did it take, after knowledge assimilation, to configure or code the platform to implement correct behaviors?
  • J.D. Meier's Blog

    Scenario Scoreboards for Testing Your Product Success


    Here is an example of a simple, but surprisingly effective way to test your product success. Around patterns & practices, a few of us affectionately called this a “consumer reports” view.  Whether your product is prescriptive guidance or code, the concept is the same – you’re testing your product against user scenarios.

    To create a Scenario Scoreboard, simply put together a matrix of scenarios. Next, add criteria. Next, test against the scenarios and rate the criteria.  Note – There are two keys to making this successful: 1) have a useful collection of scenarios, and 2) get agreement on the criteria.  You want agreement on the criteria so that people can stand behind the results.  Tuning your criteria can help you tune your product success.  You’re basically creating a feedback loop to measure the success of your product against user scenarios.

    Example of a Scenario Scoreboard
    What’s important in the example is the simple frame:  scenarios and criteria.   The scenarios are grouped into buckets.


    Scenarios / Tasks


    Best Practice Compliance

    Implementation Complexity

    Implementer Competence

    Time to Implement


    • How to push peak loads to the cloud to reduce the size of an on premise data center.
    • How to decide if you application is right for the cloud (on-premise vs. cloud, advantages/disadvantages)
    • How to run your own VM in the cloud.
    • How to run an on-premise app in the cloud.
    • How to create a small-to-medium Web app.
    • How to create a large Web application.
    • How to create a parallel processing application.
    • How to store blog data for an on premise application.

    Arch / Design

    • How to structure your application.
    • How to partition based on latency.
    • How to scale horizontally.
    • How to scale vertically.
    • How to manage state.
    • How to design for Hybrid  (i.e. part of the application runs on premise, part in the cloud)

    Auditing and Logging

    • How to log information.
    • How to throttle your logging.
    • How to determine your log destination
    • How to view logs


    • How to authenticate callers.
    • How to perform single sign on (Federation).
    • How to build an STS.
    • How to identify callers.
    • How to manage personally identifying information / sensitive data in the cloud. 


    • How to use roles to protect resources.
    • How to leverage claims.
    • How to turn your application into a claims aware application.
    • How to turn claims into roles.


    • How to use local storage.
    • How to leverage a distributed cache.
    • How to swap out cache providers.
    • How to cache data effectively.
    • How to expire the cache.


    • How to cache configuration data.
    • How to decide what settings you should use.

    Data Access

    • How to design an extensible schema that will never need to be updated.
    • How to choose a partition key for different entities.
    • How not to get too much data into one partition.
    • How to repartition your live data.
    • How to load initial/domain data.
    • How to do BI in the cloud.

    Monitoring / Health

    • How to monitor web roles.
    • How to monitor worker roles.
    • How to alert/alarm.

    Performance and Scalability

    • How to simulate load tests.
    • How to compare blog storage against local files.
    • How to measure performance against CRUD.
    • How to do capacity planning.
    • How to access/view Performance Counters


    • How to design statelessness.


    • How to decide which storage to use.
    • How to organize your containers and blobs efficiently.
    • How to track/retrieve additional information/properties about blobs
    • How to authorize access to containers/blobs


    • How to roll back.
    • How to update multiple pieces of data at the same time.
    • How to implement 2-phase commit.
    • How to lock effectively.

    Worker Model

    • How to schedule work.
    • How to group different types of work.
    • How to communicate between different types of worker roles.
    • How to determine the number of worker roles.
    • How to determine if multiple threads should be used


    • How to design for asynchronous work.
    • How to design for integration (custom cloud applications / finished services / on premise / ESB.


    • How to deploy seamlessly with no downtime
    • How to architect your application to allow data schema deployment to happen independent from app deployment

    Ratings for the Evaluation Criteria
    Here are some examples of ratings for the criteria:

    Rating Category


    Best Practice Compliance Ratings

    1. Not possible
    2. Developer implements
    3. Developer extends
    4. Wizard
    5. Transparent

    Implementation Complexity Ratings

    1. Large amount of code
    2. Medium amount of code
    3. Small amount of code
    4. Wizard +
    5. Wizard

    Quality of Documentation and Sample Code Ratings

    1. Incorrect or inaccurate
    2. Vague or Incomplete
    3. Adequate
    4. Suitable
    5. Best Practice Documentation

    Developer/Administrator Competence Ratings

    1. Expert (5+ years of experience
    2. Expert/intermediate (3-5 years of experience)
    3. Intermediate
    4. Intermediate/novice
    5. Novice (0-1 years of experience)

    Time to Implement

    1. High (More than 4 hours)
    2. Medium to High (1 to 4 hours)
    3. Medium (16-60 minutes)
    4. Low to Medium  (6-15 minutes )
    5. Low (5 minutes or less )

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Product Success Frame for High Customer Impact


    What proven practices have you seen are vital behaviors that significantly contribute to customer success? …

    That’s a common question I get, having spent the bulk of my time at Microsoft in patterns & practices.  In fact, that’s a question the Windows Azure team asked me last Summer, as a way to boil down my lessons learned from patterns & practices and turn the insight into action.

    Let me first set the stage that this information is primarily what contributes to a product’s success aimed at “developers.”

    Banging on Products from Multiple Angles Helps You See the Good, the Bad, and the Ugly
    I’ve had a chance to see the good, the bad, and the ugly in terms of our products and how they land with customers.  I’ve participated in many dog-fooding exercises, supportability reviews, platform evaluations, etc., so I‘ve learned what to look for.  Because I’ve worked across so many products and technologies, I’ve had the chance to see what success patterns, as well as anti-patterns, show up time and again.   In fact, one of the things I often do is cross-pollinate the best practices that I see across various product teams.

    As an aside, before I joined patterns & practices, I worked in Microsoft Developer Support, which means I was on the receiving end of customer pain, and I learned how to walk a product from a usability and supportability standpoint, as well as learn many of the supportability (and “un-supportability”) patterns.

    A Quick Sampling of Product Success Patterns … 
    Here is a quick example to light up the idea of how some teams set the state for product success.  For example, the ASP.NET team drove significant improvements into their platform early on through eating their own dog food and performing application building exercises. This created a lot of empathy for customers and customer scenarios. Having “Blue Books” or “Platform Playbooks” for security and performance helped win significant accounts, as well as create a glide-path for customers coming from the Java world. The QuickStart for ASP.NET with it’s amazing set of “Common Tasks” helped many, many developers get up and running with the platform in a simple way. Having a set of common baseline architectures and deployment patterns helped us show customers how to make the platform work for their scenarios in a proven and repeatable way.

    Some Products are Destined for Success 
    To share what I’ve learned, I’ve created a simple frame that encapsulates some of the things that I’ve seen make a key difference. Creating prescriptive guidance has always been a combination of creating a “driver’s guide,” test driving the product against customer scenarios, finding effective solutions and workarounds, and improving the story around qualities, such as security or performance. During the process, I’ve found that some products are destined for success and have a strong customer adoption story out of the gate, while others face an uphill battle or never really succeed.

    Sadly, I can easily see products that will fail, right up front too.

    Product Success Frame
    Here is the frame I’ve been using for sharing some of the most important product success patterns. 


    It needs some iterations, but it’s been useful so far for putting some key success patterns into buckets.  The table below shares some examples of what would fall under these buckets.  After the table, I’ve provide some visual examples to help illustrate.



    Mental Models

    How to picture, think about, and talk about the problem space.

    • A Language for the Space (“Domain Model” / “Folksonomy” )
    • Application Scenarios (Common Patterns)
    • Canonical Architecture
    • Customer Solution Stacks (common combos of product and technologies)
    • Deployment Patterns
    • Frame (Lens for looking at the space, what’s in, what’s out)
    • Hot Spots (Top Areas of Pain or Opportunity)
    • Pattern Language (Shared vocabulary for the key concepts)

    Prescriptive Guidance

    Sharing and scaling expertise, including driver’s guides and proven practices.


    “Train-the-Trainer” material for wide-spread adoption and viral expertise.

    • Architecture Kit
    • Case Studies         
    • Demos
    • Offerings (MCS / Service SKUs)   
    • Roadmap  
    • Rude Q&A            
    • Slides        
    • Train-the-Trainer 
    • Webcasts / Podcasts


    • Capabilities Matrix
    • Competitive Studies


    Knowing your unique value and where you stand in the market or how you relate.

    • Capabilities Matrix
    • Competitive Studies

    Building for the customer and with the customer to co-create a better future, as well as simplifying the user experience, and making it easy to find all the blocks.


    Assume bad things happen to good people and making it easy to fall into the pit of success or get back to a successful state, or avoid falling off the cliff in the first place.

    • Dog-fooding
    • Fault-Tree Model
    • Supportability Review
    • Supportability Whitepaper


    Know the touch points and the constellation of channels where users interact with your stuff, along with the user experiences for each of those channels.

    • 3rd Party / Partner Sites
    • Community Site (Home)
    • Dev Centers
    • Forums
    • Subscriptions   


    • Customer Proof Points
    • Product Support Reviews (“BillG Reviews”)
    • SEO Analysis and Data
    • Usability Studies
    The Network

    Get the network on your side, from a tribe of raving fans, and closer followers, to a wider community base.

    • 5 Pillar Customers (Reference examples and champions)
    • Blogger Team
    • CAT (Customer Advisory Team) Team (“SQL CAT”)
    • Champs (Internal / External)
    • Community PM
    • Insiders (“ASP.NET Insiders”)
    • MVPs
    • Product Support / Escalation Team
    • Rangers (“TFS Rangers”)

    A Quick Tour of Examples …
    The following is a quick visual tour of some of the common things that help customers make the most of the product.

    Application Scenarios and Solutions Example
    Application Scenarios and Solutions are a quick sketch of how to solve an end-to-end problem, along with key information on how to prototype the solution and test whether the solution will work for your scenario.


    Canonical Application Architecture Example
    A canonical application architecture helps customer see how to put the building block technologies together into an ideal pattern.


    CAT “Customer Advisory Team” Teams
    Customer Advisory Teams site between the product and the customer and they help address the patterns of customer problems through prescriptive guidance and hands-on support.  They can also provide in-depth product feedback because they see the patterns and practices of large sets of customers, against specific scenarios and solutions.

    • Focused team that connects the customer scenarios to the product team.
    • Strong engineering team with a solution focus.
    • Solves customer problems (with a by-product of code and content re-usable assets.)
    • Provides actionable product feedback to the product teams.

    For an example, see the SQL CAT Team.

    Catalog of Solution Assets Example
    When you build out a catalog of solution assets, it’s a proven practice to have a set of content types.   This helps users know what to expect in your catalog.  This also helps you streamline your efforts for populating your catalog.  The key is to focus on a small set of high ROI content types.  For example, a common pattern is to focus on code samples, how tos, videos, and tutorials.


    Customer Proof Points
    Customer Proof points are simply verbatums and scores on a slide from a customer to help show impact.  The verbatums provide qualitative and the scores provide quantitative.  The two key numbers to see are overall satisfaction and a change in confidence in the product, tool, or platform.  


    Deployment Patterns
    Deployment Patterns show how the common ways that the application is physically distributed.  This can help you very quickly see the end in mind.


    Feature Set Example
    Having your feature set at a glance, helps users quickly see all the dials, knobs, switches at a glance.  Having the features at a glance is also an easy way to help your users learn the scope of your product.  You can also use the features at a glance as one way for organizing, driving, and prioritizing your documentation.  This, in conjunction with a scenarios map is a powerful combination.


    Hot Spots for Architecture
    Hot Spots are basically a heat map of common pain points or key engineering decisions.  They help you quickly see the forest from the trees in a given domain.  For example, in a typical application, some of the cross-cutting concerns are auditing and logging, authentication, authorization, data access, exception management, etc.  Knowing the Hot Spots helps inform you as an product designer or engineering, by helping inform you where to invest more energy.


    Hot Spots for Security Example
    You can think of Hot Spots as a lens and you can overlay or focus on a particular topic, such as security, and highlight just those Hot Spots.


    Hot Spots for Performance Example
    Here is an example of bubbling up common performance Hot Spots for a Web application.


    How Tos
    How Tos provide step-by-step instructions for performing a task or solving a problem.  When done well, they are among the most valued content because they directly map to user challenges, scenarios, and tasks.


    See Security How Tos for an example of a How Tos collection.

    Scenario Frames / Maps Example
    Scenario Maps are an easy way to gather and organize all the user scenarios in a meaningful way.  Scenarios put requirements into context by showing what a particular user would try to accomplish.  A collection of scenarios acts as a map that helps you see the landscape of your product, from both the engineering and the user view.


    Scenario Scoreboard Example
    A Scenario Scoreboard is a simple way to evaluate the effectiveness of your product against the user scenarios.  You simply add evaluation criteria and rate each scenario against the products, tools, and platform.


    QuickStarts (Simple Starts for Common Tasks)
    QuickStarts are a way to share a quick map of common tasks, along with examples and step-by-step guidance.


    See example at - http://quickstart.developerfusion.co.uk/QuickStart/howto/

    My Related Posts

  • J.D. Meier's Blog

    Anu on Getting Results the Agile Way


    “Productivity is never an accident. It is always the result of a commitment to excellence, intelligent planning, and focused effort.” -- Paul J. Meyer

    Anutthara Bharadwaj, a Program Manager on the Microsoft Visual Studio team shares her experience on adopting the Agile Results system in her post, Getting Results the Agile Way.  In her story, Anu writes how she went from being overwhelmed to on top of her game by adopting three core practices:

    1. The Rule of 3
    2. Monday Vision, Daily Outcome, and Friday Reflection
    3. Hot Spots

    I like her concrete examples.  In her case, she uses One Note to implement the system.   That’s the power of the Agile Results system.  It’s a principle-based system so you can use whatever tools works best for you for adopting the practices.  (I’ve used everything from pen and paper, whiteboards, Evernote, Outlook, One Note, simple text files, etc.)

    Small changes in your day, add up to big changes in life.  I’ve had the chance first-hand to watch Anu transform and it’s been an amazing journey.

    Stop by and check out Anu’s post on Getting Results the Agile Way.

  • J.D. Meier's Blog

    Time Management Tips #9 - Pair Up



    What's the best way to do it?


    Pair up.

    Time management tips #9 is pair up.  Paring up simply means find somebody that will work with you on something, rather than go it alone.   When you pair up, you create a team of capabilities and you learn how to love the things you might otherwise hate.  Worst case, you at least make doing what you don’t enjoy, more fun.  Best case, you find a new passion for something you didn’t know you had.

    We all have things to do that we're not great at, or slow us down.  Maybe it's because we don't have talent for it.  Maybe it's because we hate doing it.  Maybe it's because we just don't know a few tricks of the trade. (Sadly, I find the that it’s missing the tricks of the trade, that holds us back the most … and learning the tricks, actually unleashes a passion in us, because we no longer suck at it … it’s such a chicken and an egg scenario time and time again.)

    Chances are you know somebody who is great at whatever it is that you need to do, or at least better than you.  Just because you might hate to do something, doesn't mean that somebody else does not live for it.  One person's trash is another's treasure.  And that's a good thing. 

    Pairing up is the fastest way to transfer tribal knowledge.  It’s visceral.  You *feel* it.  You immerse yourself in it.  You get to see how somebody that likes doing this activity, actually goes about it.  It's your chance to learn everything from the mindset they have, to the questions they ask, to the short-cuts they use, or how they make it fun.

    One of my favorite phrases at work is, "Show me how."

    So many experts love to show and share how they do their magic.  It puts them in their element.  Sometimes they will genuinely want to help you succeed.  Other times, it's just so they can show off.  Either way, it doesn't matter.  What matters is that you make the most of it.

    One of the best pairing situations is where you find a "workout buddy" for work.  Maybe you are good at doing slides, and maybe they are good at technical details.  When you pair up, you can both look good, and you both have something to gain.

    Pairing works best when it's a mutual gain, so it's always helpful to bring something to the table.  Sometimes, all you bring to the table is appreciation for their amazing skill, and sometimes that is enough.

    Another great pattern for pairing is if you are a "starter" -- you like to start things, but you aren't a strong "finisher."  A strong "starter" and "finisher" pair is like a dynamic duo in action that amplify each other's success.  One's strength is another's weakness, and your goal is to build a mini-team of capabilities over a one-man band.

    It's not just effective, it's strategic.  By doing what you do best, and supplementing where you are not, you maximize your ability to make things happen in the most effective way, while staying true to you.

    In 30 Days of Getting Results, you can use the time management exercises to be a more effective starter or finisher and get exponential results on a daily and weekly basis.  You can also find more time management tips in my book, Getting Results the Agile Way, and on Getting Results.com

    You Might Also Like

Page 41 of 46 (1,140 items) «3940414243»