Download to read offline
Uploaded byVicenç García-Altés
Architecture, architects and other mythological creatures
The document explores the relationship between architecture and organizational structure, emphasizing that a system's architecture often mirrors the communication structures of the organization that develops it. It discusses various architectural activities, such as domain vision creation and business process mapping, and highlights the importance of aligning business and development efforts. Additionally, it touches on concepts like Conway's Law and the implications of organizational design on system architecture.
More Related Content
Similar to Architecture, architects and other mythological creatures
Architecture, architects and other mythological creatures
- 1.
- 2.
- 3.
- 4. ARCHITECTURES, ARCHITECTS AND OTHER MYTHOLOGICAL CREATURES VicençGarcía Altés @vgaltes vgaltes.com
- 5. Architecture is thedecisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other. 5 Ralph Johnson
- 6. Architecture represents the significantdesign decisions that shape a system, where significance is measured by cost of change. 6 Grady Boock
- 7.
- 8.
- 9.
- 10. ACTIVITIES AND ARTIFACTS ■Domain vision statement creation -> Domain vision statement, List of business capabilities, Glossary ■ Study business roadmap -> List of business capabilities, Glossary ■ Reference scenario mapping -> List of reference scenarios, Glossary ■ Business process flow mapping -> Business process flow map, List of business capabilities, List of domain events, Glossary ■ Exception scenario mapping -> Business process flow map, List of domain events, Glossary ■ System mapping -> High level system diagram, Glossary ■ Context mapping -> Context map, Glossary ■ Domain refactoring -> Subdomain map ■ Domain modeling -> Domain models for each subdomain 10
- 11.
- 12. ACTIVITIES ■ Mission Statement ■Impact Mapping ■Business Model Canvas ■ Domain Use Case Diagrams ■ Event Storming ■ Core Domains Diagram ■ Bounded Context and Autonomy Contexts ■ Context Maps ■ Value Stream Maps ■ Lean Canvas ■ Value Proposition Canvas 12
- 13.
- 14. BMC – DOMAINDISCOVERY 14
- 15. BMC – KEEPBUSINESS IN THE LOOP 15
- 16. BMC – KEEPDEVELOPERS IN THE LOOP 16
- 17.
- 18.
- 19. CONWAY’S LAW 19 “organizations which designsystems ... are constrained to produce designs which are copies of the communication structures of these organizations” Mel Conway, 1968
- 20. We find strongevidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed. 20 MacCormack et al
- 21.
- 22.
- 23. If the architectureof the system and the architecture of the organization are at odds, the architecture of the organization wins. 23 Ruth Malan
- 24. COLLABORATION VS XAS A SERVICE 24 COLLABORATION X AS A SERVICE http://web.devopstopologies.com
- 25.
- 26. TYPES OF SOFTWAREMONOLITHS ■ Application monolith ■ Joined at the DB ■ Monolithic build (rebuild everything) ■ Monolithic releases (release everything) ■ Monolithic model and implementation (attempted consistency across many different contexts) ■ Monolithic thinking (apply same solutions for everything) 26
- 27. FRACTURE PLANES ■ Businessdomain bounded context ■ Regulatory compliance ■ Change cadence ■ Technology ■ Risk ■ Performance isolation ■ User personas ■ Team location ■Customer responsiveness 27
- 28.
- 29.
- 30.
- 31.
- 32. THANK YOU Vicenç GarcíaAltés @vgaltes vgaltes@thoughtworks.com vgaltes.com
Editor's Notes
- #2 305 aC Rodas invadida por Demetrio I de Macedonia -> Poliorcetes, conquistador de ciudades. Pidieron ayuda al dios Helios, protector de la ciudad. Torres de asedio. La primera hundida por una tormenta La segunda en tierra, pero hinundada por los Rodios Ptolomeo envió un ejercito que hizo huir a Poliorcetes Escultura al dios Helios -> Chares de Lindos 2 curiosidades con relacion al desarrollo de software - pasta - terremoto Calatrava
- #3 Cuando hablamos de arquitectura en una organización.. Una gran estructura perfectamente pensada, capacitada para aguantarlo todo, pensada por una mente brillante que lo domina todo.
- #4 Pero la realidad acostumbra a ser muy diferente, lo que nos encontramos es que nuestra arquitectura no vive sola en el mundo. Nuestra arquitectura está rodeada de fuerzas y luchas que la modelan.
- #6 Kevlin Henney A mi esta definición no me acaba de gustar, pq presupone (o eso entiendo yo) que tu proyecto no cambia. Que lo que es válido al final del proyecto era válido al principio. Y eso no tiene que ser así. Tu negocio, con suerte, evolucionará, y la decisión que hoy parece correcta mañana no lo será.
- #7 A mi me gusta mucho más esta otra definición: Si tu aplicación utiliza intensivamente la base de datos, esocoger que tu base de datos será una base de datos relacional o no es una decisión arquitectónica.
- #8 Hablábamos antes de lucha. La primera lucha que hay, y que no debería ser tal, es la que hay entre negocio y desarrollo. los de desarrollo somos para negocio aquellos que lentos que no son capaces de subir nada a producción cuando yo se lo digo, Y en otros muchos casos los de negocio son para los de desarrollo aquellos pesados que no paran de pedir cosas -> nuevo FW de javascript Pero esa dicotomía no es real y es dañina.
- #9 Y es que las decisiones que tomamos desde desarrollo tienen un impacto directo en el negocio. Historia Edu Ferro Carlos Ble -> json en una columna de la tabla relacional
- #10 Pero el impacto también puede ser el contrario. Que una decisión nuestra impacte negativamente en el negocio. Eso se ve mucho cuando en nuestra empresa se desarrolla con lo que se dice la arquitectura orientada al curriculum. Microservices React <- Angular 2 <- Angular 1 <- Emberjs <- Knockout <- jQuery tu web no es el New York times ni Facebook ni actualizas zillones de datos a la vez. Puede cambiar como es el negocio en si. CQRS -> porque puede cambiar como muestro la información a mi usuario y como funciona mi negocio. Greg Young, versionado con Event Sourcing -> Jodido -> cambiar eventos, rediseñar agregados
- #11 Como decíamos, negocio y desarrollo están muy unidos. Están tan unidos, que muchas técnicas que en principio tienen que se aplican cuando se define un negocio son perfectamente aplicables para hablar de arquitectura. El otro dia hablaba con mi sponsor sobre como empezar una arquitectura -> pensar en capabilities
- #12 Otro recurso interesante es el booklet de Nick Tune sobre las prácticas estratégicas de DDD.
- #13 Esta es un resumen de la lista que Nick nombra. Como veis, otra vez, muchas de las actividades son actividades que son pensadas para ser utilizadas desde un punto de vista de negocio, pero que son realmente importantes desde un punto de vista técnico también. Una de las nombradas es el business model canvas.
- #14 El business model canvas es un template que nos ayuda a definir un nuevo nogocio o a describir uno existente. En el podemos encontrar áreas como la proposición de valor, … En la DDDX de este año, Javier Fernández A parte, Javier explicó que el BMC puede tener un mapeo más o menos directo a patrones estratégicos de DDD.
- #18 Si la arquitectura es aquello que pone ciertas limitaciones a nuestra imagincación y eliminar alternativas, nuestra empresa o cliente fija dos limitaciones muy importantes: tiempo y dinero. Las fechas que pone negocio en muchos casos no son arbitrarias, sino que tienen una fuerte razón de ser. Videojuegos -> E3 Historia recarding -> retraso seis meses -> BAU tactical vs strategic El dinero impacta, a parte de en las fechas, en el equipo que se pueda formar. Desarrolladores como una comodity -> NO Indra -> BDD Ahora -> solo seniors -> diversidad
- #19 La primera release de nuestro producto no es el final del proyecto, sino el principio de la vida del software. Diseñamos para QA, sobretodo en consultoria Cada vez más modelo de you build it, you run it Problemas en producción vienen por los non functional requirements -> cross functional requirements Accesibilidad, auditabilidad, compatibilidad estabilidad y capacidad. - History - JustEat
- #20 Alguien sabe quien es este hombre? Mel Conway. Esto quiere decir que si en nuestra organización tenemos este organigrama.
- #21 Esto fue estudiado unos cuantos años más tarde (2012 si no me equivoco) y se certificó de una manera un poco más científica.
- #22 Se puede (y se va a dar) el caso que este señor necesite hablar con este otro para hacer su trabajo. Y que con estos no hable nadie. Esto hará que haya un coste de comunicación añadido brutal, no solo entre personas y equipos sino que, como cada uno hará su componente, entre piezas de software. Por tanto, entregar valor a nuestros clientes será más complicado. Historia Lynk and sync?
- #23 En 2015 y 2016 apareció en el Tech Radar de ThoughtWorks el concepto de la maniobra inversa de Conway. Esto basicamente quiere decir que si sabemos que la arquitectura acaba siguiendo el modelo organizativo de tu empresa, diseña tu empresa de manera que la arquitectura deseada emerja. Por lo tanto aquí el reto está en la manera que tenemos de formar equipos. Pizza teams de Amazon. Equipos en TransferWise (Keyvan Akvary). Squads en Spotify.
- #24 Y es importante hacer este estudio y este esfuerzo. Historia skills funding agency?
- #25 Podemos definir los niveles de colaboración entre equipos de la siguiente manera. Por ejemplo, en nuestro caso, con algún equipo implementando alguna funcionalidad si que tenemos una comunicación más estrecha y nos influimos mutuamente. En otros casos, otros equipos simplemente utilizan nuestra funcionalidad existente. Discovery vs predictability. Puedo consumir esto como un servicio? Puedo yo ser consumido como un servicio. En contact service nos planteamos extender nuestro as a service.
- #26 Una posible separación de los tipos de equipos es la siguiente. Como veis, tenemos cuatro tipos de equipos diferentes: - Product teams: aquellos encargados del desarrollo de una linea de negocio - Platform teams: aquellos encargados de implementar un servicio de infrastructura que otros equipos pueden utilizar, como puede ser los encargados de enviar correos, autenticación, etc. - Productivity teams: aquellos encargados de dar soporte a los equipos para mejorar su productividad, como puede ser equipo de CI, cloud, release, etc. No hacen el trabajo, sino que habilitan a los equipos a hacerlo. (Ultimo artículo de roberto canales). El equipo de SRE que comentó ayer Kini. - Component teams: encargados del desarrollo de un componente muy especifico, como podria ser un reproductor de video, por ejemplo.
- #27 Por lo tanto, el reto aquí será el de partir nuestro monolito (el punto de partida de muchos equipos) en una serie de equipos que puedan aportar el máximo valor posible. Podemos definir un monolito de muchas maneras.
- #28 La primera a tener en cuenta tendría que ser los dominios de negocio. => strategic design de DDD Al final, la más importante es la customer responsiveness. Preferimos un diseño impuro pero que aporte valor antes.