Pragmatic Architecture

1. Pragmatic Architecture Ted Neward http://www.tedneward.com Cathi Gero http://www.prenia.com

2. So one day, she wants to build a doghouse… Source: “Why I Hate Frameworks” (http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12)

3. Architecture • What defines the difference between these two buildings? • goals • scope • complexity • materials • process • … more • More importantly, how do we know when one “style” of construction is more appropriate than another?

4. Integrity Simplicity Extensibility Maintainability Composability Parsimonity1 Longevity Availability Scalability Performability1 Security Reliability Recoverability Manageability Usability Architecture • What do we expect of a “good” architecture? - meet the “ities”: 1We know “Performability” and “Parsimonity” aren’t real words; unfortunately for us, “Performance” and “Parsimony” don’t end in “ity”.

5. Architecture • What do we expect of a “good” architecture? • make it easy for developers to make “right” decisions • where “right” => “right for this project or system” • enable correctness by default

6. “Pragmatic Architecture” “Pragmatism urges us to look to the consequences of what we do, which the discipline of architecture, infused with an idealistic focus on intentions, frequently resists.” http://query.nytimes.com/gst/fullpage.html?res=9B0CE2DB103DF932A35751C1A9669C8B63

7. Architecture • Patterns & Architecture • isn’t architecture just judicious application of patterns? • No—as it turns out, even in Alexander’s case directly, trying to use the patterns naïvely led to failure, not once, but twice • aren’t patterns in of themselves architecture? • No—patterns help describe architectural elements, but they aren’t architecture in of themselves • are patterns “pragmatic”? • Patterns are a tool, nothing more, and the pragmatic approach demands the focus remain on the end result, not the tools. • so what do patterns do for us? • Patterns give us a lexicon for discussion at a higher-level of abstraction, so we can talk without getting bogged down in irrelevant details • In other words, patterns keep us at an appropriate level of scope during discussions

8. Architects • An architect is someone who … • … defines architecture • … gets paid more than “real” developers do • … focuses on issues that have nothing to do with real- world problems • … thinks in terms of clouds, not code • … lost the respect of developer friends & teammates (who are convinced that “architect” is Latin for “cannot code anymore”) • … speaks with big words and Powerpoint slides • … has no real idea what they’re doing and has management completely fooled to that fact

9. Architects • The Three Kinds of Architects • Infrastructure Architect • “[responsible] for the design of the datacenter, deployment and maintenance of applications/services across the organization” • Enterprise Architect • “concerned about the strategic vision of application and services within the organization” • Solution Architect • “responsible for the design or one or more applications or services within an organization, usually within the scope of a division” • (We’re talking mostly to the Solution Architect role) Source: “Three Kinds of Architects” , Simon Guest

10. Architects • Architects … • understand • reassess • explore

11. Architects • Architects need to understand … • goals • Functional requirements (business needs) • Non-functional requirements (the “ities”) • constraints • Money/Costs • Time • Resources (skill sets, hardware, etc) • Domain • Abilities of the team members “A journey of a thousand miles always begins with a single step” --Ancient Chinese proverb “A journey of a thousand miles doesn’t begin with a single step; it starts with the map” --Ted Neward

12. Architects • Architects need to reassess … • goals • changing business climate changes goals • constraints • changing business climate changes constraints • project’s progress against those goals • project’s impact on the business • competitive advantage, users’ reactions, productivity, costs/benefits/ROI “No plan ever survives first contact with the enemy” –Napoleon Bonaparte

13. Architects • Architects need to explore … • new technologies (.NET, Ajax, Ruby, …) • new methodologies (Scrum, XP, …) • new approaches (objects, services, …) • in short, determine the viability of new technologies to fit the needs of current system(s) • what changes would be necessary • prototype new technologies • analyze their impact within existing architecture • NOTE: be careful of “The Coolness Trap” • “cool” doesn’t mean “appropriate”… “We shall not cease from exploration and the end of all our exploring will be to arrive at where we started… and know the place for the first time.” –T.S. Eliot

14. Catalog How about now? • Technology-architectural decisions • Make the “big” decisions first • Example: is the jar full? Source: http://www.bredemeyer.com/pdf_files/Presentations/SoftwareArchitectureIntro.PDF

15. Catalog • Architectural Elements • Communication/Distribution • Presentation/Interaction • State Management • Processing • Resource Management • Tools

16. Catalog • Communication/Distribution • all communication tools are a three-part tuple: • transport • Over what medium does the communication travel? • Examples: TCP, UDP, ICMP, HTTP, named pipes, filesystem, queues, and more … • exchange • How do we interact? • Examples: request/response, solicit-notify, async, fire-and-forget, messaged, and more … • format • In what format does the data travel? • Examples: XML, code, text, JSON, raw binary, serialized objects, and more …

17. Catalog • Presentation/Interaction • style • Graphical • Console • Programmatic/API • None • implementation • Markup (HTML, Acrobat, SOAP) • Code (WinForms, Flash) • perspectives • User, Administrative, Reported, … • stovepipe v. composite/mash-up v. “jewel” … • How many front-ends to how many back-ends?

18. Catalog • State Management • lifetime of the state • durable vs. transient state (state held across processing steps vs state held during processing) • “shape” of the state • relational vs. object vs. hierarchical • location of the state • location—where is the state? • access & transparency—who maps it in, and how?

19. Catalog • Processing • implementation • Procedural/Imperative • Classes/Objects • Declarative • Rules • concurrent/parallel (SISD, SIMD, MISD, MIMD) • Divide and Conquer • Recursive Data • Pipeline/Pipes-and-Filters • Event-based Coordination • Master/Slave, Fork/Join • Shared Data • Shared Queue • transactional

20. Catalog • Resource Management • locator/registry • Configuration files, Windows Registry, etc • discovery • Plug-and-Play, peer-to-peer, etc • injected • “Dependency injection” • a priori Knowledge • “hard-coded”

21. Catalog • Tools • general-purpose languages • Languages intended for any programming problem • problem-specific languages • Languages specific to a particular problem domain • code manipulation tools • Tools designed to manipulate code after compilation • Software Factories & DSLs • Software Factories: Greenfield & Short • DSLs: Domain-Specific Languages • code generators • Templatized automatic authoring of code • libraries/frameworks • Collected bodies of reusable code • data formats • documentation • Any written prose describing the system or parts

22. Application • Now that we’ve identified these elements… • … how do we use them?

23. Application • Analyze the requirements, choose your tools • once requirements (functional & nonfunctional) are established, architect begins analysis to tease out the architectural constraints and goals • Consider the goals and constraints • Consider the available tools & technologies • Consider the architectural catalog • Throw out what doesn’t fit • Examine the consequences of what does • Season to taste… • … bake through a few iterations… • … and serve!

24. Examples • Client/Server (2-tier) • developed in the 1980’s in response to PC’s • goals & constraints: • scalability • - use client resources to relax server load • - upgrade server to provide more power, w/o touching client • extensibility • - allow for multiple client ends • - modify server to provide new functionality, w/o touching client • performability • - always-alive connection amortizes connection costs

25. Examples • Client/Server (3-tier, n-tier) • developed in 1990’s in response to the Internet • goals & constraints: • scalability • - allow for larger numbers of clients than 2-tier • security • - throttle access to back-end resources • modularity • - extend presentation to differing tiers & platforms • extensibility • - provide new functionality by introducing new middle tiers

26. Examples • REST: REpresentational State Transfer • developed as the architecture for the World Wide Web • goals & constraints: • low entry barrier (simplicity) • - simple encoding/format • - non-platform-specific • extensibility • - intermediary support • - uniform interface • distributed hypermedia audience • - designed for large-grain data transfer • - long-haul communication lines; minimize network interactions • - intrinsically stateless—any state is in the resource itself • Internet-scale (scalability) • - anarchic scalability • manageability • - independent deployment

27. Examples • SOA: Service-Orientation • the “next-generation” architecture for the enterprise • goals & constraints • Tenet 1: Boundaries are explicit • - minimize network interaction (scalability) • Tenet 2: Share schema/contract, not class • - minimize coupling across services/clients (interoperability) • Tenet 3: Compatibility based on policy • - describe compatibility in formal policy, not code (parsimony) • Tenet 4: Services are autonomous • - minimize dependencies (reliability)

28. Summary • Architecture… • … is important: if it’s not defined explicitly, it will be defined implicitly, and may not be something you’d like • … defines a “style” for the system, and as such answers some questions even before they’re asked • … is thus difficult (but not impossible) to refactor • Architects analyze and select … • analyze: to tease out the architectural constraints and goals • Consider the goals and constraints • Consider the available tools & technologies • Consider the architectural catalog • select: which elements of the catalog “fit” • It’s a recipe: choose the ingredients… • … examine the consequences of each selection… • … season to taste with complementary ingredients… • … making new choices where experience offers new insight… • … bake through a few iterations… • … and serve!

29. 8+ books, including: Effective Enterprise Java Effective .NET Pragmatic XML Services Pragmatic Project Automation (.NET) C# In a Nutshell SSCLI Essentials 12+ articles/papers MSDN TheServerSide.NET 30+ years’ experience large teams to lone-wolf large firms to small COTS to enterprise apps CPA MVP (C# & Architect) Blogs blogs.prenia.com/cathi blogs.tedneward.com Credentials • Who are these two? • Independent consultants, mentors, architects, authors • Collectively, we have between us:

30. Thanks!

31. Appendix: Resources • Blogs • Simon Guest, “Three Kinds of Architects” • Joel on Software, by Joel Spolsky • “Why I Hate Frameworks” (http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12) • “Architecture Astronauts” (http://www.joelonsoftware.com/articles/fog0000000018.html) • Web • www.bredemeyer.com/pdf_files/Presentations/SoftwareArchitectureIntro.PDF • “Client/Server Software Architectures”: www.sei.cmu.edu/str/descriptions/clientserver_body.html • REST • Architectural Styles and the Design of Network-based Software Architectures (Roy Fielding, 2000, UC Irvine) • RESTWiki: http://internet.conveyor.org/RESTwiki/moin.cgi/ShortSummaryOfRest