WICSA 2005:Ccorbell wicsa notes
From WICSA Conference Wiki
WICSA notes by Chris Corbell
Thursday Nov. 10, 2005
The second Architectural Design Decision session began the day. Jeff Tyree briefly revisted questions of classification or taxonomy of design decisions, citing one possibility as a state-based classification in the development process - a decision may be tentative, at a pilot state, controlling a prototype, controlling implementation, etc. 1471 defines document status as being required for an architectural description, if we treat a design decision document as a view into an architectural project (and define a corresponding viewpoint) then perhaps this is simply the content of the status attribute. This is actually something that we didn't discuss in the session that just occured to me while writing: that we can define an architectural decision viewpoint. Perhaps that can be added to the call to action for those who participated in this session.
I need to look more at methods of root cause analysis. Jeff cited typical architectural problems root causes often being other than architectural technique, esp. requirements, CM system, etc. I think that's probably true in an organization with mature architecting practices, but the opposite may be true in my organization - the failures of legacy product architectures have been not due so much to bad requirements or CM (though those played a role) as to the complete absence of architecting activity and architectural skillset development in the engineering staff.
I enjoyed the late-binding of third-party webservices architectural discussion, although it was a bit abstract (I would have liked to hear more concrete architectural problems and decisions). This relates at a basic conceptual level to my project, where we have late binding of business object definitions and we also anticipate late binding to some third party services (third-party ECM systems acting as clients, and a pluggable repository model).
The air traffic controller system architecture was very interesting to me because its core design is very similar to my system's data replication model (while we call it a "changelist" and "metadata cache" it's essentially a similar auto-updating distributed object model). Like this system we anticipate queries to the local client data or object cache, for us this is not so much for mission-critical response as it is to reduce chatter to the server, esp. in infrequent-write situations. For that reason we're trying as a first pass to avoid the need for notification registration that the traffic-controller system also uses to supplement the replication (DO) pattern. The fact that a system very similar to my changelist/replication design worked on a high-availability system as realtime-critical as air traffic control, often with over 100 clients on a server cluster, gives me fairly high confidence that our design will scale in a less critical and less time-critical DAM context (even if metadata is heavier).
The final session of papers was on software archtitecture consistency and the discussion was fairly interesting.
I had a few observations on the declarative approach to architectural reflection with AQL. First I'm not sure this should really be called declarative - it requires a custom virtual machine in order for architectural queries of the deployed system to work. I'm not sure what method is used to embed the architectural information in the running system but I rather doubt it's something that I'd consider declarative (like XML files that declare java security, data source, or ejb properties, for example). Even if so though, it's much heavier due to the custom VM requirement. There may be a bit of academic-practical dissonance - the architecture which is potentially most complex and configurable is going to be built with distributed and stateless components, which aren't supported by this approach. A more interesting approach could possibly involve a component interface that conforming components implement, or an external declarative resource (generated from source comments by XDoclet?) which doesn't require modification of the environment.
ArchJava (what I'd naively call an architectural instrumentation language) is also an interesting idea but again I think it isn't suitable for practical application. A few notes:
- An aspect-oriented approach would make much more sense; the aspect can be applied to validate architecture without forcing the source code to change, and not applied at actual deployment so there is no performance overhead.
- The 16,000-LOC sample is not sufficient to prove real-world refactoring potential; the systems that most need to be refactored are generally the 100k to million+ LOC systems. I think the presenter knew this though.
- In the refactored code samples there is -more- code. It just feels wrong to me to call it "refactoring" and end up with more code! It's really adding architectural validation features, and then refactoring this bigger code base, based on what those validation features tell you.
The validation method presented by Muskens using relation partition algebra was very elegant, I think folks liked its simplicity. Hopefully that paper will show up on the Wiki, and the algorithm will show up in some nifty tool...
The final session had some good wrap-up discussions, I was glad to be able to chime in a little on the mutability and scalability of agile - I actually take a fairly heavy documentation approach in my project but still consider it an agile project.
Overall the conference was very inspiring. I have a number of new techniques and several more to research in more depth in the hope of improving architecting practices in practical (i.e. high-ROI) ways at my company. On the way out of the lobby I ran into Len Bass and Paul Clements again and told them it was valuable, and that I felt like the Blues Brothers after visiting the church of James Brown. It got a laugh, but it's true, I'm on a mission...
Wednesday November 9, 2005
The second session on Architecting involved an extended discussion on the relationship between architectural practices and agile methodologies. On the surface it was suggested there is potentially a conflict here, however with further discussion I think we had a near consensus that there is no conflict so long as the architecting activity (like documentation activity) is that which is sufficient for the project. Rod Nord cited Cockburn's continuum from unceremonial/agile to ceremonial/planning methodologies as criticality increases - systems which require a high degree of safety because they can lead to loss of substantial capital or loss of life must be approached with stricter control than less critical systems. But overall there is no inherent tension between architecting and agile development. I shared my company's current approach which was recognized as very agile in the sense that there is no architect per se, team leads (who are also developers) lead a more or less collaborative architecting process.
The second plenary session was not so useful to me, I think most folks including some panelists saw the "great debate" topic as a little beside the point, but there were still some useful remarks. I didn't stay to the bitter end of the session (I think it ran late).
I had lunch at a table with Paul Clements and Len Bass and got to eavesdrop a little on their research work and various minutiae. I ordered a couple of their books after lunch with the WICSA discount.
There was another joint WCRE-WICSA session after lunch which was much more reverse-engineering focused. The gist of one of the papers was that in large and layered system the architecture as seen in the source code might be significantly different from the architecture of the final deployed system. Linux was cited as an example, where some C code goes through as much as 6 layers of macro expansion. It's entirely possible in a system like this that a dependency can be generated in the deployed system which is not depicted in the source (which is presumably closer to the architectural intent).
I don't think this is a huge issue from the standpoint of architectural practice. Code generation is a commonplace technique, particularly for large systems, and the central aim of architecting is not to create absolutely enforced dependency boundaries but rather to make the approach to implementation and maintenace structured, manageable, and accountable to stakeholder concerns. Hence it is much more important, generally speaking, that the source stay consonant with the architectural vision, than that the runtime artifact exactly resemble it (topologically, vs. functionally). There are exceptions of course: if the divergence between deployed artifact and architectural intent undoes essential qualities which the architecture was designed to ensure (functionality, security, reliability, etc.)
We had the first part of the Architectural Design Decisions (to be continued tomorrow) working session. This was a good working group. I made a few observations:
- There was an emphasis on visualization. When justified by project size I feel that tracking design decisions should be approached primarily as tracking architectural decision metadata (the decisions are our "business objects") along with architectural assets; such as system could easily be used as a data source for a graph visualization, matrix representation or similar interface; graph visualization is not primary.
- Prioritization of placeholder decisions can't always simply follow priority of concerns, though that's a rational starting place - Jeff corroborated this from his experience. Finer-grained task dependencies and other constraints (resources e.g.) can come into play.
- Nobody present used generic modelling tools like MIT's Alloy to model a design and test it for logical consistence or discover counter-examples. Prototypes with the concrete technologies do seem to be common and treated as throw-away code (as we've done at Extensis as well) to prevent over-prototyping.
The final session of the day was a BoF session with Rich Hilliard on IEEE 1471. It's likely that the 5-year review will result in the recommendation being promotoed to a standard, and ISO is also getting ready to vote on adopting it, possibly recasting some more concrete ISO standards in terms of viewpoints and views. After the meeting I signed up for the IEEE-1471 users mailing list. I'm interested in collaborating with a researcher on a case-study of attempting to migrate my company to 1471-based documentation practices.
Tuesday Nov. 8, 2005
The second session today was Architectural Descriptions, which included three presentations. The third presentation, How Does the Architect’s Role Change as the Software Ages?, was very useful in corroborating and defining things about the lifecycle of a system and the architect's changing relation to the system. I'd like to summarize the ideas for my company when I return, as it applies to a range of activities at Extensis.
The project I'm leading is currently in the canonical "blank page" phase where textbook architectural approaches apply; over the course of the next year this project will transition to the "integration" phase where the technology is integrated into various products. We have at least one product which is very definitely in the "magic" phase (where no one knows completely how it works and we're afraid to touch it, as the cost of any change is radically variable). An interesting problem for a company is probably finding some relatively objective way to identify the phase of a product and predict when it will pass from late integration phase to magic phase; i.e., predict when a code base's entropy becomes critical enough that it is no longer possible to add value to it in any cost-effective way.
I took a number of notes from the first WCRE-WICSA joing plenary on things to consider and follow up on - several sources for viewpoints, the general idea of analyzability being opposed to flexibility in architecture, etc. The panel discussion was interesting, in regard to popularizing architecting techniques there was a point I wanted to add to the discussion but didn't have time: while education certainly helps it's really more concrete ROI data that industry needs, we need to have case-studies that demonstrate that architecting practices are causally related to lower cost (evidenced as greater earned value, shorter development time, less maintenance effort, longer integration phase in the system lifetime, fewer defects, etc.) This is problematic considering what Booch pointed out, that there are very bad architectures behind some extremely commercially successful products. Would a better architecture make these successful products more successful? Is it impossible to achieve an 'other things equal' analysis here (since factors like branding, marketing, PR and strategic business alliances or acquisitions can overshadow strictly technological or usability concerns)?
The first working session was this afternoon, I participated in Architecting, where five papers were quickly delivered demonstrating some real-world architectures of interest; we'll have a follow up session tomorrow to discuss some topics related to these.
Finally we had an architectural practioner's BoF session today that was fairly useful. We all had similar concerns about wanting to use information from this conference for concrete improvements in practices but feeling that some conference content was a little impractical and overly academic. We began to brainstorm about ways we could bring our concerns to the conference organizers in a positive way. I suggested that practitioners could offer to participate in case-studies with researchers and posted a Wiki page for this purpose, linked to from the BoF discussion page.
Monday Nov. 7, 2005
Just starting a wiki page with a few reactions to the conference so far. Comments are welcome.
I'm feeling some predictable cognitive dissonance between academic / speculative approaches to software architecture and pragmatic approaches.
I say this being one who's sometimes characterised as academic in my company, because I advocate improved architecting practices (other teams generally don't even produce a design document for each iteration), adoption of things like UML and 1471, collaborative design with very open brainstorm and pattern discovery sessions, etc. Nonetheless I find myself feeling like a cheerleader for the real world on the sidelines of some fairly impractical ideas - which in a way is nice to know, that my aims at work really are grounded in real-world benefits and goals.
I'm currently sitting in the GEAR session and I'm very surprised at the complexity being presented. The GEAR process has too many components and although I'm sure there's a well-thought out sequence of deliverables and steps it's not evident from the diagrams - this is too busy a model for practical application in agile organizations. I can imagine a very large and ceremonial organization adhering to it, where it might be an improvement over higher-entropy formal methodologies and bureaucratic habits. But there's no way a lighter organization or startup with a diverse process-culture environment would go for it. It doesn't scale small enough - it's fine for a methodology to be capable of complexity and very ceremonial maturity (e.g. for high CMM organizations), but it should be possible to take a subset and go with it. The acronym - "Good Enough" - is a bit of a misnomer for an approach that is actually too much for most.
The Grady Booch keynote was predictably cool. It was titled as "quantitative" and I don't think it was, but it was still a worthwhile picture into his current thoughts and the Handbook of Software Architecture project, I like the idea of amassing for case-study a great number of architectures for study and comparison. If it's permitted I'd like to contribute the architecture of my current project once it's proven with a shipping product (still a year away).
Other papers today didn't blow me away, my interest ranged from mild curiosity to aversion mainly on grounds of over-technicality - I prefer adaptable standards, practices and ideas to very constrained empirical or theoretical ones. Also the tutorial this morning on Large-Scale Systems Architecture was a little disappointing. It felt a little like a book summary with UML that most of us know and no real surprises, nothing really unique to large systems other than platitudes like "keep it high-level." It was also a little annoying because, while most of the content was predictable, the presenter treated questions (which could bring the conversation to relevant depth) as distractions and cut them off halfway through the session.
My favorite session so far was the Lattix dependency structure matrix tutorial on Sunday. The DSM is a concrete tool that can yield great benefits both for new architectural module/package design and for reverse engineering and refactoring of existing systems. The Lattix tool makes exactly the improvements that I imagined would be useful when I first read about the DSM - automated transformations, hierarchical component groups, etc. I've downloaded a copy to start messing around with, and at lunch with Neeraj today I talked about getting the plugin SDK and trying to write some source-scanning plug-ins for other languages. I'll probably try python as a first pass; I'm wondering how difficult it would be to work with some gcc open source as a starting point for a platform-independent C/C++/Obj-C reverse-engineering plugin.
