Lessons from Ed On Software Architecture

The beauty of patterns is that the insight is timeless.  I was flipping back through a post on Architecture, Mobiles, and Health: 10 Pitfalls, by Eduardo Jezierski.  Ed is a friend and we worked together for years, first in Microsoft Developer Support, and then in Microsoft patterns & practices.  When Ed shares what's on his mind, he has an uncanny ability to put into word things that you have bumped into or know to be true, or a new lens that you need to look through.

This post is a roundup where I cherry pick my favorite points from his post on his lessons learned.  Many of the points especially resonate because we they ecapsulate and magnify points we learned over time in patterns & practices, as we focused on architecture, viewpoints, scenarios, context, principles, patterns, and antipatterns. 

Key Take Aways on Architectural Approach
Here are my key take aways from Ed’s learnings on software architectural approaches:

• Separate capability from implementation
• Focus on standards as a means for interoperable building blocks, not an end
• Turn end goals, requirements, and capabilities of the system into technology, integration, and infrastructure architectures
• Make sense of the implementation trade-offs between a centralized, top-down vs. decentralized, bottoms-up decision approach
• Create capability maps (a set of boxes with labels and lines that describe common functionality)
• Get performance metrics on each capability on the map to know its effectiveness

Key Take Aways on Architectural Antipatterns
Antipatterns are what not to do, or in the words of Jim Coplien --  "an anti-pattern is something that looks like a good idea, but which backfires badly when applied."  Here are my key take aways from Ed’s learnings on antipatterns:

• “I’ve seen architecture efforts fail because they create blueprints that don’t consider the target context.”
• “I always recommend focusing on proven practices rather than best practices, and evaluating on impact metrics (e.g. birth complications averted) rather than proxy measures such as adoption or usage metrics (‘30 users’) or satisfaction (‘so-and-so is thrilled’).”
• “And don’t be fooled – UML and any specialized notation has been used many times to hide bad thinking behind a veneer of formality. A good architecture effort would communicate in a language and notation that is simple even if not formal. Even better, it would provide a reference architecture and reference implementations as a starting point for common scenarios.”
• “Architecture efforts that rely on heavy top-down prescription are very prone to recommending antipatterns as they don’t have immediate feedback loops.”
• “Creating master data models is a huge temptation amongst folks who have reductionist/mechanist perspectives (and not much enterprise-scale software deployment experience). History has shown that small, flexible standards that can be used together tend to survive longer than larger, holistic standards that cover too much.”
• “The desire to rationalize efforts to save resources can lead to de-duplication initiatives. Reducing duplication can save waste but can also stifle innovation by reducing the chances of discovering new ways of doing things.”
• “Making things user-friendly takes more work, especially in the field. User Experience (UX) design plays a critical role in determining how technology can help the users achieve their goals. Yet I have always been amazed how most enterprise architecture frameworks miss user experience and design (or confuse it with usability and requirements gathering).”
• “A good architecture effort would make sure the outcomes and impact are correctly placed. Standards would be chosen based on how well they fit a problem, and catalogued as an implementation choice.”

These are just my notes and take aways from Ed’s illuminating post.  Ed’s actual post is rich with elaboration and examples, and it connects the dots.  Check out Architecture, Mobiles, and Health: 10 Pitfalls.