Architectural Attributes

Hard to believe I am still working my way through posting great log entries from folks in the Spring term. This log entry from Deborah Ford in my Software Architecture and Design Class at Stevens lists great attributes for a software architect. I like that she emphasizes domain knowledge, breadth of experience, communication skills and mutual respect (architect should respect designers and developers; designers and developers and designers should respect the architect). In many ways that is a great formula for any leadership role but it is especially the case for the architect. I would like to thank Deborah for letting me share these with you. The key excerpt from Deborah's log entry:

Out of this (my experience) I’ve concluded that there are certain keys to success for architecture teams:

1. This isn’t necessarily a job for the most creative designer or best technician. It is more important to get someone who understands the big picture and can bring differing views to consensus or make a judgment when the situation calls for it.

2. Don’t farm out architecture roles to outside contractors – you are investing your knowledge capital in people who don’t have such a compelling reason to stay and can be at the whim of budgetary fluctuations. You are also giving lots of domain knowledge that your competitors may be able to take advantage of further down the line.

3. Team members should have a wide exposure and not be too wed to any particular technology or internal organization. I am wary of people who have spent their entire working career in a single organization.

4. They must be people who have the respect of the teams that they work with.

5. They must have a good grasp of the business domain.

6. They must not be seen as too allied with any single development organization

Hopefully, I will increase my volume of posts in the next few weeks since I have some backlog and a fresh stack of 30 logbooks to read from my summer classes! Later!

Simple isn't simple

This post is about John Maeda's book, The Laws of Simplicity. I just finished reading it and was simply impressed. If you read the reviews on amazon, they are mixed. I have a simpler take, read it and judge for yourself. It is a bit over $10 and 100 pages. At most it will take you the equivalent of 3 episodes of 24 to read and you will learn so much more.

I liked it a lot, will require it in many of my courses (HCI and Software Architecture and Design) and willl have several future posts on it. I have espoused simplicity and know simple isn't simple, but Maeda helps us in its pursuit. Software folks and engineers need more grounding (fore and back) in design concepts and this is a simple, gentle introduction. It is well written.

It seems appropriate to make this first post simple. For more information, Maeda has a web site. Later!

Patterns

As I say many times in my lectures Martin Fowler is an author that seems to write faster than I can read!  If you have taken my Software Architecture and Design class, his name is mentioned many times and he is a very influential methodologist/theorist/pragmatist in Object Oriented design. 

He has just re-released an article, Writing Software Patterns, that can be found on his web site.  It captures many of the things I discuss in class along with introducing you to other pattern mavens such as Jim Coplien.  (If you've ever met Cope, even that web site does not do him justice!)

Fowler also has a great emphasis on "tasks rather than tools."  Read it to discover more.

More soon.  I have an impressive student back log of entries, more on One Web Day, and more about other summer readings.  Later!

Real Architecture

Happy New Year! 

In every class that I teach (and now on my website), I always refer to Vitruvius and his 3 principles of design:  utility, durability and charm.  As is frequently the case the wikipedia has an excellent write-up on Vitruvius.  The page also leads to the original text of his book, On Architecture,  which can be found here.  In this translation, the fabled quote can be found n Book 1, Chapter 3, Section 2, "
All these should possess strength, utility, and beauty."

I have not finished reading it, but what I have read is truly fascinating, timely and also corroborates with the depiction of the Roman Empire  in the HBO series Rome, which I highly recommend.  I will post additional entries on this book in the next month.

Since 2005 was a busy year for me, I was not the best blogger and have lots of topics and student submissions in the queue.  I resolve in 2006 to be a much more active blogger, averaging at least one per week.  We will see at the end of the year how well I do!  It is always great to provide estimations and track it with reality.

Later!

Resource sources

Charles "Chuck"  Lutz presents a host of great resources on the web in this discussion group entry.  In particular he provides a reference to a Parnas paper and that is fantastic.  As you recall, I encourage any aspiring software engineer to get the Parnas' book of collected papers, Software fundamentals: Collected papers by David L. Parnas, D.M. Hoffman and D.M. Weiss(Eds.), Addison Wesley, 2001, ISBN: 0-201-70369-6.  Especially since the gift giving season is upon us, you might give yourself this book.  It will serve you well.  Highly recommended.

Mary Shaw's paper that Chuck refers to in van Vliet is "Some patterns for software architectures."  Mary Shaw and David Garlan also wrote a book on software architecture, Software architecture: Perspectives on an emerging discipline, Prentice Hall, 1996, ISBN:0-13-182957-2.  One of the few rigorous books on software architectures.

Attached is Chuck's log, entry, thanks Chuck.  Later!

I've got a bunch of stuff to share that I've accumulated over the years which I believe 
has relevance to this course. I'll send them along as time permits (I've already got a 
backlog...!)

FYI: Mary Shaw's paper that van Vliet refers to on p. 273 can be found here.

Parnas' paper "On the Criteria to be Used in Decomposing Systems into Modules" is an 
absolute classic of software engineering. It pours a lot of timeless wisdom into just six 
pages. A web search yields many sources (I would not be surprised if it is in the top ten 
of most referenced papers). Here is the first that Yahoo yielded me.

A few weeks ago Prof. Vesonder mentioned in his notes a review technique of posting 
information on a wall. This is a very interesting area to explore, especially in trying to 
solve the problem of establishing a common vocabulary and understanding - to "get 
everyone on the same page" so-to-speak.

Here are two sources I think you might find interesting:

I'm an "information design" nerd and enjoy following the work of people in the ID and 
information architecture fields (IA). I've always enjoyed the work of Marc Rettig. Here is 
one take on the "wall" process as applied to product design.


For a more formal take on the "wall" process, including aspects that computer scientists 
can relate to, I recommend David Straker's excellent book on getting maximum 
collectively derived information using quite cheap materials.


In the future we will have wall-sized displays and software support that maximizes this 
resource. I expect such techniques will become increasingly popular as the cost of 
making changes decreases in these models as a result of this support.

Is there an architect in the house?

Julia Ryan, from my Stevens Architecture and Design class, wants to know how many software system projects use architects. Do you use them in your company?  Does it matter if it is a new or existing project?  Exert some care in your answer, since there arre many companies that provide the title of architect, but use it to mean a variety of tasks.  An architect for the purposes of this discussions matches Fred Brooks notion, that there is a single architect for a project that defines and fosters the conceptual integrity of the product.  Follow the link to get more information on what Brooks means.  We would appreciate your comments.  My development groups, regardless of size use an architect.  Later!

Julia Ryan's post:

Architecture is a fuzzy subject for me.  I think that the fuzziness stems from the fact that I have not been exposed to architecture at work.  I work on large software programs so I am surprised that I haven't seen it.  I wonder if it is because I work on legacy systems?  By legacy I mean, the code was originally developed years ago, and we are currently working on software upgrades (adding/removing functionality, code improvements, etc).  Or is it because Architecture is not yet widely practiced?  I'm curious to see if other organizations employ architects and architecture development on their programs and if they do, to what extent?

European Vacation

No, not the National Lampoon movie!  This post is a vacation from the predominant way developers view Object Oriented design and development, that is, not only as a design methodology but also as a vehicle for reuse.  After a slow start in generating reusable artifacts, the patterns movement has certainly provided a great deal of success in reuse and has greatly influenced, if not dominated,  the teaching of Object Oriented design and development.

In the European School of programming, also known as the Scandinavian School of programming design and development is considered to be modeling and simulating a real or imaginary part of the world through objects and classes. The focus was on developing this model, not on reuse.  You can find a description of the thought behind it here.  Kristen Nygaard is considered to be the founder of the Scandinavian School of programming.  His site is fascinating and it is particularly interesting how during his life he combined his work in Object Oriented research and computer science (which he preferred to call Informatics) with his interest in social issues.  An example of this unique combination can be found in this paper by Nygaard.

Nygaard along with Ole-Johan Dahl developed the first family of OO languages, Simula.  For those of you who are programming language mavens, beta is a more recent effort. 

There is much more to say about Nygaard, Dahl and the entire Scandinavian school of programming.  In fact I am considering it as a potential book (or at least long paper) project.  This will not be the last post on the school in this blog.  If you have other links, papers or experience with the Scandinavian/European school of Object Oriented programming and design, share them in a comment.  Later!

Useful Use Cases

Requirements elicitation and representation is always difficult, especially when the results need to be understood by two potentially diverse populations: the stakeholders (users, management, customers, ...) and the architects, designers and developers of the system. Use cases, emphasizing scenarios, are a great middle ground for representing large hunks of the requirements in a style that is both understandable to the stakeholders and specific enough for the technical community charged with architecting, designing and implementing them.

Use cases were introduced by Ivar Jacobson in his book, Object-Oriented Software Engineering: A Use Case Driven Approach, ISBN:0201544350. However, if you are not ready to purchase the book for $60, a great free resource on Use Cases is Rebecca Wirfs-Brock's OOPSLA 2002 tutorial, The Art of Writing Use Cases. You can download a copy of it here. Wirfs-Brock's site is an excellent resource for many OO requirements, design and architecture topics. Definitely worth browsing.

If any one has had experience using Use Cases or knows of further resources, I would appreciate it if you would add a comment. Later.

Reliable Advice

Attached is a description of the new edition of John Musa's book, Software Reliabilitiy Engineering: More Reliable Software Faster and Cheaper. Thanks to Professor Bernstein for forwarding John's notice to me. Software reliability is one of the key "ilities" (along with usability, enhance-ability, ...) of interest when developing a software architecture. John's book has been a classic in this area and provides the reader with tons of practical advice and even free software to deal with software reliability issues.

Has anyone else used or read Musa's book? I would be interested in your comments. Later!

Musa's description of the book:

The new edition of "Software Reliability Engineering: More Reliable Software Faster and Cheaper," now available, focuses on making software practitioners more competitive without working longer. This is a necessity in a world of globalization and outsourcing where professionals want more time for their personal lives.

John D. Musa has written what is essentially a new book. It reflects the latest software reliability engineering (SRE) practice. Reorganized and enlarged 50% to 630 pages, the material was polished by thousands of practitioners in the author's classes at a wide variety of companies worldwide.

One of the book's new features is a series of workshops for applying each area that you learn to your project. The frequently asked questions (answered, of course) were doubled to more than 700. All the popular features of the previous edition have been updated and rewritten. These include the step-by-step process summary, the glossary, the background sections, and the exercises. The user manual for the software reliability estimation program CASRE, downloadable at no charge from the Internet, reflects the latest version. The list of published articles by SRE users of their experiences now numbers more than 65. Everything is exhaustively indexed to make the most detailed topic easily accessible to those using it as a deskside reference.

The book separates basic practice from special situations for faster learning. Musa presents the material in a casual, readable style, with mathematics placed in separate background sections. All this was done to make the book especially effective for self learning. It also furnishes everything you need to implement SRE in your organization, even discussing the most effective methods of how to persuade people to adopt the practice.

One of the first Print on Demand (POD) professional books, it is coupled with a web site where you can browse and order the book. The web site has a complete detailed Table of Contents and extensive samples from the book that simulate the bookstore browsing experience. POD uses the latest automated technology to custom print each order and ship it anywhere in the world. It is as fast as you can obtain a traditionally published professional book. The cost is similar. POD technology makes it economic to keep the book in print for as long as even a handful of people want it.

Musa is one of the founders of the field of software reliability engineering. He is an IEEE Fellow and is Engineer of the Year in 2004. Listed in Who's Who in America since 1990, Musa is a prolific researcher, international consultant and teacher, and experienced and practical software developer and manager. ACM Software Engineering Notes noted for the first edition, "The author's experience in reliability engineering is apparent and his expertise is infused in the text."

The book, published by AuthorHouse, comes in hard cover and paperback editions. It contains 630 pages, including prefaces and appendices.

Virtually Real

This next student logbook post should provide some interesting discussion. Julia Ryan poses an interesting situation in which the simulation architecture may be driving the real architecture rather than serving as a testbed for it. Advice on how to balance the simulator with the real is appreciated. It also would be interesting to hear your simulator experiences. Thanks and later!

Julia Ryan's entry:

I recently supported a Horizontal Integration Meeting for my program where different segments of the program were presenting their status, assumptions, issues, and paths forward. One issue that was brought up from the Modeling and Simulation (M&S) group. The issue is that the simulation architecture is currently ahead of the real architecture. The worry here is that the simulation architecture may drive things that we may not want in the real architecture. I'm just curious if anyone has come across this before? If yes, how was it dealt with? Was it a major issue?

Far Out Architechture

This entry follows up on a previous post with regard to NASA's efforts in software architecture and design (Software for the Stars). I am now reading through the articles referenced and found a gem by Dvorak, Rasmussen, Reeves and Sacks, Software architecture themes in JPL's mission data system. You can get the paper here.

This paper is a great discussion of an architectural approach using a state-based architecture. The authors detail their efforts to decrease coupling between modules through using coordiantion services and the examples they provide are easy to understand and serve to illustrate nicely the architectural point emphasized. They also introduce in the paper 13 themes of the architecture describing each and illustrating by example. Some examples of these themes are: construct subsystems from architectural elements, not the other way around; system state and models form the foundation for monitoring and control; express domain knowledge explicitly in models rather than implicitly in program logic; for consistency, simplicity and clarity separate state determination logic from control flow; design interfaces to accommodate foreseeable advances in technology etc. All of this is then modeled in the UML.

This paper is highly recommended. I am definitely using it in my architecture and design class and, since the writing is so accessible, I may even use it in the intro to software engineering class. If any of you get a chance to read (its other nice attribute is that it is short, 6 pages), I would be interested in your comments. Later!

Evolving Architecture

One of my former students asked a great question on architecture and architecture reviews. The question, the answer, and some further elaboration by Joe Maranzano, an expert in architecture and architecture reviews follow these short notes.

Establishing a discipline of architecture reviews relatively early in the software development process is a great idea. The paper by Starr and Zimmerman (get it here) “A blueprint for success: Implementing an architectural review system.” www.stqemagazine.com, 2002, is a great introduction to architecture reviews. I will keep you posted on further sources of information on architecture reviews.

Enough background, here's the question, answer, and Maranzano's additional comments.

1. Does any sort of review only occur after the particular task reviewed is completely finished? That is, after the architecture review is done is it still possible to add to or change the architecture .. or should that be avoided?

Of course if the review suggests changes or deficiencies the architecture should be adjusted to accommodate them. Tuning can still be done until design, any changes after that have a ripple effect -- the design has to be changed and code and ... . Bottom line the general architecture should not change after the review but knowledge during the design/development process may cause adjustments. And there are exceptions, if you are using very new technology the architecture may change as you discover how it really works during development. We sometimes refer to that type of project as advanced development, and generally use our top staff on it. I think the key is that the architect (and there only should be one) should shepherd her architecture through development and testing -- so a simple answer is the architect should not change, the architecture may change but this should be done carefully.

Joe added: "You might want to mention that if some portion of the architecture has to change (e.g., due to design discoveries or economic impact of the solution) that a review of that portion of the architecture can and should be done."

Hope you found this interesting and, as always, comments are welcome.

Later.