1 Review

 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

 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

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

 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

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

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

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

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

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

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

13

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

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

 Stateless 16