Microservices: Settling Architecture vs Design Debate

It is an old religious war in software industry. Where does Software Design end and Software Architecture start ?  My answer to that question is - boundary that separates a microservice from the things outside of it from the stuff inside it. Inside a micro service we need Design, outside of micro service we need Architecture.

What is Software Architecture?

The wikipedia definition captures the essence of what Software Architecture is. I take liberty to re-iterpret it a little bit.  

Software Architecture is the set of structures needed to reason about the software system. Each structure comprises software elements (aka Micro-service), relations among them, and properties of both elements and relations.

Software architecture choices include specific structural options from possibilities in the design of software. Software architecture is about making fundamental structural choices which are costly to change once implemented.  

Martin Fowler defines the architecture in an interesting way. "The important stuff—whatever that is".  

ISO/IEC/IEEE 42010 defines it as "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution"

Architecture vs Design

• Architecture is defining the interactions and contracts of a micro service with the rest of the system. Design is making implementation choices (like internal OO Design, data structures and algorithms.) Your Architecture involves figuring out what micro services you need. Defining data they communicate and store. Details of database design, choice of MVC framework is Design.   
• Architecture is strategic , Design is tactical. Making trade-offs around consistency and availability is Architecture. Making space/time tradeoffs or  deciding to precompute partial results or choosing a caching mechanism is then all part of the Design. 
• Design is concerned with local issues, Architecture is concerned with global issues. We can change our Design without asking anyone else. (Eg. Change data structure, algorithm or refactor OO Model). To change Architecture we need to communicate it to others and the change has ripple effect. 
• Design is executable. Architecture is not.

Discovering and Defining Microservices

There are two steps to discovering the Microservices 

1. User Story Mapping

Input : Our starting point is scenario or epic. A user has a concrete need in mind and a task to accomplish. User does that by interacting with our system through series of actions. Input to our architectural discovery process is long list of user stories. 

Activity: We group related stories into the clusters.  These clusters indicate the underlying feature or "capability" that the system must provide.

Output: Each feature or capability is potentially a micro-service. (Prune the list as required.) 

2. Component-Responsibility-Collaboration Cards

Input : List of microservices, list of user stories.

Activity:

1. For each micro service create a card with two sections Responsibility and Collaboration. 
2. Responsibility section includes (a)  What do I know ? (b) What do I do? (c) What do I decide ?
3. In Collaboration section include (a) Who do I interact with? (b) What data I exchange with others? 
4. For each major user story walk through the micro services and in the process assigning responsibilities to them and discovering collaborations and details of those interactions.

Output:  Well defined set of micro-services with clear responsibilities and identified interaction with collaborators.

References:

• The New User Story Backlog is a Map http://jpattonassociates.com/the-new-backlog/
• Creating an Agile Road Map Using Story Mapping https://www.scrumalliance.org/community/articles/2013/august/creating-an-agile-roadmap-using-story-mapping