SEI Insights

SATURN Blog

SEI Architecture Technology User Network (SATURN) News and Updates

How has something you learned or saw at SATURN changed how you develop software? Since the first conference in 2004, SATURN has been a place for software developers to share stories about our adventures in building software. Architects, managers, and programmers from across industries and the world came together once a year to share stories about our experiences applying software architecture-centric practices.

Call for Papers, Tutorials and Technical Briefings, and Student Research Competition

MobileSoft 2015 -- 2nd ACM International Conference on Mobile Software Engineering and Systems http://mobilesoftconf.org/2015/ May 16-17, 2015 Firenze, Italy Co-located with ICSE 2015 May 16-24, 2015 http://2015.icse-conferences.org RESEARCH PAPERS AND SHORT PAPERS ================================ Important Dates ===============

Consensus Algorithms and Distributed Systems Consensus algorithms for distributed systems represent a growing field focused on increasing the efficiency of these systems while decreasing their vulnerability to attack and component failure. These recent blog posts offer some theory and practice on consensus algorithms. The Space Between Theory and Practice in Distributed Systems: Marc Brooker at Marc’s Blog discusses the gap between theory and practice in materials on distributed systems, using consensus algorithms as an example. Much material exists on the theory end of the continuum; much exists on the practice end of the continuum. What’s in the middle?

One of our goals every year with SATURN is to create a solid technical program that is informative, engaging, and lasting. When evaluating proposals for the program, the review committee uses the following guidelines to help decide whether a proposal is a good match for this year’s conference. In these guidelines, the term “session” is used generically to describe any talks, workshops, tutorials, and so on in the conference program. Informative sessions share meaningful insights with lessons that attendees will be able to apply directly with their teams after the conference.

  • Is the information proposed relevant to one of the topic themes in this year’s conference?
  • Are there succinct lessons supported by real-world examples, research, or direct experience?
  • Is the topic of broad or general interest?
  • Can the lessons be applied beyond small sub-communities of practice?
Engaging sessions create an active learning environment that promotes information retention and generally gets attendees excited about the topics discussed.

The SEI Architecture Technology User Network (SATURN) Conference 2015 will be held at the Lord Baltimore Hotel in Baltimore, Maryland, April 27--30, 2015. We are pleased to announce that the co-technical chairs of SATURN 2015 will be George Fairbanks of Google and Michael Keeling of IBM. Based on your feedback in the hallways in Portland and from post-conference surveys, George, Michael, and the rest of the SATURN technical committee have designed SATURN 2015 to better meet your needs in a practitioner-oriented technical conference. The SATURN 2015 Call for Submissions is now open. As described in the Call, we will immediately begin a rolling-acceptance process for proposal submissions, so submit early to get feedback and improve your chances.

What’s New for 2015

Microservice Architecture Since James Lewis and Martin Fowler published their article on Microservices in March 2014, the microservices architecture pattern has been the subject of much debate in the blogosphere: Is there a good definition for it (or not), is it another form of SOA (or not), is it an answer to the monolith (or not), is it a fad or the next big thing? The following blog posts contribute to the discussion on some of these topics. Failing at Microservices: Please avoid our mistakes!: Richard Clayton’s Unrepentant Thoughts on Software and Management recently included a blog post about his team’s attempt to implement a microservice architecture, four reasons why it failed, and some recommendations for avoiding these problems. Microservices for the Grumpy Neckbeard: Chris Stucchio discusses what he sees as the two camps of the debate about microservices, the hipsters who see their many benefits and the neckbeards who are more suspicious, and describes an architecture that may serve to bring the two camps together.

By Jørn Ølmheim and Harald Wesenberg Statoil ASA We were fortunate enough to be able to participate at SATURN 2014. For Jørn, this was his first time at SATURN, while for Harald it was the fourth SATURN conference. As always, we knew that the quality of the conference content is high, and we were looking forward to a fun week with learning new and interesting ideas from other practitioners. In this group of excellent presentations and tutorials there were many that stood out, but to us George Fairbanks' talk on teaching architecture was definitely one of the greatest. Many of the more experienced participants at the conference recognized George's experiences of trying to teach the importance of architecture to the junior team members with varying degree of success, so we were well motivated for a discussion about how this can be done better. Many of us recognize the challenges of motivation and lack of commitment both from your peers and the company to spend time on such activities.

DevOps: Definitions and Misconceptions This month, Ben Kepes at Forbes reported on ScriptRock’s efforts to raise funding from investors to expand their operations in “To Help DevOps-ify The World.” Kepes opens with an explanation of how ScriptRock must first differentiate its product and services from vendors selling “DevOps in a box.” More agile software development in less time, however, may not fit neatly in that box. Here are some links to definitions of DevOps that include components that exist outside of the box. Defining DevOps Might Be Harder Than Defining Design: In the Under Development podcast series, Bill Higgins and Michael Coté explain DevOps, metrics, and “the processes used by designers vs. software developers vs. management consultants vs. wedding planners.”