1. 1 Review

2.  Influences  Problem Domain  Ilities  Marketecture and Tarchitecture Collide  Technology Base  Human Influences on This  Results now while considering the long run  Future Support Needs  Architecting for a Class of Needs  Harnessing Feedback  Include Developers  Risks Associated w/ This 2

3.  Clarity in Communication  Both Must Understand the Problem Domain  Worse if Markitect doesn't understand it  Each benefits from understanding the other  Agreement on Project Management  Common Language (e.g. UML)  Make Data Available 3

4.  Project Action  SELECT  Join Action  FROM  Select Action  WHERE 4

5.  Supposed vs. Real Motivations  Real Motivations  It is Cool  Early Customer Requests  Costly  Doesn't Compensate for a Poor Product  Matrix of Pain 5

6. 6

7.  Webservices  REST  Easy to Access  Parameters in URL  Not Well Defined  SOAP  Machine Readable  More Complex Inputs  Well Defined  Bloated (XML adds data) 7

8.  Formats a.k.a. Schemas  MATHML  MUSICML  Well Formed 8

9.  Use Case Diagram  Shows Scope  Static Class Diagram  ERD Shows Entities and Relationships  Sequence Diagram  Process Shows Flow of Methods 9

10.  Resumé Driven Design  Sense of Wholeness  Giving In To Great Architectures 10

11.  Encapsulation  Loose Coupling  High Cohesion  Interfaces  Parameterization  Deferring Uncertain Decisions 11

12.  Market Pressure w/ No Architectural Support  Technical Debt  Entropy  Entropy Reduction 12

13. 13

14.  Logical View  Development View  Process View  Physical View 14

15.  Request  Request Line  Method  Address  Http Version  Headers  Body  Response  Response Line  Version  Status Code  Status Description  Headers  Body 15

16.  Stateless 16