pragmatic architecture

Sofia, Bulgaria | 9-10 OctoberSofia, Bulgaria | 9-10 October

Pragmatic ArchitecturePragmatic Architecture

Ted Neward

http://www.tedneward.com

Ted Neward

http://www.tedneward.com

Cathi Gero

http://www.prenia.com

Sofia, Bulgaria | 9-10 October

So one day,

she wants to build a doghouse…

So one day,

she wants to build a doghouse…

Source: “Why I Hate Frameworks” (http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12)


ArchitectureArchitecture● 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?

● 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?


ArchitectureArchitecture

● Integrity

● Simplicity

● Extensibility

● Maintainability

● Composability

● Parsimonity1

● Longevity

● Integrity

● Simplicity

● Extensibility

● Maintainability

● Composability

● Parsimonity1

● Longevity

● Availability

● Scalability

● Performability1

● Security

● Reliability

● Recoverability

● Manageability

● Usability

● Availability

● Scalability

● Performability1

● Security

● Reliability

● Recoverability

● Manageability

● Usability1 We know “Performability” and “Parsimonity” aren’t real words; unfortunately for us, “Performance” and “Parsimony” don’t end in “ity”.

● What do we expect of a “good” architecture?

- meet the “ities”:


ArchitectureArchitecture


● make it easy for developers to make “right” decisions

● where “right” => “right for this project or system”

● enable correctness by default


● make it easy for developers to make “right” decisions

● where “right” => “right for this project or system”

● enable correctness by default


“Pragmatic Architecture”“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


ArchitectureArchitecture● 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

● 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


ArchitectsArchitects

● 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

● 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


ArchitectsArchitects● 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

● 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


ArchitectsArchitects● Architects …

● understand

● reassess

● explore

● Architects …

● understand

● reassess

● explore


ArchitectsArchitects● 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

● 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


ArchitectsArchitects● 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

● 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


ArchitectsArchitects● 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”…

● 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


CatalogCatalog● Technology-architectural decisions

● Make the “big” decisions first

● Example: is the jar full?

● Technology-architectural decisions● Make the “big” decisions first

● Example: is the jar full?

Source: http://www.bredemeyer.com/pdf_files/Presentations/SoftwareArchitectureIntro.PDF

How about now?


CatalogCatalog● Architectural Elements

● Communication/Distribution

● Presentation/Interaction

● State Management

● Processing

● Resource Management

● Tools

● Architectural Elements

● Communication/Distribution

● Presentation/Interaction

● State Management

● Processing


● Tools


CatalogCatalog● 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 …

● 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 …


CatalogCatalog● 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?

● 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?


CatalogCatalog

● 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?

● 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?


CatalogCatalog● 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

● 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


CatalogCatalog● 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”


● locator/registry

● Configuration files, Windows Registry, etc

● discovery

● Plug-and-Play, peer-to-peer, etc

● injected

● “Dependency injection”

● a priori Knowledge

● “hard-coded”


CatalogCatalog● 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

● 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


ApplicationApplication

● Now that we’ve identified these elements…

● … how do we use them?

● Now that we’ve identified these elements…

● … how do we use them?


ApplicationApplication

● 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!

● 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!


ExamplesExamples● 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

● Client/Server (2-tier)● developed in the 1980’s in response to PC’s


● 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


ExamplesExamples

● Client/Server (3-tier, n-tier)● developed in 1990’s in response to the Internet


● 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

● Client/Server (3-tier, n-tier)● developed in 1990’s in response to the Internet


● 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


ExamplesExamples● 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

● 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


ExamplesExamples● 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)

● 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)


SummarySummary● 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!

● 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!


CredentialsCredentials

● 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

● 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

● 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

● Who are these two?● Independent consultants, mentors, architects, authors

● Collectively, we have between us:

Sofia, Bulgaria | 9-10 OctoberSofia, Bulgaria | 9-10 October

Thanks!Thanks!


Appendix: ResourcesAppendix: 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

● 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

pragmatic architecture

Documents