modern software architect post the agile wave

Post on 09-May-2015

208 Views

Category:

Software

2 Downloads

Preview:

Click to see full reader

DESCRIPTION

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

TRANSCRIPT

The modern architect “A Pragmatic View from the Trenches” -

Niels Bech NielsenPragmatic Engineer

ServicesLiv og PensionDigital SelvbetjeningProfessional ServiceProjekterApplication ManagementArkitekturSikkerhedOpen Source

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

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

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

Main Responsibility

• Limiting choices available during development byChoosing a standard way of developmentCreating, defining or choosing a framework for the application

• Recognizing potential reuse byObserve and understand the broader system environmentCreating component designHaving knowledge of other applications in the organisation

• Subdivide a complex application into manageable entitiesGrasp the functionality of each component within the applicationUnderstand the component interactions and dependencies

• Communicate these concepts to developers

7

Enterprise Architectural Growth

Startup/Small-cap

Mid-cap

Enterprise

8

Tiered architects

Strategic Thinking

System Interactions Communication Design

Enterprise Architect

Across Project Highly Abstracted

Across Organisation

Minimal, High Level

Solution Architect

Focused on Solution Very Detailed Multiple Teams Detailed

Application Architect

Component Re-use,

Maintainability

Single Application Single Project Very Detailed

9

The Dictating Ivory Tower

Enterprise Architect

Solution Architect

Application Architect

Developer Developer

Application Architect

Solution Architect

Application Architect

Application Architect

Developer Developer

UML

Design ManualReq

spec

TCO

ROI

EJB

MOM

ESB

Business Intelligence

10

Agile

• Individuals and Interactions

• Working Software• Customer Collaboration• Responding to Change

• Processes and Tools• Comprehensive

Documentation• Contract Negotiation• Following a plan

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

11

Agile

• Individuals and Interactions

• Working Software• Customer Collaboration• Responding to Change

• Processes and Tools• Comprehensive

Documentation• Contract Negotiation• Following a plan

Up-front designUML/BML

OrganisationROI/TCO

IterativeReal Options

RetrospectivesCraftmanship

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

That is, while there is value in the items on the right, we value the items on the left more

12

Enterprise Agility Adoption

Startup/Small-cap

Mid-cap

Enterprise

Individuals and Interactions

Working Software

Customer Collaboration

Responding to Change

Processes and Tools

Comprehensive Documentation

Contract Negotiation

Following a plan

13

Agile Iterations

Options/Plans

ExecutionValidation

Reflection

”Tends to be focussed on delivering functionality rather than looking after their architecture”

Project Manager

Scrum Master

Product

Owner

?

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

15

Agile Architecture

16

Time, Leading to..?

• Software Entropy receives no focusas a system is modified, its disorder, or entropy, always increases. This is known as software entropyWhen a program is modified, its complexity will increase, provided that one does not actively work against this.

• Technical Debt increasesa 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 InternalizedTribal 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?

17

- Pause, Paul- Ja, pause Paul, bare 2 minutter

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

Main Responsibilities

• Technical Leadership of the productSet the standards for developmentProvide high-level design practisesEnsure best practise and communicate theseMinimize software entropy and increase product qualityEnsure that the architecture is sufficiently documented

• Enterprise collaborator and networkerIdentify and support re-useCollaborate with enterprise architects to incorporate cross-cutting concerns

20

Enterprise Foundation

Application Architecture Foundation

Solution Architecture

Enterprise Architecture

Business Requirements

Ensure that the productIs built within theEnterprise guidelinesTo support the business

22

Up-Front Project Planning

StructureUnderstand 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

VisionCreate 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

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

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

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

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

Mastering Skillset

Remember

Describe

Name

Find

List

Relate

Write

Understand

Explain

Compare

Discuss

Predict

Outline

Restate

Apply

Complete

Use

Examine

Illustrate

Classify

Solve

Analyze

Compare contrast

Examine

Explain

Identify

Categorize

Investigate

Evaluate

Justify

Assess

Prioritize

Recommend

Rate

Decide

Create

Plan

Invent

Compose

Design

Construct

Imagine

Bloom’s Taxonomy

> > > > > > > > > > > > > > > > > > > > > > > > >

29

Problem Solving in your Team

Stack Overflow

Google

ArchitectSmart Guy

?

30

Stack OverflowI 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.

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.

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 componentizationIncrease awareness of cross-cutting concerns

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 interventionAutomatic testingAutomatic software analysisPeer review

34

Automatic Testing

• Accepted curse of unit testingDocumentationRegressionWorks best on loose coupled entities

• Focus on Integration testingEnd to end scenario supportEnsure that Input leads to OutputHelped by virtualization and continuous deploymentsWatch out for maintenance costs

35

Automatic Software Verification

• Perform automatic analysis of source code and binariesTools 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

36

Peer Review• Formal or informal collaborate effort of cross-

examination of source code• Review improve quality by

Rejecting or improving commitsCommitters and reviewers learn from each otherMotivation 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 thingIt can do to improve product quality is to introduce a code review process

37

The Code doesn’t Tell the Whole Story

• Code may hint at(Functionality)Programming languageArchitectural tiersNaming standardsPatterns and idioms

• But even those hints may be misinterpreted• Code may not reveal

Why the technologies were chosenThe overall structure of the systemWhether any common patterns or principles are usedHow and where to add new functionalityHow security, stability, scalability, etc is achieved

38

Recognize this place?

39

Recognize this place?

40

Recognize this place?

41

Recognize this place?

42

Recognize this place?

43

Recognize this place?

44

Recognize this place?

45

Documenting Architecture

• Documentation is not hard• Briefly outline technologies and choices

Keep the stories short and to the pointCreate simplified diagrams

• Keep it with the source code under revision control

Use the Source, Luke

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

47

Example 2 - gmaven

• Generate lists from source code scanning<plugin> <groupId>org.codehaus.gmaven</groupId> <artifactId>gmaven-plugin</artifactId> <version>1.5</version> <executions> <execution> <phase>generate-sources</phase> <goals> <goal>execute</goal> </goals> <configuration> <source> src/main/gscripts/services.groovy </source> </configuration> </execution> </executions> <dependencies> <dependency> <groupId>com.thoughtworks.qdox</groupId> <artifactId>qdox</artifactId> <version>1.12.1</version> </dependency> </dependencies> </plugin>

def dir = new File(project.basedir.parent, "gps_persistence/src/main/java") def builder = new com.thoughtworks.qdox.JavaDocBuilder() builder.addSourceTree(dir) def services = builder.classes.findAll { it.annotations.find { it.type.value == "org.springframework.stereotype.Service" } } def servicelist = new File(project.build.directory, "service.ad") servicelist.withPrintWriter { pw -> services.each { pw.println "+${it.name}+” if (it.comment) pw.println "${it.comment}” pw.println '[cols="2", options="header"1]’ pw.println '|===’ pw.println '|Method’ pw.println '|Description’ it.methods.each { if (it.public) { pw.println "|${it.name}” pw.println "|${it.comment?:''}” } } pw.println '|===’ } }

48

Example 3 - Violet

• Simple tools for structural diagrams

49

Are you responsive?

• All changes to a software product must be reversibleDeployments fail for many reasons outwith control, making this a real risk in any software projectHowever 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 questionsHow 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?

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

51

Q (+A?)

I left the murky, bedraggled streets of home to venture on aJourney for a thousand miles and more.I had a vision and a purpose and everything around me sprang to lifeIn a newfound thrill of excitement.Arriving at my final destination I saw wonders beyond compare and suchJoy and such life that everything fell into place and harmony.How can this be of wonder, you ask, when I reveal the final destinationAs the origins of my journey. But alas, everything old can be born againFrom a new perspective

top related