Many organizations today strive to establish autonomous development teams who can move as independently of each other as possible. The goal is to achieve speed, scalability, and empowerment. The bigger you get, the less central decision making will work, because a central group just cannot know enough to make good decisions.
You have to decide what architecture governance looks like in such a decentralized setup and how to avoid chaos. And you have to know how to walk the line between hard rules and helpful guidance. One way to create a shared understanding of what architecture means in your particular organization is to introduce architecture principles and use them to guide all the teams’ decision making toward common goals.
The presentation explores different ways of creating and phrasing principles, outlines what you need in place around principles to make them practical and effective, and some lessons from a few organizations where I've seen principles in action.
birgitta410
oracle4engineer
mosa_siru
hokaccha
kazuhitotakahashi
dahatake
sajikix
akiroom
utam0k
codenote
.jpg){kind=avatar}
oshanqq
i35_267
is_ryo
bermonpainter
tammielis
shpigford
chriscoyier
geoffreycrofte
wjessup
malarkey
chrisshort
schacon
dougneiner
mraible