This is take two of the presentation, some things added, some removed, but still the regurgitation is best..
The purpose is to raise your awareness of software architecture in light of modern day agile development. Disciplines to incorporate and reconsider
Project Based Learning (A.I).pptx detail explanation
Modern software architect post the agile wave
1. The modern architect
“A Pragmatic View from the Trenches” -
Niels Bech Nielsen
Pragmatic Engineer
2. Services
Liv og Pension
Digital Selvbetjening
Professional Service
Projekter
Application Management
Arkitektur
Sikkerhed
Open Source
3. 3
Disclaimer
• These slides do not tell the story, they are a natural
supplement to a vivid regurgitation, that is my real
presentation
• Read them at will, but expect the real story to be better
• Contact me, if you really want the truth
if you CAN handle the truth
4. 4
One definition
• ”Software Architect is a computer manager who makes
high-level design choices and dictates technical
standards, including software coding standards, tools and
platforms”
5. 5
One definition
• ”Software Architect is a computer manager who makes
high-level design choices and dictates technical
standards, including software coding standards, tools
and platforms”
6. 6
Main Responsibility
• Limiting choices available during development by
Choosing a standard way of development
Creating, defining or choosing a framework for the application
• Recognizing potential reuse by
Observe and understand the broader system environment
Creating component design
Having knowledge of other applications in the organisation
• Subdivide a complex application into manageable entities
Grasp the functionality of each component within the application
Understand the component interactions and dependencies
• Communicate these concepts to developers
10. 10
Agile
That is, while there is value in the items on the right,
we value the items on the left more
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have to come to value
14. 14
Irrespectively of scale
• Cross-cutting concerns such as logging and exception handling
• Security; including authentication, authorisation and
confidentiality of sensitive data
• Performance, scalability, availability and other quality
attributes
• Audit and other regulatory requirements
• Real-world constraints of the environment
• Interoperability/integration with other software systems
• Operational, support and maintenance requirements
• Consistency of structure and approach to solving problems
• Implementing features across the codebase
• Evaluating that the foundations you’re building will allow
you to deliver what you set out to deliver
16. 16
Time, Leading to..?
• Software Entropy receives no focus
as a system is modified, its disorder, or entropy, always increases. This is
known as software entropy
When a program is modified, its complexity will increase, provided that one
does not actively work against this.
• Technical Debt increases
a neologistic metaphor referring to the eventual consequences of poor
software architecture and software development within a codebase.
Technical Debt will increase until eventually only rewrite is possible
• Tribal Knowledge is not Internalized
Tribal Knowledge or Know-How is the collective wisdom of the organization.
It is the sum of all the knowledge and capabilities of all the people.
Knowledge must be transferred or else behaviour is duplicated or forgotten
• Who is around the agile project to identify reuse and manage
complexity?
18. 18
What IF
• ”Software Architect is a computer manager who makes
high-level design choices and dictates technical
standards, including software coding standards, tools and
platforms”
• ”Software Architect is a techo polymath* who offers
high-level design choices and and facilitates best
technical practises, including software coding standards,
tools and platforms”
*) A polymath is a person whose expertise spans a significant
number of different subject areas
19. 19
Main Responsibilities
• Technical Leadership of the product
Set the standards for development
Provide high-level design practises
Ensure best practise and communicate these
Minimize software entropy and increase product quality
Ensure that the architecture is sufficiently documented
• Enterprise collaborator and networker
Identify and support re-use
Collaborate with enterprise architects to incorporate cross-
cutting concerns
21. 22
Up-Front Project Planning
Structure
Understand the
significant structural
elements and how they
fit together based on
the architectural drivers
Design and
Decomposition down to
containers and
components
Risk
Identify and mitigate the
highest priority risk
Risk-storming and
concrete experiments
Vision
Create and
communicate a vision
for the team to work
with
Context, container and
component diagrams
Just enough up front design to create firm foundations for the
software product and its delivery
22. 24
In the face of Continuous Delivery
• Set the technology stack
• Control the build process
• Be responsible for deployment
• May be handled by the Build Engineer
23. 25
Shifting the focus
• Focus for an application architect in the presence of
working software must be to facilitate the team to make
the best decisions and help provide the best possible
platform for further extension
24. 26
Setting the standards versus templating
Examplification
An architect must often forefront
the development and provide an
initial implementation of the
framework in which the software
will be developed
25. 27
Setting the standards versus templating
Copy and Paste
However, the architect should be
aware that not everybody can see
the aesthetics and evolve from
there.
28. 30
Stack Overflow
I need to send multiple requests to many different web services and receive the results. The
problem is that, if I send the requests one by one it takes so long as I need to send and
process all individually.
I am wondering how I can send all the requests at once and receive the results.
29. 31
Top 3 Ludicrous Answers
• It has got various option to develop this:
JMS : quality of service and management, e.g. redelivery
attempt, dead message queue, load management, scalability,
clustering, monitoring, etc.
Simply using the Observer pattern for this. For more details
OODesign and How to solve produce and consumer follow this
Kodelog
• Looking at the problem, you need to integrate your
application with 10+ different webservices. While making
all the calls asynchronous. This can be done easily with
Apache Camel.
• You can ask your jax-ws implementation to generate
asynchronous bindings for the web service.
30. 32
Availability
• A software architect must have enough time and interest
to answer all questions from teams and individuals
• A software architect must facilitate learning and
mentoring
• A software architect must communicate shared models
and shared visions
• By having high developer interaction the software
architect can
Identify re-use and componentization
Increase awareness of cross-cutting concerns
31. 33
Quality Assurance
• Code Review is a systematic examination of computer
source code. It is intended to find and fix mistakes
overlooked in the initial development phase improving
both the overall quality of software and the developers’
skills.
• Automatic as well as manual intervention
Automatic testing
Automatic software analysis
Peer review
32. 34
Automatic Testing
• Accepted curse of unit testing
Documentation
Regression
Works best on loose coupled entities
• Focus on Integration testing
End to end scenario support
Ensure that Input leads to Output
Helped by virtualization and continuous deployments
Watch out for maintenance costs
33. 35
Automatic Software Verification
• Perform automatic analysis of source code and binaries
Tools such as PMD, Checkstyle, Findbugs, jdepend, classycle,
Emma, Cobertura, Pathfinder, ThreadSafe, Macker, clirr,
Tattletale (for Java development)
Or collective in reporting systems such as SonarQube, QALab or
Xradar
• Important to apply qualified analysis on top of the result
34. 36
Peer Review
• Formal or informal collaborate effort of cross-
examination of source code
• Review improve quality by
Rejecting or improving commits
Committers and reviewers learn from each other
Motivation to do boring tasks
• But can also improve overall morale and team coherence
• Important to keep an open culture and avoid blame
game
For any software team not already doing so, the single most effective thing
It can do to improve product quality is to introduce a code review process
35. 37
The Code doesn’t Tell the Whole Story
• Code may hint at
(Functionality)
Programming language
Architectural tiers
Naming standards
Patterns and idioms
• But even those hints may be misinterpreted
• Code may not reveal
Why the technologies were chosen
The overall structure of the system
Whether any common patterns or principles are used
How and where to add new functionality
How security, stability, scalability, etc is achieved
43. 45
Documenting Architecture
• Documentation is not hard
• Briefly outline technologies and choices
Keep the stories short and to the point
Create simplified diagrams
• Keep it with the source code under revision control
44. 46
Example 1 - AsciiDoc
• Extremely simple markup, integrates with builds
<profile>
<!-- ========================================================================= -->
<!-- Include a documentation profile if the project have src/main/asciidoc -->
<!-- Adds a process-asciidoc goal to the generate-resources phase -->
<!-- ========================================================================= -->
<id>fdc-documentation-profile</id>
<activation>
<file><exists>${basedir}/src/main/asciidoc</exists> </file>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<configuration>
<backend>html</backend>
<outputDirectory>${project.build.directory}/docs</outputDirectory>
<sourceHighlighter>coderay</sourceHighlighter>
</configuration>
</plugin>
</plugins>
</build>
</profile>
Ex
46. 48
Example 3 - Violet
• Simple tools for structural diagrams
47. 49
Are you responsive?
• All changes to a software product must be reversible
Deployments fail for many reasons outwith control, making this
a real risk in any software project
However the risk is easy to avert by proper rollback mechanisms
• Projects are no longer static, and must be palpable by
engineering staff and newcomers
Especially when projects are signed off
• Ask yourself these questions
How long time does it take to check-out the software,
circumvent a simple problem and re-release your product to
production environment?
How long time does it take to integrate a new developer with a
workable developer environment?
48. 50
In total
• Always start from an enterprise foundation
• Engage in Just Enough Up-Front Design
• Set the standards and the builds
• Evolve the documentation
• Master Code Reviews
• Be the go-to guy
• Be responsible for the product artefact
49. 51
Q (+A?)
I left the murky, bedraggled streets of home to venture on a
Journey for a thousand miles and more.
I had a vision and a purpose and everything around me sprang to life
In a newfound thrill of excitement.
Arriving at my final destination I saw wonders beyond compare and such
Joy and such life that everything fell into place and harmony.
How can this be of wonder, you ask, when I reveal the final destination
As the origins of my journey. But alas, everything old can be born again
From a new perspective
Editor's Notes
Hvordan forholder en sådan kommandostruktur sig til matrixorganisation
Agile practices of refactoring, unit-testing and continuous deployment
Scrum master er en sekretærstilling som går på omgang. Der står ikke team captain på trøjen
Spørg snehvides stedmor hvad et spejl kan bruges til.
Hvem ejer cross-cutting concerns (i projektet, på tværs af aprojekter)
Neologistisk = new to-be common term… What’s important is..
A polymath is a person whose expertise spans a significant number of different subject areas
Overordnet IT strategi er vigtig for drift og vedligeholdelse, mens forretningskrav kan være af højere prioritet
En arkitekt, som ikke er en go-to guy er ikke god nok
Manden bad ikke om asynkron kommunikation, men parallel over sekventielt
Classycle is a nice little utility for checking your internal Java program architecture. It can find cycles and can also check conformance with an architecture definition.
Java Pathfinder (JPF) is a system to verify executable Java bytecode programs Its primary application has been Model checking of concurrent programs, to find defects such as data races and deadlocks.
Macker is a build-time architectural rule checking utility
Clirr is a tool that checks Java libraries for binary and source compatibility with older releases.
Tattletale is a tool that can help you get an overview of the project you are working on or a product that you depend on
Raise your hand when you recognize the place, and add the most precise label to it.