The document outlines the roles and responsibilities of various types of architects in software development, including application architects, solution architects, and enterprise architects. It describes their tasks related to project structure, technology organization, and ensuring application performance and security. Additionally, it discusses architectural patterns such as microservices and event-driven designs, highlighting their pros and cons.

1. www.eleven-labs.com
SOFTWARE
ARCHITECTURE
@vcomposieux
… all you need to know
Vincent Composieux

2. WE WILL NOT TALK ABOUT

3. In computer engineering, computer
architecture is a set of rules and methods that
describe the functionality, organization, and
implementation of computer systems.
WIKIPEDIA
SAYS
“
”
DEFINITION

4. PROJECT TEAM
TECH LEAD
BUSINESS TEAM
ENGINEERS
OPS TEAM
ARCHITECTS
ENGINEERS
PRODUCT
OWNER
SERVICES
TALK
TO EVERYONE
ARCHITECT
BRINGS
ANSWERS TO QUESTIONS
WHAT IS ITS POSITION?

5. START ONGOING RESEARCHNEXT
AUDIT / FOLLOWDEFINE PREPARE
DOCUMENT
COMMUNICATE
DOCUMENT
COMMUNICATE
DOCUMENT
COMMUNICATE
PROJECTS
WORKFLOW
Present at all key moments of a
project.
WHAT IS ITS JOB EVERYDAY?

6. APPLICATION
ARCHITECT
Specialist on a specific
technology. Knows how to
develop and deploy the app
SOLUTION
ARCHITECT
Practices multiple
technologies. Knows how
to organize complex apps
ENTERPRISE
ARCHITECT
Has a strong experience on
organizing multiple
applications into an
information system.
DIFFERENT JOBS

7. APPLICATION
ARCHITECT

8. ORGANIZE
A SPECIFIC TECHNOLOGY PROJECT STRUCTURE
APPLICATION ARCHITECT

9. DEFINE
STANDARDS
PROCEDURES
Ensure that everyone is able
to understand quickly and
use the application in a
normalized way.
● Define best practices to follow on the project (PHP’S PSRs, Symfony
best practices, etc…),
● Define procedures and tools for project integration (tests), deliver
(deploy) the application,
● Ensure that each developer understand and use the best practices,
● Ensure that there is no issue with procedures.
START ONGOING NEXT
APPLICATION ARCHITECT

10. AUDIT
PERFORMANCE
SECURITY
FIABILITY
Ensure that the application is
running well from develop
environment to production
environment
● Ensure that application can be fully used on develop environment,
● Ensure that pages rendering are fast so there is no slow queries,
● Ensure that there is no security breach,
● Ensure that application is fully available on production.
START ONGOING NEXT
APPLICATION ARCHITECT

11. PREPARE
THE FUTURE
Ensure that application is
well maintained in time and
evolves with new
technologies
● Think about new features and propose an evolution for the
application in order to continue working great,
● Propose ideas to simplify procedures or project architecture when
necessary,
● When technologies evolves, plan and prepare migrations to new
versions
START ONGOING NEXT
APPLICATION ARCHITECT

12. SOLUTION
ARCHITECT

13. ORGANIZE
THE WHOLE PROJECT
SOLUTION ARCHITECT

14. DESIGN
COMPONENTS
EQUIPMENTS
Design whole components
(cross-technologies) that will
compose the architecture of the
application
● Chooses the best technologies and tools for answering the needs of
the application
● Prepares material specifications for running the application on
servers
● Writes and communicate on both software and technical
specifications
START ONGOING NEXT
SOLUTION ARCHITECT

15. ANALYZE
DYSFUNCTIONS
OPTIMIZATIONS
Ensure that the whole
application components are
working properly and search
for optimizations.
● Ensure that there is no issue on all the application components
● Listens for feedbacks from application architect and/or technical
teams
● Investigates on how the whole application can be optimized
(reliability, data exchanges, security, ...)
START ONGOING NEXT
SOLUTION ARCHITECT

16. EVALUATE
THE NEXT STEPS
Ensure that components are
maintained in time and
evolves with new
technologies and needs
● Ensure that components are running in a recent and stable version
● When components evolves, plan and prepare migrations to new
versions
● Think about new features and propose evolutions of the current
architecture if needed (technical and material)
● Propose ideas to optimize/simplify procedures, architecture or costs
START ONGOING NEXT
SOLUTION ARCHITECT

17. ENTERPRISE
ARCHITECT

18. ORGANIZE
THE ENTERPRISE IT PROJECTS
TOGETHER
PROJECT1PROJECT2
PROJECT 3 PROJECT 4
ENTERPRISE ARCHITECT

19. ORGANIZE
INFORMATIONS
TECHNOLOGIES
Organizes whole components,
technologies and tools that
will compose the architecture
of a company
● Responsible of the global architecture cartography,
● Analyzes data exchanges wanted for the targeted
architecture,
● Challenges solutions to answer a need on a business part,
● Evaluates risks and technical impacts of retained solutions
● Takes feedbacks from application/solution architects to
propose solutions on what needs to be optimized
ENTERPRISE ARCHITECT

20. APPLICATION
ARCHITECTURE PATTERNS

21. OBSERVER PATTERN
SERVICE 1
SERVICE 3
EVENT
CONTROLLER
MOVE
LOGIC INTO DEDICATED SERVICES
Notify
Listens
SERVICE 2
Listens
APPLICATION

22. PROS
● Clean design: each things sits as it place
● Easy to understand
● Loose coupling between your publishers and your
subscribers
● Easy to unitarily test: each part is decoupled from
others
● Resilient: in the case a subscriber fails, others
don’t
OBSERVER PATTERN
CONS
● If not used carefully the observer pattern can add
unnecessary complexity
● Accept only one event object: have to couple data
if you want to add extra data

23. HEXAGONAL PATTERN
EXPOSE
SOME INTERFACES TO INTERACT WITH BUSINESS
APPLICATION
BUSINESS CODE
Domain
ADAPTER
ADAPTER
ADAPTER
ADAPTER
PRESENTATION
PERSISTENCE
PostgreSQL
Oracle
Web
App
Mobile
App
WEBSERVICESRest API
SOAP API
OTHER

24. PROS
● Keep your business code free from any service:
just write adapters to interact with them
● Focus on logic: you don’t have to worry how
adapters will work when you code
● Logic stills easy to implement/understand
HEXAGONAL PATTERN
CONS
● Can be seen as more complex from an
architecture point of view
● YAGNI (You Aren’t Gonna Need It): make sure you
really need to have multiple interfaces

25. SOLUTION
ARCHITECTURE PATTERNS

26. MICROSERVICES
SERVICE 1 SERVICE 2 SERVICE 3
API API API
MOBILE
UI
WEB
UI
DECOUPLE
SERVICES BY BUSINESS

27. PROS
● Separated services, developments can be splitted
by business too
● Deploy frequently without impacting the whole
business
● Fine-grained scaling: scale by service
● Independant technology on each service
MICROSERVICES
CONS
● Requires to spend more time on industrialization
and deployment tasks
● Have to deal with resilience in case of
communication fail (circuit breakers, retry,
fallbacks, ...)
● Have to deal with performances degradations
such as network overhead, async, … (polling,
own-service database, data sync, ...)

28. EVENT-DRIVEN
SERVICE 1 SERVICE 2
EVENT
BUS
REACT
TO APPLICATION EVENTS
Publish an event
React to an event
Publish an event
React to an event
DatabaseWEB
UI

29. PROS
● Easy to conceptualize: Events are small and
represent a specific state change
● Each service subscribes to events he wants to
react
● Scalable: any number of consumers can react to
events
EVENT-DRIVEN
CONS
● Potential loss of events/messages/state (network
problems: no one guarantee it)
● Needs to be documented when app growth:
complexity increases

30. MICRO FRONTENDS
WEB UI
INCLUDE
MULTIPLE SEPARATED FRONTEND SERVICES
Frontend
1
Frontend
2
Frontend
3
Back-end
1
Back-end
2
Back-end
3
DB 1 DB 2 DB 3
HTML 5
CustomEvents
Server
Sides
Includes

31. PROS
● Agility: Independent development and
deployment cycles for each service
● Reduces risk of bugs: services scope are
mastered
● Easier to test
MICRO FRONTENDS
CONS
● Complex development environment/integrations
● Third party module overlapping/redundancy
● Initial load time can increase

32. SERVERLESS
SERVICE
MOBILE
UI
WEB
UI
Serverless Provider
AWS Lambda
Google Cloud Functions
Apache OpenWhisk
EXECUTE
DATA PROCESSING
FUNCTION 1 FUNCTION 2
FUNCTION 3 FUNCTION 4
API
Calls
Run
EVENT / SERVICE

33. PROS
● No system administration required
● Reduces costs and is scalable by default
● Reduces the complexity of software by
splitting “jobs”
● Quick to develop: easy to get an “MVP”
(Minimum Viable Product)
SERVERLESS
CONS
● Dependent of provider APIs: cannot change
provider without making significant
changes in your application
● Not compatible with long-running tasks
(time-limited & memory-limited)
● Adds overhead for functions/calls (“cold
start”)

34. PATTERNS
Microservices
Microservices.io: http://microservices.io
Event-driven
The Reactive Manifesto: https://www.reactivemanifesto.org
Micro Frontends
Techniques, strategies and recipes: https://micro-frontends.org
↳ Self-Contained Systems
Independing systems: http://scs-architecture.org
RESOURCES

35. ALWAYS KEEP IN MIND
DATA
EXCHANGE / STORAGE
EXECUTION
TIME
NETWORK
BANDWIDTH / SECURITY
PHYSICAL
RESOURCES
COST

36. ONE MORE THING
KISS
* Keep it simple, stupid
* Keep it stupidly simple
* Keep it simple, silly
* Keep it small and simple
* Keep it sweet and simple
* Keep it simple and straightforward
* Keep it short and simple
* Keep it simple and smart
* Keep it strictly simple
* Keep it speckless and sane
* Keep it super-simple
* Keep it sober and significant
* Keep it short and sweet
* Keep information security simple
* Keep it safe and simple

37. THANK YOU
Happy Architecting

38. Images
https://www.eleven-labs.com
https://www.16personalities.com
CREDITS