Governance – distributed v central
This page is
published under the terms of the licence summarized in the footnote.
Martin suggests a software development team should be 1 to 12 people.
I believe that to be normal, even in projects develop a single large app.
Separation of responsibilities is fine when the micro apps are natural silos.
Where integration is needed, who is responsible for these cross-app elements
What if one end-user app depends on many separately deployed micro apps?
Who is responsible for the whole app? Who understands what it takes to deploy the whole?
Martin likes to quote Conway’s law (Melvyn Conway, 1967):
“Any organization that designs a system
will produce a design whose structure is a copy of the organization's
communication structure.”
The law sounds profound, but is actually rather trite, and note the Bennett-Berrisford corollary to Conway’s law.
"People naturally coalesce
into work groups that optimise their system of interest, and
de-optimise any wider system of which their local system is a part".
Our papers on microservices and micro apps have pointed out that modularisation and decoupling tends to:
· increase work to integrate modules
· increase work to meet non-functional requirements
· increase work to address data disintegrity
· complicate design for failure.
· distribute responsibility for integration
So any discussion of microservices must include some consideration of how to address these costs and complications.
What if my one micro app is required and depended on by many user interface apps?
Who is responsible for deciding what requirements I respond to? Who pays for my work?
If micro apps are logically coupled, then they must be coupled one way or another.
A macro app may well prove the best solution in some cases.
And in other cases, there is a need for centralised governance of some kind.
Micro apps are related to the agile development and dev/ops movements.
Agile development strives to optimise the use of the brain power in a small team.
The team is expected to hold the configuration and dependencies of a small system in their heads, preferring informal knowledge sharing to formalised document exchange.
The dev/ops movement recommends one team takes responsibility for everything from business requirements to operational support.
Both movements encourage employment of human resources dedicated to a system over the long term, even during periods of little or no system change.
They can undermine enterprise architecture ambitions by optimising micro systems at the expense of macro systems.
The bigger/wider picture is a complex mesh of trade-offs between options.
There are choices to be made between:
· local agility and wider integrity
· micro databases and macro databases
· silo apps in different clouds and enterprise system integration.
· employing people dedicated to a system or people who move from project to project.
A challenge is to assess the trade-offs in each circumstance and make the optimal decisions, rather than follow fashion.
The modularisation of a macro app into micro apps is a high-level design decision.
The distribution of micro apps to devices and to teams are high-level design decisions.
How to integrate micro apps is a high-level design decision.
Modularisation and
decoupling within one enterprise creates the need for a high-level architect
role.
And by the way: Do Amazon and Google provide a good model for all enterprise apps?
An app to handle 100,000 tps surely requires special design patterns.
There must be massive scaling out, complex and power-hungry replication processes.
The same app handling 1,000 tps can be built to a far simpler and cheaper design pattern.
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0 12/04/2015 21:02
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org