SAC 21 Workshop: What was right, what was wrong, and what was missing.

Now I know the answer to the question of what will it take for me to actually start writing in this blog.  Now I need to figure out how WordPress works.  In the meantime, here’s a really long post.

On June 8th I attended the Software Architecture Challenges for the 21st Century workshop (http://csse.usc.edu/csse/event/2009/Arch-Workshop/pages/program.html) held at the University of Southern California.  The IEEE Software blog (http://www2.computer.org/portal/web/computingnow/sac21) described the event this way:

“Members of IEEE Software’s editorial board and faculty from USC’s Center for Systems and Software Engineering and the University of California, Irvine’s (UCI’s) Institute for Software Research came together for a wide-ranging discussion of the role and value of architecture in software development in the age of grid, cloud, Web, and volunteer computing.”

On the three hour drive home from USC I decided that I wanted to say something about the workshop.  The more I thought about it, the more I realized I had a lot to say about what I liked and where I saw room for improvement.

What Was Right

There was a reasonably large group split between academicians and practitioners.

In general, the speakers were erudite and articulate and the event was relatively information dense.  Thankfully, there were differing opinions on several topics so we got a chance to consider the different viewpoints.

Several speakers made the point that agile software development does not mean don’t do or have architecture.  Philippe Kruchten made the point that he was both an architect and a co-founder of Agile Vancouver.  That was especially interesting to me as I was teaching both  an architecture class and an agile software development class in the spring quarter at UCSD Extension.  My experience has been that requirements and architecture provide the necessary foundation and context for agile software development to be effective.

I am especially indebted to Kruchten for his point about two different kinds of architects – Architectus Reloadus and Architectus Oryzus.  I have explored that topic in more detail already, reading Martin Fowler’s IEEE Software article – “Who Needs an Architect?” (http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf) and going through a set of comments on that article from Venkat Subramaniam’s students at the University of Houston (http://www2.cs.uh.edu/~svenkat/fall2006SE/yousaid/yourcommentsonwhoneedsanarchitect.html).

What Was Wrong

SAC 21 wasn’t really a workshop, it was more like a mini-conference.  What was missing was sufficient time for discussion and serious interaction between the attendees and the hosts/presenters.

In talking about UML, many of the presenters focused on the documentation aspects of UML.  Grady Booch went so far as to state that he threw away some UML diagrams.  Andre Van der Hoek presented a tool that was intended to capture whiteboard style sketches.  In the first case, one must (might?) assume that there was value in creating the UML that was discarded.  Just as people learn differently, so some people design differently.  For one, text and table might be sufficient.  For others, visualization is the key to understanding.  UML provides the syntax and semantics necessary for such visualization.

Once understanding has been achieved, it is reasonable to limit the maintained documentation to summary level descriptions.  I would argue that rather than throw away the rest of the model, it should be maintained in a CM repository for possible future use.  On the other hand, I often create a robustness analysis diagram as a preliminary design step.  Once we have created the diagram, we have developed sufficient confidence in our understanding of that part of the problem, and the diagram can be discarded.  The value of the diagram is in the creation.

One participant asked a question about executable architectures.  The question was answered as if it was regarding executable UML.  There is a significant difference between the two.  Executable architecture (aka simulation) is a technique that supports early system verification and validation.  To the extent that the execution can be tightly coupled to the architecture models, then we can avoid translation errors in developing the simulation.  There is significant value in avoiding such errors in complex system development (think FCS combat vehicle http://www.globalsecurity.org/military/systems/ground/fcs-mgv.htm).

Executable UML (http://en.wikipedia.org/wiki/Executable_UML) offers an opportunity to do model-based development, with transformation of the Platform Independent Model to the implementation model.  As it is explained in the Wikipedia article, xUML does have a limited scope, unlike executable architecture.

What Was Missing

The most glaring omission was methodology.  Philippe had one slide on the topic that didn’t say much.  Others ignored the topic.  This is possibly the most crucial aspect of what architects need – a method like the Visual Architecting Process from Bredemeyer Consulting.  I recommend the article “Less is More with Minimalist Architecture” by Ruth Malan and Dana Bredemeyer, published in IEEE’s IT Professional, September/October 2002, as well as the VAP.

Systems Architecting!  Software Architecture can no longer be considered as a specialty engineering element to be addressed after the systems engineering has been completed.  I totally agree with Mark Maier (http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?r=1&ISBN=9781420079135&ourl=The-Art-of-Systems-Architecting-Third-Edition%2FMark-W-Maier) when he says that architecting of software must begin early, before the system architecting is complete.  USC needs to lead in this area.  They are, after all, the Center for SYSTEMS and Software Engineering, offer an MS in System Architecture (http://www.usc.edu/dept/publications/cat2006/schools/engineering/systems_architecture.html#masters), and are leaders in the Systems Engineering Research Center.

  • During his presentation, Booch mentioned a satellite system that he is working on where software architecture has been negatively impacted by systems decisions regarding the number of processors made before the software architects got involved.
  • One systems engineer attendee asked the same question several times – how long does the software architecture last?  The answers he got were a little non-specific (e.g as long as the system lasts).  One of my colleagues suggested that perhaps the answer should have been another question – how long does the system architecture last?
  • The Software Engineering Institute (http://www.sei.cmu.edu) has recognized the need to expand their focus.  They invited John Zachman and Mark Maier to offer their perspectives on Enterprise and System architecting respectively, at the 2009 SEI Architecture Users Network conference (http://www.sei.cmu.edu/architecture/saturn/2009/).  The theme of SATURN 2009 was “architecture at all scales.”

What Now?

The time has come for a holistic architecting approach.  Software pervades our modern systems and we need to learn how to work concurrently and cooperatively, as effectively and efficiently as possible.  A lofty goal but one I believe is achievable.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: