Tag Archives: architecture evaluation

Architecture Boot Camp at SATURN 2015

As the field of software architecture has matured over the years, its concepts and terminology can be barriers to newcomers. In past years, the SATURN program was geared toward those who had attended SEI courses or had otherwise steeped themselves in the canon (a pretty hefty bookshelf). For those who had not yet done so, the SEI offered its introductory courses before the conference began.

This year, at no additional cost, the SATURN 2015 technical program includes a series of sessions intended for beginners, novices, and aspiring software architects. This Architecture Boot Camp will be held early in the conference program and led by experienced instructors from the SEI technical staff. You don’t have to attend every Boot Camp session, and you can interleave them with the main schedule.

Continue reading

Advertisements

Coming November 3-6, 2014, Pgh. Pa.: TSP Symposium 2014

We at the SEI are excited about the Team Software Process (TSP) Symposium, which we are holding in Pittsburgh, Pa. November 3-6, 2014. The theme of the symposium is “Going Beyond Methodology to Maximize Performance.”

By this, we mean that the technical program goes beyond the core methodology of TSP to encompass a broader range of complementary practices that contribute to peak performance on system and software projects.

As part of our strategy to expand the scope of the symposium and bring in more architectural thinking to those who have adopted TSP and are using it, we’ve added several architecture-related sessions to the technical program. We at the SEI have seen how successful combining TSP and architecture-centric engineering approaches can be in the project we undertook with Bursatec, the technology subsidiary of the Mexican stock exchange.

Continue reading

Architecture Analysis Using AADL: A Beginner’s Perspective

Introducing new software languages, tools, and methods in industrial and production environments incurs a number of challenges. Among other necessary changes, practices must be updated, and engineers must learn new methods and tools. These updates incur additional costs, so transitioning to a new technology must be carefully evaluated and discussed. Also, the impact and associated costs for introducing a new technology vary significantly by type of project, team size, engineers’ backgrounds, and other factors, so that it is hard to estimate the real acquisition costs.

This blog post at the SEI blog presents research conducted independently of the SEI that aims to evaluate the safety concerns of several unmanned aerial vehiclesystems using the Architecture Analysis and Design Language (AADL) and the SEI safety-analysis tools implemented in OSATE.

SATURN 2014 Promoting Quality Attributes: Lessons Learned from the Trenches Session (notes)

Notes by Ziyad Alsaeed, edited by Tamara Marshall-Keim

Can You Hear Me Now? The Art of Applying Communication Protocols When Architecting Real-Time Control Systems
Todd Farley, BAE Systems, Inc.

BAE Systems deals with architecting real-time control systems. These systems are usually complicated and distributed. Also, the lifetimes of projects are usually very long. So BAE must always answer this question: Which process should they adapt? The problems they face tend to fall into three categories:

  • motion control systems (~robots)
  • computation-intensive algorithms
  • user interfaces

Continue reading

SATURN 2014 Line-up of Tutorials

by Neil Ernst, SATURN 2014 Tutorials Chair

We have a great tutorial line-up this year that I would like to share. Since tutorials at SATURN are half-day sessions, they provide the presenters time for an in-depth exploration. I think attendees of SATURN 2014 will be particularly impressed by the breadth and depth of our program.

On Tuesday, May 6, we have five tutorials scheduled.

  • George Fairbanks, Google, and author of Just Enough Software Architecture, will cover “Architecture Hoisting” (T1), techniques for moving responsibility from the code to the architecture.
  • Stephany Bellomo and Rick Kazman, from the Software Engineering Institute, in Tutorial T2, will introduce deployability and DevOps techniques, then discuss architectural approaches and patterns to reduce build time and shorten the feedback cycle.
  • In the afternoon sessions, Len Bass, of Australia’s National IT Research Centre, will discuss the implications of DevOps on system design (T3). For example, how does moving to a continuous-deployment approach change how the architecture is designed and implemented? This makes a nice complement to the earlier tutorial from Bellomo and Kazman for those desiring a full menu of deployability fare.
  • Pradyumn Sharma (@PradyumnSharma) of Pragati Software will cover NoSQL databases (T4). If you’ve been hearing this term for a few years now and need to really get a good sense for the landscape, Pradyumn will cover the fundamentals for you, basing the session on real-world examples.
  • Finally on Tuesday, Eltjo Poort (@eltjopoort) of CGI will cover the CGI Risk and Cost-Driven Architecture approach (RCDA) in T5. He will discuss how CGI has used RCDA to implement lean and agile architectures in their global software business. RCDA is a recognized architecture method in The Open Group’s architect certification program.

Continue reading

Best of SATURN: A Curated Selection from Jeromy Carriere (Google)

Jeromy Carriere of Google, member of the SATURN 2014 Program Committee and previously featured speaker at SATURN, dug through presentations from previous years at SATURN and put together a list of some he found valuable:

Invited talk: Games Software Architects Play (Phillippe Kruchten)
“The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partially in the dark.” Phillippe takes us on a tour of some of the ways that we make bad decisions: cognitive biases, reasoning fallacies, political games. Sadly, each example resonates with me, and not just because I’ve seen them in other people. Architects have to rely on intuition, but we also need to know when and how it fails us.

Continue reading

SATURN 2014 Call for Submissions

SATURN 2014 marks the 10th Software Engineering Institute (SEI) Architecture Technology User Network (SATURN) conference—the largest conference dedicated to software architecture in North America. Since 2003, an international audience of practicing software architects, industry thought leaders, developers, technical managers, and researchers have gathered at SATURN to share ideas, insights, and experiences about effective architecture-centric practices for developing and maintaining software-intensive systems.

SATURN 2014 will take place in Portland, Oregon from May 5—May 9, 2014.

Continue reading

SEI Architecture Training in Los Angeles

This September, the SEI will be coming to Los Angeles to offer two onsite professional development courses, Documenting Software Architectures and Software Architecture Design and Analysis. Successful completion of these two courses fulfills two of the four requirements toward the SEI Software Architecture Professional Certificate, which can help you gain the skills and acquire the experience to enhance your career.

Continue reading

SATURN 2013 Governance and Education Session (notes)

Notes by Ian De Silva

Software Development Improvement Program: Enabling Software Excellence at a Hardware Company
Sascha Stoeter, ABB

ABB has historically been a hardware company, but it has been slowly increasing the amount of software development it does since the 80s. It is a distributed company (in 34+ countries) with software embedded into products such as controllers. Each team has its own set of tools to support development efforts.

Continue reading

SATURN 2013 Architectural Evaluation Session (notes)

Notes by Brendan Foote

All Architecture Evaluation Is Not the Same: Lessons Learned from More Than 50 Architecture Evaluations in Industry
Matthias Naab, Jens Knodel, and Thorsten Keuler, Fraunhofer IESE

Matthias has evaluated many systems’ architecture, ranging from tens of thousands of lines of code to tens of millions, and primarily in Java, C++ and C#. From this he distills out commonalities in the various stages of the evaluations. To start with, the initiator of the evaluation was either the development company or an outside company, such as a current customer or a potential one. The questions being asked also varied—whether wondering if the architecture is adequate for one’s solutions, what the impact would be of changing the system’s paradigm, or how big a difference there was between a system and the reference architecture.

Continue reading