1.
Agileversus?Architecture

2.
• “Who Needs An Architect?” by Martin Fowler - http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf• “Architecture” video by Uncle Bob (Robert Martin) - http://www.cleancoders.com/codecast/clean-code-episode-7/show• “Emergent Design and Evolutionary Architecture” by Neal Ford - http://www.thoughtworks.com/emergent-design• “Design == Code” by Jack Reeves - http://www.developerdotstar.com/printable/mag/articles/reeves_design_main.html• Zen and Enterprise Architecture (me at IASA) - http://richardalexandergreen.wordpress.com/2011/08/17/profil/zen-and-enterprise-architecture/• Agile SOA, Agile EAI (me at IASA) - http://richardalexandergreen.wordpress.com/2011/08/17/profil/agilesoa_iasab/

3.
Definitions• Architecture is an aspect of design. - It is the aspect where the designers decide how the components will be organized.

4.
Metaphors• Enterprise Architeture is like urban planning. - There is a big-picture plan, but it has to be developedone project at a time.• Application Architecture is like the floor plan of a building. - It identifies the major functional areas and indicates how they communicate.• Program Architecture is like the layout of a refrigerator. - It indicates the design patterns to be used by those who work on various types of modules.

5.
Sometimes there is tension betweenAgile concepts andArchitecture concepts

6.
What will webe asked to do?

7.
Traditional Planning Needs• Tradition: Long lead times for infrastructure purchases and installation seemed to require early planning.• Tradition: The staffing of the project is based on the target framework for the product.• Tradition: Once the project is rolling, service, database, and desktop engineering all want to know how and when they will be expected to contribute.

8.
HOW MUCH HOW SOON?

9.
Planning processtends to wantup-front designswhile agileprefers to keepoptions open.• Traditionally, (pre-agile) Architecture wants to preview how the application will be deployed.• In effect, several stakeholders want to know the how before the what is well established.

10.
Keepoptions open

11.
Deploy via clouduntil thatbecomestooexpensive.Risk:This trades lead-time advantagefor other problems.

12.
Designso that you canswitch frameworkswith minimum costs.Risk:Such designsseem too abstractto some, andthey willignore the design.

13.
Tell everyone that the early releasesare prototypesto test usability (or some other quality).Risk: All too frequentlythe "prototype" messagemeans different things to different people.

14.
Let the architecture emerge.Risk:Many teamsdo notknow howto do that.(See next)

15.
Agility meanskeeping your options open.Try to rememberthat business practice, policy, and strategywill change.Defer decisionsto the last responsible moment.Embrace change- avoid strategies that constrain the futureof the product.Define componentsand coding practicesthat minimize the costs and risks of change.

16.
Architecture is not abouttools and frameworks.Architecture is about collaboration collaborating componentsand collaborating teams.Architecturedefines the roles and responsibilitiesof components.A good architecture (and coding practice)allows components to be replacedwith minimal costs.

17.
Good architectureis like goodobject-oriented design.You design for coherence, minimal coupling, potential re-use.The difference between architecture and object-oriented designis mainly a matter of context.Well-designed components are like "black box" Other components see the interface, but dont need to know what goes on inside.Black boxes are defined by their interfaces. Defining the interfaces clearly (and early) will enable and expedite collaboration between programmers and teams.

18.
Technique

19.
In an enterprise context,certain "applications"(and their corresponding teams)are the natural candidatesfor certain responsibilities.- Example: Customer contact datais owned by Customer Relationship Management(CRM) system.- Example: Contacting a customershould involve CRMwhen Field Service (another system)requires some contact.

20.
In an application design context,there are various techniques forpredicting needed interfaces.(At first, the designers might not have a clear idea of what the component actorswill be, let alone what they need to say to each other.But there are team ideation and collaboration techniquesthat tend to drive these things out quickly.)-CRC cards = Class Responsibility Collaboration cards.- Use Case Scenarios. Story Cards- There is a variation on Behavior Driven Design (BDD) where the design team starts from an BDD test and proceeds to create stub code and interface definitions. (This is similar to a CRC session, but it creates interface code instead of cards. It is slower but more precise.)

21.
there are design patternsand programming conventionsthat teams discuss and agree to follow.- Late Binding:Dependency Injection vs. Class Factory vs. RPC- Initialization: Automatic / Lazy / Eager / How much?- Conventions for documenting methods / messages.(Write an English sentence describing the action / fact.)- Logging: Which logging framework? What/When/Why to log at each level of logging.- How to model a real-world concept in data? (measurement, money, date, time-stamp, location)

22.
AgileArchitecture