Presentation given at Pamplona Software Craftsmanship 2017 talking about the things that influence the architecture like our relation with business, deadlines, deploying to production and organisational design.
5. Architecture is the decisions 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
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
19. CONWAY’S LAW
19
“organizations which
design systems ... are
constrained to produce
designs which are copies
of the communication
structures of these
organizations”
Mel Conway, 1968
20. We find strong evidence 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
26. TYPES OF SOFTWARE MONOLITHS
■ 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
■ Business domain bounded context
■ Regulatory compliance
■ Change cadence
■ Technology
■ Risk
■ Performance isolation
■ User personas
■ Team location
■Customer responsiveness
27
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
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.
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.
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á.
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.
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.
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
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
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
Otro recurso interesante es el booklet de Nick Tune sobre las prácticas estratégicas de DDD.
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.
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.
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
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
Alguien sabe quien es este hombre? Mel Conway.
Esto quiere decir que si en nuestra organización tenemos este organigrama.
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.
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?
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.
Y es importante hacer este estudio y este esfuerzo.
Historia skills funding agency?
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.
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.
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.
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.