- Now Available: Final PDF of the Microsoft Application Architecture Guide, Second Edition
-
A final PDF is now available for our patterns & practices Application Architecture Guide, second edition. This is our platform playbook for the Microsoft application platform.
Here are the relevant links:
Here are some of my related posts:
- Patterns and Practices for Distributed Teams
-
This post is a summary of my lessons learned from leading distributed teams. I've managed distributed project teams since 2001, spanning the UK, Argentina, India, and other parts of the world. While I preferred having everybody together on site around a whiteboard to simplify and improve communication, flexibility with distributed teams gave me access to the right talent, wherever it may be.
Key Challenges
These are some of the most common challenges I faced:
- Trust
- Time zone differences
- Sharing state
- Changes in direction that have a ripple effect
- Communication overhead
- Keeping everybody on the same page
- Sharing knowledge across the team
- Partitioning work for enough autonomy but to keep checks and balances
- Lack of a whiteboard
Distance didn’t matter as much as differences in time zones. If the time zone differences were too much, it meant a lot more information, knowledge and state had to be packaged up and handed over. However, when you leverage time zone differences, the experience can feel like you carry the baton forward, or, it’s like “The Elves and the Shoemaker,” where you make progress around the clock.
Success Patterns for Distributed Teams
The following success patterns helped improve distributed team effectiveness:
- Forming, storming, norming and performing. The forming, storming, norming and performing lens helps remind everybody to expect that things smooth out over time. It’s a simple maturity model for explaining how a team gels.
- Proxy / On Point. One of the most helpful patterns for cross-site communication is to have somebody act as the proxy or person on point to funnel key communication. This is especially important when their are major time zone differences. The additional patterns, such as the show and tell, and the Monday iterations and daily stand-ups, keep this from being a single point of failure. Instead, it’s a focal point with some accountability when key information needs to be shared across time zones.
- Rhythm of results. Daily, Weekly, and Monthly Results. While the team might ship every two weeks, thinking in terms of daily, weekly, and monthly results helps set the right mindset. It creates a bias for action, and it helps get the kinks out of execution.
- Monday Vision, Daily Outcomes, and Friday Reflection. This is a simple, high-level pattern to drive results each week. The approach is to identify 3 key outcomes for the week, as well as 3 key outcomes each day, and to use Friday for learning and reflecting.
- Stories. By focusing on stories, it makes it easy for everybody on the team to think in terms of end-to-end stories over, features or discipline-focused activities. It’s a great way to balance the customer, technical and business perspectives, as well as help the team converge around common goals.
- Monday Iteration plans. Doing iteration plans on Mondays helps set the goals for the week, as well as include everybody’s input. We keep these to 30 minutes or less. The outcome is the prioritized set of stories for the week.
- Daily stand-ups. Everybody calls in and we go around the team asking 3 questions: 1) what did you get done? 2) what are you getting done today? and 3) where do you need help? We keep these to 10 minutes or less. It sets the pace and prevents getting side-tracked.
- Invoke a teammate. One goal up front is to make it easy for everybody on the team to reach whoever they need in an ad-hoc way. Everybody identifies their preferred email, phone number, Skype account, and instant message information, as well as their main working hours.
- Show and Tell. I use weekly show and tells as a forcing function. It gives people on the team a chance to show off their work. More importantly it’s a simple way to dog food results as well as use the team as a sounding board. It’s one thing to build something, it’s another to show it to other people and get honest feedback.
- Wiki Knowledge Bases (KBs.) Using Wikis helps simplify sharing information. It keeps people from over-engineering and it’s easy to keep updated.
- Experience Step-Throughs. These are simply short slide decks that mock up the experience. Each deck walks through one story or scenario visually. We test the experience with customers, and then we walk through as a team, from a technical perspective. We do this for high-risk stories. See Experience-Driven Development and Experience Step-Throughs.
- Distributed pairing. I’ve found the fastest way to hand over information is to pair people up. Pairing can also help people get unblocked or keep pace. It’s not always obvious who pairs up well, so we test different combinations to find what works best for people. Sometimes it helps to compliment skills. For example, one person might be great technically, while another might be great with customer experience.
- Mentoring and buddies. Helping new people on the team ramp up is a priority. I’ve found the most effective way is to have people pair on things together. For metaphors, we call it either “co-pilot” or a “student-driver” model.
- Email Triage. As simple as it sounds, it’s been helpful to include “triage” in the title of some emails. This tells the team that this email thread may be a drill-down or discussion on a topic. It’s also a quick way for anybody on the team to ask for help, since they may not know who on the team has the answer.
- One mail. This is a simple burn down list. Whenever we’re pushing for a key milestone, it’s helpful to summarize the open work that everybody can see and comment on in a shared way. To do so, we simply send out an email that lists the current open work to the team and everybody chimes in. It helps everybody see a tangible finish line.
- Team project site. It’s important that the team has one place to look for all the shared information. The most important information here is the schedule, the deliverables, status, and any key information related to either the deliverables or the project.
- Lessons Learned. I’m a fan of sharing lessons learned on the team. To bootstrap these, we usually just start an email thread and dump our lessons learned. We then port the lessons into the Wiki for easy reference. We list the lessons as one-liners in the form of “do’s” and “don’ts".” It’s a tickler list that provides a backdrop for richer conversations, dialogues, and discussions.
- Checklists. Checklists for common tasks have been the best and simplest way to share information across the team. They help reduce mistakes and carry lessons forward.
- Best Practices Repository. We store our best practices for each project in a project-level repository. At the end of the project, we port the best practices to a shared repository across projects. This way each project is focused on “best practices,” and these are very specific and detailed. The all up best practices are more generalized to be useful across projects, and as a starting point for new projects.
- Reduce friction in the process. This is a shared goal on the team to get the kinks out of any sticking points in any of the processes. We try to innovate in the process to save cost or time or improve effectiveness. This helps us avoid death by a 1000 paper cuts.
- Video nuggets. We’ve found that sharing short-videos can help share knowledge on the team very quickly. These are throw-away videos, but they help capture a snapshot whenever somebody does research in a particular area.
No single pattern is a silver bullet. Instead, it’s the composition of these patterns and practices that help improve distributed team communication and overall effectiveness.
Tools of the Trade
The following are some common tools of the trade:
- Email. This is helpful for sharing technical details, state, and general asynchronous communication.
- Conference calls. This is important for Monday iterations, daily stand-ups, Show and Tells, and any other team meetings.
- Microsoft Shared view. This is helpful for distributed pairing as well as Show and Tells, so that everybody can see a shared desktop.
- Slides. Slideware is a great way to share visuals and consolidate key information or to demo ideas and concepts.
- Mind Maps. Mind maps are a great way to pair and map out what the team knows about a given topic. We’ve also found them useful for creating Work Breakdown Structures, as a team. This way everybody gets to see the big picture as a simple map.
- Instant Messenger. This is especially helpful for simply knowing when people on the team are around and for ad-hoc synch ups.
- Skype. This has gradually replaced setting up conference calls. In fact, we’ve started having better luck with Skype than conference calls in terms of clarity in some cases.
- Groove. This has been our simplest way to share files instead of email. There are some tricks to learn, but we’ve successfully shared projects of with thousands of files and hundreds of MBs.
What about you? … What have been your best lessons learned when it comes to distributed teamwork?
- Now Available: patterns & practices Application Architecture Book
-
The Microsoft Application Architecture Guide, 2nd edition, is now available on Amazon and should be available on the shelf at your local bookstores soon. The PDF was downloaded ~180,000 times. This is the Microsoft platform playbook for application architecture. You can think of it as a set of blueprints, and as your personal mentor for building common types of applications on the Microsoft platform: mobile, RIA, services, and Web applications.
The backbone of the guide is an information model for the application architecture space. It’s a durable and evolvable map to give you a firm foundation of principles, patterns, and practices that you can overlay the latest technologies. It’s your “tome of know-how.” While it’s not a step-by-step for building specific applications, it is a pragmatic guide for designing your architecture, with quality attributes, key software principles, common patterns, and architectural styles in mind. It’s holistic and focused on the key engineering decisions where you face your highest risks and most important choices.
Key Features of the Book
The book has several compelling features for slicing and dicing the application architecture body of knowledge:
- Canonical Frame. This describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer will be described in terms of its focus, function, capabilities, common design patterns and technologies.
- Application Types. These are canonical application archetypes to illustrate common application types: Mobile, Rich Client, RIA, Services, and Web applications. Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype is mapped to the canonical app frame. They are illustrative of common application types and not comprehensive or definitive.
- Quality attributes. This is a set of qualities and capabilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
- Cross-cutting concerns. This is a common set of categories for hot spots for key engineering decisions: Authentication, Authorization, Caching, Communication, Configuration Management, Exception Management, Logging and Instrumentation, State Management, and Validation.
- Step-by-Step Design Approach.
- Principles, patterns, and practices. Using the application types, canonical frame, and cross-cutting concerns as backdrops, the guide provides an overlay of relevant principles, patterns, and practices.
- Technologies and capabilities. The guide provides an overview and description of the Microsoft custom application development platform and the main technologies and capabilities within it.
Contents at a Glance
The full Microsoft Application Architecture Guide is available for free on MSDN in HTML. This is the contents of the guide at a glance:
Chapters
Appendices
The Team
Here is the team that brought you the guide:
- Core Dev Team: J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
- Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman
- Edit Team - Dennis Rea
- External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan
- Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski
Application Architecture Knowledge Base
The guide was developed in conjunction with our Application Architecture Guide v2.0 Knowledge Base Project. The knowledge base project was used to inform and steer the guide during its development. The Application Architecture Knowledge Base includes a large amount of material that expands on specific topics in the main guide. It also includes draft material from the main guide that is targeted and packaged for more specific audiences, such as the Pocket Guide series.
Key Links at a Glance
Here are the key links at a glance:
- 10 Years at patterns & practices
-
I never imagined I would invest 10 years on the patterns & practices team at Microsoft. Life is short and I always imagined I would spend it across so many more adventures. What surprised me is how much you can grow yourself, and grow the job in the process. While I sometimes wonder about the path not taken, there’s no doubt I’ve built a deep set of capabilities, achievements, and experiences as a direct result of investing my time in patterns & practices. I’ve shared some of my best lessons learned at patterns & practices, as well as my proven practices for individual contributors.
I think my biggest take away lesson is follow your heart, follow the growth, and invest in yourself (mind, heart, body, emotions, career, financial, relationships, and fun.)
Why patterns & practices?
There are lots of reasons why I chose patterns & practices. At the end of the day, it was the people, the values, and the mission.
Our Mission
While we’ve had various flavors of the mission, I like to think of it as …. “Customer success on the Microsoft platform” … or … “Proven practices for the platform.” I had the toughest time explaining to my Aunt what I do, until finally I said, “I help customers put the legos together.” She then said, “ahhh, I get it.”
Goals
In patterns & practices, the goals are simple:
- Simplify the customer experience of building quality solutions on the Microsoft platform.
- Improve the customer value of Microsoft products and technologies through customer connection and solution engineering.
- Grow the professional knowledge and capability of the Microsoft development community.
- Help customers and partners build their LOB (line-of-business) applications and services faster and more predictably than any platform in the world.
Values
In patterns & practices, we value:
- Continuous learning, innovation and improvement - We have a bias toward action (over more planning) and customer engagement and feedback (over more analysis.)
- 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.
- Explicit, transparent, and direct communication with customers and with our team and others in our company.
- Quality over scope - no guidance is better than bad guidance.
Principles
We use the following principles to guide our work:
- Start with the end in mind; think about end to end scenarios and how the products we produce fit in the solution architecture and into the patterns & practices catalog.
- Help the customer succeed with their intent - the results they want to achieve, not just what they are trying to do.
- Find the minimal solution required for a good result and ship it.
- Our tools platforms are assets that expand the types of guidance we can express - use all of what they provide where it naturally fits the scenario.
- Constructive tension between customer needs and Microsoft product and business strategy is expected - when we do our job well, this tension is healthy.
Capabilities, Achievements, and Experience
How do you measure the impact of the time you spend down a given career path? I’ve been looking for an effective lens, and I think it boils down to capabilities, achievements, and experience. It’s the simplest way that I can organize and reflect on where I am, based on where I’ve been. Capabilities are simply my skills. They are the things I’ve learned how to do, from soft skills to technical abilities. Achievements are my results. This includes my impact on Microsoft, the software industry, and customers. I lump my books, patents I filed, and the methodologies I’ve baked into the platform and tools here. In terms of experience, I think of the job roles and activities I’ve had along the way.
Key Themes
I think I can boil my impact and results down into 3 key themes:
- Project management. I drive projects from pitch to ship. I’ve built dream teams that go on amazing adventures to change the world. I’ve consistently shipped projects on time and on budget year over year. I’ve mentored many project managers and PMs at Microsoft to share the best of the best of what I’ve learned about shipping, execution, impact and results in patterns & practices. I’ve had unique experiences here, especially since we adopted Agile practices early on, and I’ve lead distributed teams around the world since 2001. I’ve learned a lot in terms of managing innovation, delivering incremental value, fixing time, while flexing scope, and experience-driven development (my latest thinking on software development.) I think my biggest achievement here was helping shape the patterns & practices catalog, the programs, and the execution. See Writing Books on Time and On Budget.
- Software engineering. I’ve invested the bulk of my time in application life cycle management, process improvement, quality attributes (security, performance, … etc), and application architecture. Most of my talks and writings have been focused on security, performance, and software architecture, but I’ve done a lot more behind the scenes. One of the big things I’ve focused on at Microsoft, is “solution engineering”, which is really about problem solving, while satisficing the user, business, and technology perspectives. I think my biggest achievements here were baking security and performance into the life cycle, and into Visual Studio Team Foundation Server.
- Effectiveness. I’m a fan of continuous improvement. I’m not a productivity junkie though. I’m all about impact and results. I’ve learned from the best of the best around Microsoft. I’ve hunted and gathered patterns and practices for effectiveness over the span of several years. More importantly, I’ve bounced the ideas and techniques against reality to see what sticks. In the last few years, I’ve regularly carried 8 mentees. I’ve given talks to our X-Box team on productivity and results systems. Effectiveness is an art and science, and I’m trying to bridge the gap between state of the art and state of the practice. See 7 Habits of Highly Effective PMs and Effectiveness Post Roundup.
Years at a Glance
I think browsing by years is a healthy reality check against impact over time. Looking back is the simplest way for me to respond to the question, “if I had it to do over again, what would I do differently?” Where there answer is “nothing” – those are the sweet spots. Where the answer is “everything” – those are the lessons :)
| Year | Results |
| 2009 | Books - Application Architecture Guide 2.0
Projects - Azure Security Guidance Project
- Core Systems Information Model
- Cloud Architecture Scenarios
- Customer-Connected Engineering
- Productivity coach for the Xbox team.
|
| 2008 | Books - Improving Web Services Security
Projects - Line-of-Business (LOB) Frame
- Catalog Sweep
- Visual Studio Add-In for Guidance Explorer
|
| 2007 | Books - Performance Testing Guidance for Web Applications
- Team Development with Visual Studio Team Foundation Server
|
| 2006 | - 8 patents filed (Security, performance, and info models for software life cycles and application life cycle management.)
Projects - ASP.NET Security RI (Reference Implementation)
- Competitive Assessment for Security Engineering
- Defending Your Code
- Guidance Explorer
- PDL (Performance Development Life Cycle)
- Practices Checker
- Scenario Evaluation Framework
- Security Case Studies
- Security Code Examples
- Security Toolbar
|
| 2005 | Books - Security Engineering Explained
Projects - Security Engineering in VSTS
- Threat Modeling Web Applications
- Whidbey Security Guidance
|
| 2004 | Books - Improving .NET Application Performance and Scalability
|
| 2003 | Books - Improving Web Application Security
|
| 2002 | Books - Building Secure ASP.NET Applications
|
Books
My books at a glance:
Pocket Guides
My pocket guides at a glance:
- Agile Architecture Method Pocket Guide
- Mobile Architecture Pocket Guide
- Performance Pocket Guide
- RIA Architecture Pocket Guide
- Rich Client Architecture Pocket Guide
- Security Pocket Guide
- Service Architecture Pocket Guide
- Web Architecture Pocket Guide
Projects
My projects at a glance:
- Application Architecture Guide 2.0 – A guide, knowledge base, information model and methodologies for the Microsoft platform.
- ASP.NET Security Reference Implementation - Sample application for ASP.NET 2.0.
- Building Secure ASP.NET Applications – A guide for designing authentication and authorization and end-to-end applications scenarios.
- Catalog Sweep – Information model for organizing the complete patterns & practices catalog of code and content assets.
- Customer Connected Engineering – Methodology for engaging customers throughout the life cycle (“patterns & practices secret sauce.”)
- Defending Your Code – An online knowledge base for software security.
- Guidance Explorer – An online knowledge base for prescriptive guidance ("ITunes for knowledge.")
- Improving .NET Application Performance and Scalability – A guide and methodology for baking performance into the life cycle.
- Improving Web Application Security – A guide for threats, attacks, vulnerabilities and countermeasures for LOB applications.
- Improving Web Services Security – A guide for threats, attacks, vulnerabilities and countermeasures for Web services.
- Performance Testing Guidance for Web Applications – A guide and testing methodology for testing Web application performance.
- PDL (Performance Development Life Cycle) – Methodology, activities and artifacts for baking performance into the life cycle.
- Practices Checker – An application that checks software against patterns & practices recommendations.
- Scenario Evaluation Framework – Assessment technique for design, implementation and deployment “building codes.”
- Security Case Studies – A model and examples for sharing business impact from patterns & practices security guidance.
- Security Code Examples – 60 security code examples in VB.NET / C#.
- Security Engineering Explained – A guide and methodology for baking security into the life cycle.
- Security Engineering in VSTS – Baked security engineering into VSTS / MSF.
- Security Information Model – A unified model for Microsoft’s security guidance.
- Security Toolbar – A toolbar for browsing patterns & practices guidance from Visual Studio.
- Threat Modeling Web Applications – A technique to identify relevant threats and vulnerabilities for your scenario to help you shape your application's security design.
- Visual Studio Add-In for Guidance Explorer – Find, create, and share prescriptive guidance inside Visual Studio.
- Whidbey Security Guidance – A collection of guidelines, checklists, and step-by-step how tos for improving software security based on the .NET Framework 2.0.
Where do we go from here? You write your future a page at a time. If there’s one thing I’ve learned, it’s continue to reinvent yourself, reinvent your job, and make the most of what you’ve got.
My Related Posts
- Security Mental Model for Azure
-
We’ve been exploring Azure on the patterns & practices team for potential security guidance. To get our heads around it, we’ve had to create a simple view for our team that we could quickly whiteboard or drill into. We wanted a way to easily compare with our previous security guidance. Here’s what we ended up with …
Today’s application security mental model …
Compare that to our evolving security mental model for Azure …
The key thing to note is that on Azure you have a managed infrastructure, but you still have to address application security issues, as you would in today’s on-premise scenario. There are obviously more details to the story, but I’ll elaborate on those another day. For now, the key is to simply notice how you can carry forward your application security skills to the cloud as a new deployment channel.
- Experience-Driven Development
-
Features don’t necessarily aggregate up to “experiences” and I would argue that today’s winning approach is …
… Experience-Driven Development
… Where experience means user’s can perform their goals successfully… the software makes them feel good and succeed at their goals. It’s an integration of scenarios + experiences … and persona-based scenarios with goals.
This shifts the focus to lighting up experiences over just shipping features or scenarios. It also means a focus on “Experience Step-Throughs” to model and prioritize what you ship. It seems like today’s software success is about shipping the vital few experiences that make an impact. I know it seems like a subtle shift, but I still come across too many glitches that get in the way of great software … … I think we need “experience-first” … or more “experience-driven.”
Experiences are the differentiator ... you can have scenario parity or feature parity, yet miss the boat on experience. It's beyond user stories and scenarios with acceptance tests (though that's a good start.) It's about measuring efficiency and effectiveness of the user experience.
- The Power of Patterns and Practices
-
I wrote a post, The Power of Patterns and Practices, on Sources of Insight to summarize some of the benefits of using patterns and practices as a way to organize and share knowledge. For simplicity, I think of patterns as a way to share problem and solution pairs in context. I think of practices as a way to share methods or techniques. When you combine them, you effectively have an efficient way to share strategies and approaches for success in a given domain.
While sharing patterns and practices has been effective in software, I think other industries can gain from finding ways to more effectively share patterns and practices. Christopher Alexander, father of the pattern language movement, set a great example by creating a catalog of patterns for towns, buildings, and construction in the architecture space. Along those lines, Michael Michalko, a former Disney imagineer, put together an amazing catalog of patterns and practices for creative thinking, in his book, THINKERTOYS. The meta-point is that when you frame and name things, you simplify sharing knowledge in a meaningful and scalable way.
- Sources of Insight is One Year Old
-
It was a year ago today that I wrote my first post on Sources of Insight, where I focus on patterns and practices for effectiveness and skilled living. I wrote up my learnings and highlights in my post, Sources of Insight is One Year Old. My goal with Sources of Insight is to scale myself and to share my lessons learned in effectiveness more broadly. The key theme on Sources of Insight is, “stand on the shoulders of giants!” and I draw from books, people, and quotes , as well as my own experience leading projects, building teams, and writing prescriptive guidance at Microsoft.
I’m a big believer in skills as a way to level the playing field and give everybody a chance at their best life. Sources of Insight is my main clearing house for insight and action for work and life. This way, I can focus my MSDN blog more on my adventures at Microsoft, including my project information, and technical insights. I mentor a lot of people at work, so Sources of Insight is also a way for me to consolidate and share knowledge, while turning it into reusable nuggets. I like to think of it as gems of insight, a post at a time.
- Time Management Quotes
-
Time management is a key skill for work and life. I’ve posted my collection of Time Management Quotes on Sources of Insight. While organizing my collection of quotes, I got clarity on a handful of lessons for time management:
- Time is what you make of it.
- You don’t have time, you make it.
- It’s your most valuable resource.
- Invest time. Investing in your time is investing in your life.
- Don’t dwell on the train you missed. Catch the next train.
- Time changes what’s important. You can’t buy time.
- Time is all we have.
- Time is a teacher.
- Time is a judge.
- Time is a healer.
- Time is a friend.
- Cloud Security Frame
-
I posted a draft of our Cloud Security Frame at Shaping Software. This frame is especially important because we’re using it to help us map out the Cloud security space for our patterns & practices Cloud Security Guidance project. It’s helps us scope our project. The frame is basically a set of Hot Spots. We use the Hot Spots to find, organize, and share principles, patterns, and practices. We also use the Hot Spots to find pain points and opportunity or to organize key engineering decisions. Here is our current set of Hot Spots:
- Auditing and Logging
- Authentication
- Authorization
- Communication
- Configuration Management
- Cryptography
- Exception Management
- Sensitive Data
- Session Management
- Validation
In this case, since it’s a security frame, we’re using the Hot Spots to organize threats, attacks, vulnerabilities and countermeasures. This helps make the information more actionable and relevant. We’re sharing this early and often so that you can give feedback and help us shape it as we go.
If you’re familiar with any of the following guides, this Hot Spot approach should look familiar:
Check out our evolving Cloud Security Frame and provide your feedback in the comments.
- What’s Your Favorite Thinking Technique?
-
Have you thought about your default thinking patterns? I wrote a post on 3 Thinking Techniques to Improve Your Intellectual Horsepower at Sources of Insight. I use these 3 techniques fairly regularly. If you think about thinking as simply asking and answering questions, then improving your questions, can improve your answers. That’s the power of these 3 techniques; they are simple ways to improve your questions to improve you results.
What’s your favorite thinking technique?
- Cloud Security Survey Results
-
As a follow up to our earlier patterns & practices Cloud Security Survey, here is a quick summary of the results. Note that the the bulk of our respondents said they spend most of their time in architect roles. The next biggest buckets were developers and testers.
Key Take Aways
Here are some highlights from the survey:
- As far as cloud adoption, there is fairly even spread in adoption from evaluation to testing to engaged migrations, with a slightly heavier emphasis on testing.
- There is significant interest in data handling within the cloud, such as confining data to geographic regions.
- There is significant interest in infrastructure and process related security issues such as SLA’s, policies, and intellectual property.
- There is significant interest in threats and countermeasures.
- There is some interest in OpenID as an authentication / authorization approach.
- There is some interest in ingress/IP filtering.
- There is some interest in eDiscovery.
- There is some interest in HIPPA.
App Scenarios in Rank Order
Here are the top application scenarios in rank order based on respondents:
- A cloud-based service used by different Enterprises (federated scenario).
- An internet facing web application, deployed on the cloud.
- An enterprise specific web application, deployed on the cloud.
- An enterprise specific web application, deployed on premises using cloud-based services.
- An enterprise specific web application, deployed on-premises using cloud-based services and cloud storage.
Authentication in Rank Order
Here is are the top authentication mechanisms in rank order based on respondents:
- Windows Authentication
- Forms Authentication
- Cert Authentication
- Windows Live
I think one of the most interesting things we've done as a result of the survey is we started to collect and organize relevant industry standards. We'll try to find any relevant technical intersections (our focus is on technical guidance.)
- Communication Isn’t the Only Source of Conflict
-
I wrote a post on how Poor Communication isn’t the Source of Most Conflicts at Sources of Insight. The gist is this: rather than blame communication as the source of conflict, explore other sources as well. For example, conflict can also stem from how your group is organized, to personality conflicts, or conflicts in values. When you know what the source is, you can use the right tool for the job.
- patterns & practices Assets Survey
-
If you take our patterns & practices satisfaction survey, you can let us know which patterns & practices assets you use and how satisfied you are with the assets, as well as how satisfied you are with overall patterns & practices results.
To browse patterns & practices, here are some key links:
patterns & practices Catalog
For easy reference, I’ve shared a simplified view of how I look at our patterns & practices catalog:
| Category | Items |
| Enterprise Library | Enterprise Library |
| Blocks | |
| Factories | |
| Guides | Architecture Deployment / Production Development Performance Security Testing |
| Patterns | |
| Reference Implementations | |
My Related Posts
- A Language for Your Strengths
-
I wrote a post on A Language for Strengths on Sources of Insight. It's my attempt to consolidate and share the best information I've found for learning and talking about strengths and talents. I'm a big believer in focusing on your strengths. I know that when I spend more time in my strengths, I have more energy, I get more done, and I improve my impact. It's about giving my best where I have my best to give. It sounds simple and obvious, yet, before I had a lens for strengths and talents it was more hit or miss. Now, I can more effectively zoom in on my strengths because I have a vocabulary for them.
As I've been helping people find jobs, write their resumes, find their passions, and unleash their best, I've been relying heavily on first helping them find their natural strengths and talents. This gives them the drive and the staying power to deal with whatever life throws at them, as well as gives them a competitive edge. The key in today's landscape, is to bring your unique combination of strengths to the table. I think that while it's a skills-for-hire economy for the short-term, it's a play-to-your-strengths life for the long term.
To learn the map of the 34 strengths and get started on your strengths quest, read my post, A Language for Strengths.
