{
Cathi Gero and Ted Neward had a session on what they call "pragmatic architecture" - the fuzzy definition of which was architecture that maintains ideals until the consequences outweigh them.
It was interesting to get this high level at TechEd; most of the sessions I went to were very technical where this was a balance between philosophy and a general approach to developing software.
One of the first thing they went after was the recent infatuation people on the architectural level have had with "design patterns." According to them, a cut and paste approach to design patterns is not the path to success - and although I haven't immersed myself in the design patterns world, I doubt it's proponents probably leave some room for flexibility in implementation.
According to Cathi and Ted, the goals of a software architect were twofold:
1. Functional Requirements (Business needs, raw functionality)
2. Non-functional Requirements (the "ities": scalability, maintainability, extensibility, and so on)
Their approach in being pragmatic about architecture was to leverage a vocabulary, not as a means to accomplish the goals of software architecture, but as a lexicon for strategies and tactics in accomplishing those two main goals. They covered what they called the 6 elements of architecture and examples of approaches (patterns?) that lend themselves to the software of the solution.
Here are the 6 architectural "elements:"
1. Communication
2. Presentation (the front end)
3. State Management (how the data are stored)
4. Processing
5. Resource Management
6. Tools
For each of the 6 they presented examples of what we see with most modern software. Under Communication, for example, they listed what they call as a "three part tuple:"
1. Transport
TCP, UDP, other network protocols
2. Exchange
Data can be exchanged using request/response, asynchronous, fire and forget, amongst others
3. Format
XML, Text, JSON, Binary, and so on.
Presentation has to do with the interface for the user. Some examples given here were Console, Graphical Interface, and Markup.
The State Model to apply in the application in pragmatic language is either durable (available always) or transient (available only certain times). Another consideration for State Management is the "shape" of the data: objects, relational, heirarchical, etc... Finally when considering the State Model there was the notion of where the data was: client, server, elsewhere...
Processing used in the application, some examples of implementation they gave were: Procedural, Imperative, Concurrent, Parallel, and Transactional. On the processing side, however, some higher level descriptions of approaches included: Divide and Conquer, Recursive, Event based, Shared Queue, amongst others.
Resource Management had to do with persistence of data and configuration. Some styles discussed for this was locator / registry, discovery, injected, and a very sophisticated term for "hard coding" called a priori.
Tools to consider in being pragmatic could be the programming language, development environment, frameworks, code generation, amongst others.
I'm not sure if this stuff originated with Cathi and Ted, but it's very useful in coming up with a high level picture of how software will work. Although most of what I've worked with recently fits under the umbrella of "web application" it would be very useful to approach new projects with this catalog and the set of approaches beneath each item in mind.
This entire session is available as a webcast, and I'd recommend it to anyone who is involved in software development, even if they don't think of themselves as architects. There is always a point when I'm reading or listening to high level stuff like this where I begin to wonder if it really matters but when it is kept concrete like this the distinction between architecture as high level thinking that has to be done anyway, and architecture as romantic "rah rah" for the higher ups is very clear.
Ted's blog seems fairly alive but Cathi's blog has not been updated for a while.
}
Cathi Gero and Ted Neward had a session on what they call "pragmatic architecture" - the fuzzy definition of which was architecture that maintains ideals until the consequences outweigh them.
It was interesting to get this high level at TechEd; most of the sessions I went to were very technical where this was a balance between philosophy and a general approach to developing software.
One of the first thing they went after was the recent infatuation people on the architectural level have had with "design patterns." According to them, a cut and paste approach to design patterns is not the path to success - and although I haven't immersed myself in the design patterns world, I doubt it's proponents probably leave some room for flexibility in implementation.
According to Cathi and Ted, the goals of a software architect were twofold:
1. Functional Requirements (Business needs, raw functionality)
2. Non-functional Requirements (the "ities": scalability, maintainability, extensibility, and so on)
Their approach in being pragmatic about architecture was to leverage a vocabulary, not as a means to accomplish the goals of software architecture, but as a lexicon for strategies and tactics in accomplishing those two main goals. They covered what they called the 6 elements of architecture and examples of approaches (patterns?) that lend themselves to the software of the solution.
Here are the 6 architectural "elements:"
1. Communication
2. Presentation (the front end)
3. State Management (how the data are stored)
4. Processing
5. Resource Management
6. Tools
For each of the 6 they presented examples of what we see with most modern software. Under Communication, for example, they listed what they call as a "three part tuple:"
1. Transport
TCP, UDP, other network protocols
2. Exchange
Data can be exchanged using request/response, asynchronous, fire and forget, amongst others
3. Format
XML, Text, JSON, Binary, and so on.
Presentation has to do with the interface for the user. Some examples given here were Console, Graphical Interface, and Markup.
The State Model to apply in the application in pragmatic language is either durable (available always) or transient (available only certain times). Another consideration for State Management is the "shape" of the data: objects, relational, heirarchical, etc... Finally when considering the State Model there was the notion of where the data was: client, server, elsewhere...
Processing used in the application, some examples of implementation they gave were: Procedural, Imperative, Concurrent, Parallel, and Transactional. On the processing side, however, some higher level descriptions of approaches included: Divide and Conquer, Recursive, Event based, Shared Queue, amongst others.
Resource Management had to do with persistence of data and configuration. Some styles discussed for this was locator / registry, discovery, injected, and a very sophisticated term for "hard coding" called a priori.
Tools to consider in being pragmatic could be the programming language, development environment, frameworks, code generation, amongst others.
I'm not sure if this stuff originated with Cathi and Ted, but it's very useful in coming up with a high level picture of how software will work. Although most of what I've worked with recently fits under the umbrella of "web application" it would be very useful to approach new projects with this catalog and the set of approaches beneath each item in mind.
This entire session is available as a webcast, and I'd recommend it to anyone who is involved in software development, even if they don't think of themselves as architects. There is always a point when I'm reading or listening to high level stuff like this where I begin to wonder if it really matters but when it is kept concrete like this the distinction between architecture as high level thinking that has to be done anyway, and architecture as romantic "rah rah" for the higher ups is very clear.
Ted's blog seems fairly alive but Cathi's blog has not been updated for a while.
}