PATTERN LANGUAGE

Modeling, Managing, Making it Right.

September 2006

Although the paper "Responsibilities of a Software Architect" has been around for a while, it is worth reviewing--particularly since questions still arise on what exactly a software architect does seems to crop up.

In a nutshell:

A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies user requirements, and achieves the desired results under given constraints.

For more detail, my favorite topics (in no particular order) are:

• An architect abstracts the complexity of a system...
• An architect sets quantifiable objectives...
• An architect acts as an agent of change...
• An architect progressively makes critical decisions...

Of course, a software architect does a lot more than this--as you'll see when you go to SoftwareArchitectures.com for details about on what I've briefly introduced.

Posted by Jon Erickson at 05:22 PM  Permalink |

The Software Engineering Institute (SEI) has announced the formation of the System-of-Systems Test and Evaluation Consortium (SoSTEC) to develop technology for identifying conclusions about the functionality, reliability, dependability, performance, and safety of systems of systems.

In short, the goal of this SEI-managed consortium is to generate new understandings and consensus about the nature of the problem, promising approaches, and additional research that would have significant payoffs.

"The vision for network-centric warfare and network-centric operations radically changes the current approach to developing and deploying systems," explains Patricia Oberndorf, director of the Dynamic Systems Program at the SEI and leader of the effort to organize the SoSTEC. "Traditional engineering techniques for both systems and software will not be able to completely meet the system-of-systems test and evaluation need."

According to the SoSTEC vision, in the service-oriented architecture (SOA) concept, services -- not systems -- will be deployed and composed dynamically into systems. These services become the components of future systems, but at the time of a service's deployment no one will know or be able to anticipate all the other services and components with which it might be combined.

Consequently, SoSTEC examines the issues related to how we develop sufficient confidence in the quality of systems of systems. Traditional engineering techniques for both systems and software -- including conventional test and evaluation approaches -- will not be able to completely meet the system-of-systems test and evaluation need for at least the following reasons:

• It is unclear what it means for a system of systems to fail.
• Even given operational scenarios defining the expected capabilities of a system of systems, the amount of testing required to develop any degree of confidence in the system (using the usual statistical approaches) would be prohibitive in time and expense.
• Systems of systems are so large that they are always undergoing changes. It is unclear what techniques should be used to ensure that changes do not have unexpected emergent effects.
• Different users expect/need different qualities of service in different situations.

The consortium will be composed of representatives from a spectrum of organizations dealing with the difficulties of testing systems of systems, including:

• Organizations responsible for evaluating the suitability of systems of systems (e.g., U.S. Department of Defense test and evaluation organizations)
• Organizations responsible for developing such systems (e.g., defense contractors, large healthcare organizations, and organizations that have established net-centric or SOAs for their own purposes)
• Academic researchers who are addressing the system of systems T&E problem (by invitation)

Posted by Jon Erickson at 12:13 PM  Permalink |

The SEI's Software Engineering Measurement and Analysis (SEMA) Initiative has completed its first survey to gauge the state of the practice in software measurement.

The objectives of the survey were to characterize:

• The degree to which software practitioners use measurement when conducting their work.
• The perceived value of measurement.
• Approaches that are used to guide how measures are defined and used.
• The most common types of measures used by software practitioners

The results of the survey provide an indication of the measurement implementation approaches being used by the community. They also point to behaviors that are promoting or preventing the effective use of measurement.

Posted by Jon Erickson at 12:21 PM  Permalink |