Certification programs for software architects abound. How can you tell which programs best measure an architect’s capabilities? Or which ones are right for you? SATURN 2010 plans a track on architecture certification to pull together details on certification programs.

…says CNN/Money.com.

In the CNN/Money list of top-paying jobs, software architect ranked No. 8. Likewise in the list of least stressful jobs.

At the SEI’s software architecture website, you’ll find modern, classic, and bibliographic definitions of “software architecture,” as well as definitions contributed by visitors to the site.

– Bill Pollak, SEI

For those interested in the relation between usability and software architecture, my colleague in this work–Bonnie John of the Human Computer Interaction Institute at Carnegie Mellon University–gave a talk a while ago at Stanford on the work. You can see her talk on YouTube:

Usability and Software Architecture: The Forgotten Problems

- Len Bass, SEI

“The push to promote cloud computing is part of the Obama administration’s effort to modernize the government information technology systems,” according to a September 15, 2009 New York Times article highlighting the unveiling of Apps.Gov, a virtual storefront run by the General Services Administration where federal agencies will be able to purchase cloud computing applications and services such as productivity software, storage, and web hosting.

Cloud Computing is being adopted by commercial, government, and Department of Defense organizations, driven by a need to reduce the operational cost of their information technology (IT) resources. From an engineering perspective, cloud computing is a distributed computing paradigm that focuses on providing a wide range of users with distributed access to virtualized hardware and/or software infrastructure over the Internet. From a business perspective, it is the availability of computing resources that are scalable and billed on a usage basis as opposed to acquired, which leads to potential cost savings in IT infrastructure.

The goal of this introductory-level presentation is to define cloud computing, types of clouds, and types of cloud-computing environments. Grace Lewis of the SEI will then focus on the drivers and barriers for cloud-computing adoption and will compare cloud computing with other existing computing paradigms.

About Grace Lewis

Grace Lewis is a senior member of the technical staff at the Software Engineering Institute. She is currently the lead for the System of Systems Engineering team within the System of Systems Practice (SoSP) initiative. Her current interests and projects are in service-oriented architecture, technologies for systems interoperability, modernization of legacy systems, and characterization of software development life cycle activities in systems of systems environments. Her latest publications include several reports published by Carnegie Mellon University on these subjects and a book in the SEI Software Engineering Series. She is also a member of the technical faculty for the Master in Software Engineering program at Carnegie Mellon. Grace holds a B.Sc. in systems engineering and an executive MBA from Icesi University in Cali, Colombia; and a Master in Software Engineering from Carnegie Mellon.

You can register for this webinar here.

We’re excited to announce that acclaimed author and leader of the Agile movement Jim Highsmith will be a keynote speaker for the SEI Architecture Technology User Network Conference (SATURN 2010), May 17 – 21, 2010 in Minneapolis, Minn.

Jim Highsmith is coauthor of the Agile Manifesto, a founding member of the Agile Alliance, coauthor of the Declaration of Interdependence for project leaders, and co-founder and first president of the Agile Project Leadership Network. In his 1999 groundbreaking book Adaptive Software Development, which received the Jolt Award in 2000, Highsmith stated that “rules can be barriers to hide behind or guidelines for the wise to consider and break when the circumstances justify it.”

We at the SEI are hosting SATURN 2010 in collaboration with IEEE Software magazine, which will publish selected papers from the conference. The call for participation submission deadline is Monday, November 9, 2009. For more information, see this SEI press release.

The intersection between Agile and architecture-centric engineering has been the subject of several posts here at the SATURN blog. Agility and the ability to respond to change have become key architectural drivers across the software industry, and the agile software-development community has increasingly been addressing how to scale agile development techniques for large-scale, multi-year projects. This year, SEI staff members have begun a research project about the benefits of architecting within agile-development projects. We will be reporting here about the progress and results of this research project in a new feature that we will call “From the Trenches.” We hope you will stop by, and we’ll welcome your participation through our comments threads.

- Bill Pollak, SEI

This article in the New York Times discusses a strictly computer-science aspect of ultra-large-scale systems.

The community has done a good job in describing and understanding techniques for achieving operational qualities. Performance, availability, security, and usability have been well studied from the point of view of definitions and techniques to achieve them.

Less well understood are developmental qualities.

Modifiability/maintainability, reuse, and portability are mentioned as developmental qualities. Developmental qualities have much to do with the partitioning and allocation of functionality. Yet there are a great many allocation or partitioning decisions that don’t fit into any discussed or described quality attribute. Here are some examples:

1) An organization wishes to get their subcontractors on contract as soon as possible. So they proceed with the contracting process. In order to have the contracts in place, the subcontractors must had defined development tasks. These tasks effectively partition the functionality. All of this before any architect is even hired, let alone before an architecture is defined. – Contractability?

2) An architect designs a system cleverly and the design does not need a data base. His manager convinces the architect that a data base system is needed because there is an expensive data base group that currently has no tasks. – Databasability?

3) A design excludes the use of threads because the staff has no experience with threads. – Threadability?

4) Time to market considerations cause the use of a legacy component that has much more functionality than required. – Hurrability?

I am sure there are other examples out there. My point is that we have advocated a design process that assumes we begin with the necessary functionality and the important quality attributes and proceeds from that premise. The reality is that frequently, partitioning decisions are driven by factors that are essentially irrelevant to the purpose or the quality requirements of the system.

- Len Bass, SEI

On Thursday, October 1, Len Bass of the SEI spoke on the University of Minnesota campus at a meeting of the Twin Cities Software Process Improvement Network (Twin-SPIN) about the architecture of ultra-large-scale (ULS) systems. Len’s presentation slides from the talk are now online.

The Twin-SPIN event gave us an opportunity to network with the Minneapolis academic and business communities. SATURN 2010 will be held in Minneapolis, Minn. this year on May 17-21, in collaboration with IEEE Software magazine.

I’ve been thinking about the issue of modeling and documentation. While many within the Agile community embrace the concept of “modeling with a purpose,” there is also a widespread view of documentation as an after-the-fact, template-based activity that generates unused shelfware. To me, this dichotomy can best be expressed as the difference between acting “in the heat of passion” and acting “in cold blood.”

When you’re trying to solve a problem, modeling is performed “in the heat of passion.” It’s done with a purpose; it’s done in a state of flow. The model that you draw represents just enough of the system to facilitate reasoning about the problem at hand.

When you’re working to document a problem that you’ve already solved, you’re modeling “in cold blood.” Many times the documentation is being recorded via templates or standards. In a lot of ways, templates and standards are very useful. They provide guidelines to constructing abstractions and prod the writer / modeler to consider a range of models and information for inclusion into the documentation. At the organizational level, standards and templates can facilitate exchange of information across different teams.

However, templates and standards can also have a mind-numbing effect sometimes. They can end up being “filled out” like a DMV form instead of being used to communicate a decision or concept or point that someone wants to convey. Let’s face it, no one thinks about communicating when they’re filling out a Department of Motor Vehicles form. You just want to finish up and get on out of there.

One piece of the puzzle, I think, is grappling with the issue of abstraction with respect to documentation. When you’re modeling to solve a problem, the abstractions come naturally (i.e., – you abstract enough information about the system to solve the problem at hand). When you’re doing so in cold blood, the question of what to abstract out about the system becomes, as it were, a little too abstract.

I’m not sure exactly what the answer is to the documentation issue. I don’t think tacit knowledge is enough. I’m not sure whether a collection of models created “in the heat of passion” is superior or inferior to a more comprehensive and orderly set of models constructed in “cold blood,” when it comes to conveying information to maintenance teams.

Maybe one potential solution would be for Agile teams to create “maintenance stories” as part of their sprint or iteration retrospectives. These stories could be enhanced or refactored across subsequent iterations. Maybe this approach could bring more of a team dynamic and sense of purpose to creating maintenance documentation. Perhaps it could increase the temperature of the documentation activity up to “warm-blooded” at least.

Nanette Brown – SEI

Last month I attended the Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture (WICSA/ECSA 2009).

This was the eighth WICSA offering in a series of conferences beginning in 1999.  A good summary of the journey the work in architecture has taken over the years is contained in a paper by Paul Clements and Mary Shaw on The Golden Age of Software Architecture. Paul initially put forth these ideas during a panel at WICSA 2005 that marked the 10 year anniversary of the first International Software Architecture Workshop (ISAW-1) and the 10th anniversaries of the IEEE TSE and IEEE Software special issues on software architectures.  Another good summary can be found in a paper that came out at the same time on The Past, Present, and Future for Software Architecture by members of the IFIP Working Group on Software Architecture, who also support the WICSA conference.

I have been involved with WICSA since its inception.  It is one of my favorites due to its unique nature as a working conference, the mix of research and practice, and the sense of community among the 100 plus attendees.  At WICSA this year, the emphasis was on the relationship between software architecture and “higher” level concerns such as systems of systems, enterprise architecture, and value of architecture.

The program reflected this emphasis in its series of keynotes.  Jaap Schekkerman kicked off the conference with a keynote on Why Business & IT Professionals do not understand each other and how Enterprise Architects can Bridge that Gap. Schekkerman started with the premise that the human brain has two different thinking styles (right brain/left brain).  He expanded on the idea to include the thinking styles of software engineers/architects and business people and reflected on how enterprise architects can bridge the gap between both groups. I thought this was an interesting way to approach the problem and complemented the keynote that Eoin Woods gave at SATURN 2008 on Putting Software in its Place: Classifying the Architectural Species where he approached the challenge of bridging from the roles of the different types of architects.

Eoin Woods gave a keynote of Using Design Principles to Unify Architecture and Design.  He focused his remarks on the question of how can we avoid conflict and allow enterprise architects, software architects and development teams to work together cooperatively.  He explained how the use of design principles are a unifying concept that help these different groups to work together.

Alex Wolf asked the question, Where is software architecture? in his keynote that concluded the conference.  This included questions of the sort, What is the current state of ideas in software architecture? What is the right direction to look to find promising new ideas? And, if software architecture is more than just an intellectual exercise, then where, quite literally, is it to be found in modern software systems? He offered three areas for exploration: (1) moving from the notion of a system having a single architecture to having multiple, simultaneous, intersecting, interacting, and maybe even conflicting architectures; (2) shifting the emphasis on architecture as components and connectors to understanding emergent system behaviors and better utilizing techniques such as simulation (based on models) and experimentation (based on implementation); and (3) understanding the incentives to document and discovering architecture in the ways engineers already document using deployment descriptors, manifests, configuration files, and service-level agreements, and so on.

More details of the conference and discussion on the working session topics are available at the conference wiki.

- Robert Nord, SEI