Researchers Showing Interest in AADL Standard

In a recent paper, Peter Feiler, technical lead and author of the Architecture Analysis and Design Language (AADL) industry standard notation, points out that more than 160 publications in refereed conferences and journals have been published about the standard since it was published in 2004 by SAE International. An updated version was published in 2009. In his research brief, Peter provides detail on the development of AADL and on MetaH, a precursor to the standard.  

Link Roundup: January 25, 2010

Good morning all,

Welcome to our January 25 Link Roundup. Here are some notable posts from other software engineering blogs that you may have missed this past week:

Stakeholder-Specific Communication, by Michael Stal at Hitchhiker’s Guide to Software Architecture and Everything Else. Michael’s thoughts on stakeholder-specific communication are applicable to a wide range of software architecture issues.

Why Microsoft and Intuit Need Each Other’s Clouds, by Phil Wainewright at Software as Services. Phil discusses the functionality and limitations of the cloud platform.

Tim Brown on Design Thinking, by Peter Cripps at Software Architecture Zen. Peter provides a link to and a summary of a TED podcast with Tim Brown, CEO of IDEO.

It’s the Services . . .

“SOA met its demise on January 1, 2009.”

That announcement in a Burton Group Application Platform blog is the starting place for many comments in the past year on the health of service-oriented architecture (SOA).

“The blog headline does say ‘SOA is dead,’ which is wrong. But the part of the headline that few people note is ‘long live services,’” according to Grace Lewis, a senior researcher at the Carnegie Mellon Software Engineering Institute (SEI). Lewis and others have developed a research agenda for SOA (View a presentation on the agenda.)

While wrong in writing off SOA, the obituary does point out something important for the future. “We need to move away from considering SOA as a set of technologies to embrace service-orientation as a way to design, implement and deploy systems,” Grace says.

Grace points out that these “pillars of SOA adoption” are essential for success with SOA:

• alignment with mission and business goals
• instantiation of principles of SOA governance
• evaluation of relevant technologies for SOA implementation
• recognition that SOA requires a different mindset than traditional development

All in all, “The technologies to implement SOA will most probably change over time, but the concepts will remain,” Grace predicts.

Architecture design from the trenches (Changes of operations in interaction diagrams)

I am working with Bursatec, the technology company of the Mexican stock exchange on the architecture design for a new system. Bursatec is using the SEI’s Attribute-Driven Design (ADD) method embedded in a Team Software Process (TSP) environment for designing the new system. They also use the tool “Enterprise Architect” for documenting the system’s software architecture.

Last week, when working with Bursatec’s architecture team, they showed a nice little rule they implemented for using the design tool. Since I believe that many architects have the same problem when using a design tool, I thought it would be worthwhile sharing their solution.

Link Roundup: January 18, 2010

Good morning all,

Welcome to our January 18 Link Roundup. Here are some notable posts from other software engineering blogs that you may have missed this past week:

How Cloud Collaboration Changes the Way Software Developers Work, by Phil Wainewright at The Connected Web. This seven-minute podcast interview with Michael Knighten, director of hosted services at Atlassian, discusses the ways in which cloud computing affects software developers.

Non-Functional Architectural Woes, by Udi Dahan at The Software Simplist. Udi muses on functional and non-functional requirements and how they move from the problem to the solution domain.

Evolving Architectures, Part 1: What’s Software Architecture, by Arnon Rotem-Gal-Oz at Dr. Dobb’s CodeTalk. Arnon spends some time explaining his own thorough definition of software architecture.

Software Engineering, for End-User Programmers?

Research discussed at WEUSE V: The 5th Workshop on End-User Software Engineering indicates that, in the US, there are about four times as many people who do programming at work (12 million) as there are professional programmers (3 million). Add in another 55 million of us who use spreadsheets and databases (and thus may also be considered to be doing programming) on the job, and that means there’s probably a lot of undependable, error-riddled software being created. As workshop participants noted: “When the software that end users create is not dependable, the people whose retirement funds, credit histories, e-business revenues, and even health and safety rely on decisions made using that software can face serious consequences.”

The workshop participants discussed end-user programming with a specific focus on the software engineering that is required to make it a more disciplined process, while still hiding the complexities of greater discipline from the end user. Proceedings from the workshop are available in a report at http://www.sei.cmu.edu/library/abstracts/reports/09sr015.cfm.

One approach reported on in the workshop: distributed cognition, advanced by Margaret Burnett et al. From the SEI report: “Thus, instead of trying to build systems that solve this type of problem: ‘What can the system figure out automatically so that users need not think too hard?’, [the] distributed cognition perspective is that the problem statement becomes: ‘How can end-user software engineering tools help end users think?’ “

Link Roundup: January 11, 2010

Good morning all,

Welcome to our January 11 Link Roundup. Here are some notable posts from other software engineering blogs that you may have missed this past week:

Architecture for a New Decade, by Peter Cripps at Software Architecture Zen. Peter notes that three of the top ten strategic technologies for 2010 include cloud computing, advanced analytics, and social computing.

Tips from 2009 for a Prosperous 2010, by Phil Wainewright at Software as Services. Phil reflects on viral marketing, predictable and diversified revenue streams, as well as the importance of a strategy that includes real business value for both investors and consumers.

Trends for 2010, by J.D. Meier at J.D. Meier’s Blog: Software Engineering, Project Management, and Effectiveness. J.D. outlines a roadmap of software engineering for 2010 and beyond.

REST: Tying AJAX to the Cloud, by Martin Heller at Strategic Developer. Martin sees 2010 as the year of AJAX and REST services, and examines the difference between the “cloud” and the “server.”

SEI Webinar Jan 21: Mike Gagliardi, System of Systems (SoS) Architecture Evaluation and Quality Atrribute Specification

Thursday, January 21, 2010
Time: 1:00 PM – 2:00 PM EST
Cost: Free

Abstract

A system of systems (SoS) can experience costly rework, schedule overruns, and the failure to achieve performance goals–from problems that surface late in the development life cycle or after the SoS is in operation. One prominent reason for these severe integration and operational problems is inconsistency, ambiguity, and omission in addressing quality attributes in SoS architectures (and in their constituent system/software architectures). Examples of quality attributes are performance, availability, reliability, security, safety, and interoperability.

SEI senior researcher Mike Gagliardi shares an SoS architecture definition and evaluation approach that involves stakeholders in augmenting end-to-end mission threads with quality attribute considerations. This approach yields architectural challenges and risks that can be mitigated earlier in the development life cycle, when they are much less expensive to resolve.

Register.

From the Trenches: “Real” Real Options in Large-Scale Agile Development

An option is defined as the right, but not the obligation, to take an action in the future. In order to gain this right, one has to spend some upfront cost, which is buying the option. The option is an asset, hence it has value. The higher the uncertainty around the decision tied to the option, the more valuable the option–obviously because it gives the right to walk away and incur just the cost of buying the option. The real options method applies financial options theory to quantify the value of flexibility in real assets and business decisions. And both common sense and the theory demonstrate that the higher the uncertainty, the more it makes more sense to wait to act and defer the decisions.

So far, so good?

Yes, only if you are sure you have bought the option and have accounted for the cost of doing nothing today. This is where the agile mindset and architecture reasoning start diverging , when in fact they could be the best of friends.