TSSJS Day 3: Neward’s Ruminations on Pragmatic Architecture

One of Ted’s first slide:  “Architecture is not to provide retirement for programmers…”

See http://www.joelonsoftware.com/articles/fog0000000018.html but the basic gist is that Java has way too many layers connected with XML.

Architecture definition: building design, building style and structuring a computer system.

First, we have to recognize the differences between a simple and a complex design.  What to expect in a good architecture: the “ities” (Reliability, Maintainability, Scalability, etc.). Make it easy for developers to make the right decisions by default…build an architecture that makes it easy for a developer to fall into the pit of success.

Good architects understand, reassess and explore.  They understand goals that back up the “ities” and they understand the constraints (money, time, resources, domain, ability of the team) that can work against those goals.

Goals – changing business climate changes goals; same with constraints. You constantly have to reassess and adapt to these changes.  An architect needs to explore…understand the viability of new technologies to fit the needs of current systems at least to a 2-sentence story.  If you can’t explain that to your boss, he may consider talking the IBM Rep. (Websphere wise-crack…LOL).

Three kinds of architects:

  • Infrastructure Architects: design of datacenter, network, app servers, etc.
  • Enterprise Architecture: concerned about the strategic vision of application and services within the entire organization
  • Solution Architect: writes code!  Lead for one or more projects.  Focused on building solutions usually in the scope of a division, and Explores new technology.  This is the area where Ted desires to be.

Patterns and architecture: Patterns failed! Patterns should describe architectural elements not the architecture itself.

Technology-architectural decisions should revolve around progress.  Start with the big ones and move from there.

Architecture elements to consider:

  • Communication/Distribution: Transport, Exchange and Format for RCP; tailor the exchange to the situation
  • Presentation/Interaction: style, implementation, perspectives and composites; perspective is what’s important to the actor using the system…important to consider!
  • State Management: Durable v. Transient state, Relational v. Object v. Hierarchical; Context-based v. Process-based state.
  • Processing: Implementation, Concurrency/Parallelism, and Transactional; functional languages address concurrency very nicely.
  • Resource Management: Locator/Registry, Discovery, Injection,
  • Tools: Languages, Code manipulation, etc.

In summary, architecture is an explicit action, if you don’t do it, it will be defined implicitly for you! It represents a higher perspective and defines a style for the system, and lastly defer decisions to the last reasonable minute, but not forever!

Very good talk and recommend taking a look at the slides for more details.  As a solution architect, I think I do some of these things but I certainly will fine-tune my own approach based on what I learned here…Bravo!