dhh1128
commented
9 years ago I like this article, which summarizes some of the same issues:
https://genehughson.wordpress.com/2015/07/01/modeling-the-evolution-of-software-architecture/
Also, note his link to Ruth Malan's work. Several of her ideas jump out to me:
- The separation of visualization emphases into those that focus on what (static, constituents of the system), how (interactions/dynamic, processes), and who (people, organizations, etc).
- The idea that we might need multiple views of the same thing. Quoting Malan:
"Oh, while I'm being contentious... I think the design should be expressed in terms of multiple views as useful to expressing the design. Stakeholder concerns need to be weighed, and all that good stuff. But the views the architect focuses on are the views the architect determines are important to getting the thing designed and built.
A security (set of) view(s) is a design view -- made necessary because there are stakeholders who care about security, but it is first and foremost a design view. It is a set of models (and text) that we use to address the various security concerns of various stakeholders taken and balanced by the architect (team). The architect acts as the agent of these stakeholders actively and dynamically balancing their various security-related concerns and creating the models and capturing the reasoning and decisions the architect needs to think through, validate and communicate the design dimensions that address security. It comes back to my heretical notion that design is a conjoint matter and much is being dynamically balanced during the design process.
The views are addressed at some separation of concerns, at isolating some concern to gain design traction on the threads of reasoning that must take place to do that piece of design work and to have something to resolve across, as we iterate through the concerns that cut across the separated concerns (however you cleave concerns, you leave a set that then cut across; if you focus on security, you then have to look at the impact on cost and scope, performance, usability, scalability, etc.)...
Which is to say, I think the architect is the first-order citizen in the creation, selection and construction of views."
Although intent is not an architectural language, it may make a lot of design and architecture work easier if it facilitates talking about high-level concepts such as those that often make their way onto informal whiteboard diagrams. Have a look at http://www.infoq.com/articles/road-ahead-for-architectural-languages -- especially the first callout about "WHAT INDUSTRY NEEDS FROM ARCHITECTURAL LANGUAGES". This should help clarify which features of architectural languages are most valuable. Which could we support in intent?
First idea is to make it easy to refer to graphical diagrams. Simple hyperlink is good; anchored hyperlinks are better (e.g., "foo.jpg#red" could mean everything in red on the foo.jpg diagram; "foo.jpg#topleft" could give 9 quadrants of accuracy).
Second idea is to make explicit the observation of Grady Booch that architecture is distinguished from design by the significance of its decisions, where significance is measured in cost to change. Perhaps we should formalize the idea of "key decisions" as an attribute of an architecture?
Should architecture.i be a standard file in a component? Or should architecture be a subclass from which we can derive, and which we can specify in typical intentional declarative fashion?
Note the idea of formal semantics. We need to be able to make assertions about architectural characteristics, such as "All configuration is stored in the DB". Perhaps we do this by using tags (marks)? I.e., we tag items as "configuration", and we have an architectural component named "DB". We express an architectural principle (in architecture.i) with the informal statement "All configuration is stored in the DB", and then we map it ("all configuration" = +config; "stored" = +persist, "DB" = @my_db_component)?