Archive: 2015-01

Continuous software evolution and delivery refers to the organizational capability to innovate and release software in fast parallel cycles, typically hours, days, or very small numbers of weeks. This requires not only adoption of more agile processes in development teams or large investments in automated release pipelines, but changes in potentially the entire research and development organization in terms of technology and practices. Furthermore, automatic live monitoring and experimentation of different system alternatives enables fast evaluation and decision making. Finally, best practices and success stories should be documented and exchanged.

The Workshop on Continuous Software Evolution and Delivery (CSED), which grew out of the successful RELENG and RCoSE workshops, aims to bring together the research communities of the aforementioned areas to exchange challenges, ideas, and solutions to bring continuous software evolution and delivery a step further to being a holistic continuous process. The workshop will be run in a highly interactive manner to stimulate discussions, featuring presentations of practitioner abstracts and academic papers, as well as break-out groups focusing on lively interactions to identify challenges, existing approaches and potential directions for solutions.

For more information, see the CSED website.

Defining Microservices

By on

I see microservices as an architectural pattern or style. Some styles are well described in the literature (Roy Fielding's description of REST is an example). Unfortunately, there was no clear description of the microservices style when it became popular. And the growing buzz has contributed to the confusion because different people try to add nice-to-have characteristics to what a microservice should be. For example, based on things I've read, one might conclude that microservices should:

  • Have few lines of code (some say 10-100 LOC).
  • Not be part of circular calls across services.
  • Be developed by a team that can be fed by 1 or 2 pizzas.
  • Avoid synchronous communication (request-response calls).
  • Offer coarse-grained operations (though microservices are "fine-grained services").
  • Be run by the team who built them.
  • Not participate in complex service compositions.
  • Have the freedom to use new languages, frameworks, platforms at will.
  • Manage their own databases.
  • Be monitored by sophisticated logging and monitoring infrastructure.
  • Be developed by teams split around business capabilities motivated by Conway's law.
  • Match DDD bounded contexts.
  • Be dynamically discovered.
  • Be small enough to be rewritten in two weeks.

Thus, requirements for a microservice are all over the place, and often mention good software engineering practices known for decades.

I'd rather stick with the well-known description by Lewis and Fowler: "the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. "

From an architecture perspective, the microservice style belongs primarily to the deployment view. It dictates that the deployment unit should contain only one service or just a few cohesive services. The deployment constraint is the distinguishing factor. As a result, microservices are easier to deploy, become more scalable, and can be developed more independently by different teams using different technologies. Beyond that constraint, other characteristics describe a lean SOA service that does not use orchestration or ESB.

Despite the lack of clarity about what microservices really are, it's exciting to see the many ideas, tools, and discussion sprung from them. I'm not sure we're past the peak of inflated expectations with microservices, but I certainly look forward to seeing what consolidated shape microservices will have when they reach the plateau of productivity. At the moment, for us software developers, more important than having a clear definition is to understand the tradeoffs of using microservices.

Microservices is one of those buzzwords that generate a lot of hype but is ill defined. In another post, I comment about defining microservices. In this post, my main goal is to discuss pros and cons of using microservices in contrast with the monolithic approach, so let's cut to the chase.

What you gain and what you lose

Benefits of using microservices:

  • Deployability: more agility to roll out new versions of a service due to shorter build+test+deploy cycles. Also, flexibility to employ service-specific security, replication, persistence, and monitoring configurations.
  • Reliability: a microservice fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith.
  • Availability: rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith.
  • Scalability: each microservice can be scaled independently using pools, clusters, grids. The deployment characteristics make microservices a great match for the elasticity of the cloud.
  • Modifiability: more flexibility to use new frameworks, libraries, datasources, and other resources. Also, microservices are loosely-coupled, modular components only accessible via their contracts, and hence less prone to turn into a big ball of mud. Dynamic discovery and binding via a registry (e.g., Apache ZooKeeper, Netflix Eureka) is sometimes used for location transparency.
  • Management: the application development effort is divided across teams that are smaller and work more independently.

Challenges of using microservices:

  • Deployability: deployment becomes more complex with many jobs, scripts, transfer areas, and config files for deployment.
  • Performance: services more likely need to communicate over the network, whereas services within the monolith may benefit from local calls. Also, if the microservice uses dynamic discovery, the registry lookup is a performance overhead.
  • Availability: if you use a registry for dynamic discovery, unavailability of the registry may compromise the consumer-service interaction.
  • Modifiability: changes to the contract are more likely to impact consumers deployed elsewhere, whereas in the monolithic model consumers are more likely to be within the monolith and will be rolled out in lockstep with the service. Also, mechanisms to improve autonomy, such as eventual consistency and asynchronous calls, add complexity to microservices.
  • Testability: automated tests are harder to setup and run because they may span different microservices on different runtime environments.
  • Management: the application operation effort increases because there are more runtime components, log files, and point-to-point interactions to oversee.
  • Memory use: several classes and libraries are often replicated in each microservice bundle and the overall memory footprint increases.

What about autonomy?

Much of what I read about microservices mentions autonomy as a benefit. For example, Sam Newman's Building Microservices book says increased autonomy is a huge advantage of microservice architecture. But what is autonomy? And why didn't I list it in the pros of microservices above (or the cons either)?

First off, there's design autonomy: how much freedom you have to design, implement, and modify a software element. But more important to our discussion is runtime autonomy: how much control a component has over everything that is executed when the component is invoked. A service that doesn't need to interact with any other components outside its boundary is highly autonomous. If a service calls another service, accesses a shared database, sends a message or event to a message broker, then it loses a little bit of autonomy. A design goal is not to get rid of these kinds of interactions, but to avoid problematic ones so that the level of service autonomy doesn't compromise performance or reliability.

And what about the autonomy of microservices? They certainly beget high degrees of design autonomy--the team can employ different technologies and patterns to design and implement each microservice, and can change and redeploy each microservice independently. On the other side, services within a monolith often have to follow the same design constraints and change+deploy cycles--less design autonomy.

As for runtime autonomy, I'm afraid the very idea of microservices goes in the other direction. We're splitting the monolith into small distributed services. The overall business logic that was once collocated in the monolith is now spread across microservices. It's more likely that a microservice will interact with other microservices over the network--that interaction decreases autonomy. If the interaction between microservices involves changing data, the need for a transactional boundary further compromises autonomy. To quote Newman, "Don't also be surprised if things like distributed transactions or CAP theorem start giving you headaches."

The good news is that much of the schooling about microservices I've seen emphasizes this apprehension with autonomy. To avoid autonomy issues, the experts advise you to employ techniques such as eventual consistency, event-driven architecture, CQRS, cache (data replication), and aligning microservices with DDD bounded contexts. My point is that these great techniques are not inherent to microservices, but are desirable to prevent service autonomy issues that are inherent to microservices.

Researchers at the Carnegie Mellon University Software Engineering Institute are seeking volunteers to participate in a study. The Quantifying Uncertainty for Early Lifecycle Cost Estimation research project is conducting a public call for participation from individuals who have recent experience executing a Department of Defense (DoD) program. This study explores how to calibrate individual and group expert judgment in the context of decisions about uncertain events within DoD programs. The study also explores the impact of those uncertain events on the cost of executing a program.

The call for participation is open now through November 30, 2015. Participants will gain knowledge of measuring expert judgment and techniques to improve their own judgments and estimations. After the experiment, participants will receive their personal test results in addition to summarized group results in a format that maintains individual confidentiality.

The experiments will be conducted across two half-days of remote participation. For more information about the experiment and to volunteer, visit www.sei.cmu.edu/quelce-experiment-cfp.

With the emergence of an increasing number of conferences and professional-development opportunities in the field of software architecture, how is SATURN unique? Why should a software engineer choose to attend SATURN 2016?

SATURN is an annual gathering of software developers, architects, and thought leaders. At SATURN 2015 last April, 80% of the attendees had 10 or more years of experience and 56% were in leadership positions in their organizations. They gather to share experiences and ideas.

The relative experience of the SATURN community makes it uniquely qualified to evaluate the efficacy and practical utility of technology trends such as service-oriented architecture (SOA), microservices, and Internet of Things in a balanced way, avoiding reflexive promotion or advocacy.

"SATURN is about keeping the tribal history of software architecture and disseminating the fundamentals beyond current skills needed," says Len Bass, formerly of the SEI and of National Information and Communications Technology Australia (NICTA). "You will always want to know about the latest tools and the hottest methods, but more importantly, you will want to understand how to recognize the underlying concepts the next time a tool or method climbs the technology hype-cycle curve."

Such architectural knowledge building at SATURN provides learning and networking opportunities that have lasting value, greater than simply becoming familiar with the latest hot technical buzzwords.

The large number of experienced and technically savvy attendees at SATURN also affords junior developers or aspiring software architects the opportunity to network and learn from those with more experience, gain a solid understanding of techniques and methods that have been validated and proven to be effective, and find solutions to problems that others have solved in similar contexts. Knowledge sharing at SATURN happens through participatory sessions, tutorials, and open office hours with the creators of foundational techniques and methods.

SATURN has also evolved to be a conference where experience and research come together to forge new solutions to pressing problems, as a forum for articulating and exploring new ideas and leading-edge thinking. For example,

  • While software architecture training is now common in many global organizations, early adopters at SATURN began taking seminal software architecture courses from the SEI and others and sharing ideas, curricula, and experiences about developing software architectures in their own organizations.
  • Long before the coexistence of agile and architecture practices became a frequent topic of discussion in other technical venues, SATURN attendees were sharing their experiences and techniques for achieving agility at scale.

"We want SATURN to be thought of as the birthplace of new ideas and innovations in architecture-design practice," says Amine Chigani of GE Digital, a technical co-chair of SATURN 2016. If you are doing something new and interesting that you have successfully applied in a practical setting and that seems promising--even if it hasn't been proven yet--we want to hear about it.

Here are some examples of talks at SATURN conferences during the past few years that exemplify SATURN's balance of proven experience and new ideas that propel the discipline forward:

Proven experience:

New ideas:

DEV@SATURN

The DEV@SATURN (Design, Engineering, Vision) talks that we have added to the SATURN technical program this year are intended to reinforce the vision of SATURN as a forum for sharing experience-based insights and articulating new ideas and innovations. Patterned after the popular TED series of talks, DEV@SATURN talks will be short, concentrated bursts of experience, wisdom, and inspiration.

We seek talks that are

  • Visionary - They open a window that reveals or makes visible the future of software design or report on a breakthrough to a new idea or new solution to what had been an intractable problem.
  • Passionate - They are delivered by a speaker with a passionate commitment and need to share a paradigm-changing idea or insight.
  • Concrete - They tell specific stories about something that the speaker has done, such as an idea or lesson realized in the course of a project, a big problem and why it is important, a report of a personal journey that led to an insight or breakthrough, or something that everyone thought was impossible until the speaker discovered otherwise.

Please consider submitting a proposal for a DEV@SATURN or a longer talk, and if you have never attended SATURN before, please join our growing community and attend SATURN 2016.

A DEV(Design, Engineering, Vision)@SATURN talk is similar to a TED talk and concisely shares a single breakthrough technique, lesson, or experience in a passionate and inspiring way. We have a few slots available for these presentations at SATURN 2016.

DEV@SATURN talks will be particularly story based with lots of colorful images, simple charts, videos, and other visual props. They will be short: you have a maximum of 15 minutes, which will force you to focus on only what matters. Speaker delivery is critical; audiences will react equally to the message and the messenger. It will help to watch a couple of TED talks to get a sense of the style. Remember, there will be a select few of these sessions in the technical program, so submit a proposal for this session type only if you believe you have the right topic and delivery style to delight your SATURN community.

Your DEV@SATURN talk will really ignite your audience when you focus on using stories and pictures. The 4D outline is a great tool to help you think about your purpose for each point and how you want to convey that point. With this tool, you can create an exciting presentation that drives home what you want your audience to remember.

We look forward to seeing your proposals!


The 12th SEI Architecture Technology User Network (SATURN) Conference 2016 will be held at the Sheraton San Diego Hotel & Marina in San Diego, California, May 2-5, 2016.

The SATURN 2016 Call for Submissions is now open.

Guest post by SATURN 2016 Program Committee Bett Correa, Architect at GE

So you are excited about presenting at SATURN 2016? Awesome!

One key question to ask is whether the audience will remember your presentation after the conference. There are a few tips I'd like to share that can help you give a memorable presentation.

When giving a presentation, focus on your audience and your purpose. Audience members may be saturated from having taken in so much information during the conference. You will leave a memorable impression on them only if you carefully construct your presentation. Grabbing their attention right from the beginning will help them realize that you are worth listening to. Make each slide purposeful. This might sound daunting but can be accomplished using a simple format I created called the 4D outline.

Before getting into the outline, define the following two items:

  1. Audience
  2. Purpose

The audience is just as important as the purpose--often people just have something to say and don't think about why they want to say it or to whom. Think of the difference between kindergarteners and software engineers. Take time to define these two items explicitly before moving on; doing so will greatly change how you create your presentation.

The example of a 4D outline shown below for an experience-report presentation demonstrates how such an outline forces you to think about each point and what you want to say.

table.PNG

Continue to create your outline for each section of your speech. Rather than filling your slides with long streams of text, find appropriate pictures/graphs for each section of your talk so that the audience has something to look at and doesn't have to read. Telling stories is an excellent way to keep your audience engaged. You can tell the same story over several slides.

The last few slides of your presentation should be the summary. This could be what you think the audience can take away and apply in their projects.

Once you have your presentation outline and slides put together, practice it between three to six times in front of others and alone to ensure that you know where on your slides you should make each point. While practicing you might find that you need to change slides around or change what you say on each. This is good! Keep making your presentation better and better. We strongly discourage you to rely too heavily on notes--doing so causes you to lose the essential connection with your audience that is so important to an effective presentation.

We hope you will follow the suggestions in this blog post and help us to make SATURN 2016 the best yet--good luck!

Bett Correa
Architect at GE

amine.pngAmine Chigani is a principal software architect at GE Digital. He leads the development of industrial internet-of-things (IoT) solutions for GE businesses and their customers in domains such as aviation, transportation, and energy. Amine is a founding member of the Industrial Internet Consortium's Architecture Working Group. Prior to his current assignment, Amine was an architect at GE Global Research, an architecture visiting scientist at the Software Engineering Institute (SEI), and CS adjunct faculty at Virginia Tech. Amine earned a PhD in Computer Science from Virginia Tech and the Software Architecture Professional Certificate from the SEI.

joe_olmheim.jpgJørn Ølmheim is a practicing software professional with strong beliefs in open source and internet technology. Currently he holds the position of leading advisor in corporate IT at Statoil, focusing on the subsurface application portfolio and systems integration challenges. He holds an MSc degree in computer science from the Norwegian University of Science and Technology (NTNU).

We welcome Amine and Jørn to the SATURN Technical Committee and look forward to working with them on SATURN 2016.

Bill Pollak
SATURN 2016 General Chair

Why the Internet of Things (IoT) as a special theme for SATURN 2016?
by Amine Chigani and Jørn Ølmheim

Over the past decade, SATURN has built a community of software architecture practitioners and researchers that is passionate about advancing the state of practice and quality of software development through software architecture. So who is better than this community and this conference to cut through the hype and discuss real architecture challenges and solutions to building IoT reference architectures, products, and services?

Now, why IoT and not some other theme?

The short answer is that it feels like everyone is talking about it. But the more intriguing motivation is the 2015 World Economic Forum identifying IoT and related technologies in its top ten priorities.

OK, but who is creating the hype?

Well, Gartner projects that around 50 billion devices, machines, and objects will connect to the Internet in the next 5 years. This is compared to a few billion people who are currently connected to the consumer Internet (and they are still a challenge to handle). A variety of large organizations such as ABB, Cisco, General Electric, Google, IBM, Intel, Microsoft, National Instruments, Siemens, and many others are focusing large resources in this emerging area. Venture capital is spurring a lot of IoT startups too. Unlike other waves of Internet technology transformations, IoT is touching both the consumer and the industrial sectors alike. One club where both of these worlds meet now is the Industrial Internet Consortium (IIC). After incubation on March 27, 2014 with only five founding members, the IIC now boosts more than 200 members from across the globe and is growing weekly.

What Industrial Internet are you speaking of?

Oh! This IoT thing goes by many names. The folks at the Industrial Internet talk about an internet of big things spitting out exabytes of sensor data. In China, there is a reference to Internet+. Of course, Germany has to have its own initiative with a cool name: Industry 4.0. To be even more inclusive, Cisco goes as far as the Internet of Everything. By the time we hold the conference, we will have few more perhaps.

I see. Why should architects care?

That's a good question! Have you heard about the Industrial Internet Reference Architecture that recently came out of IIC? The European Union folks spent a couple of years coming up with their IoT Architecture too. Let's stop at these two examples without going into the plethora of reference architectures and platforms for IoT that are out there. How many of these architectures can the SATURN community call architectures with capital A?

So this is real for architects. There are many software architects and engineers who are in in the midst of the IoT hype, and have to guide business leaders and technology executives to make sense of emerging IoT platforms, products, and services. Many are leading efforts to architect and build the technology infrastructure and solutions to take advantage of the opportunities afforded by moving into a more connected enterprise. This is why we thought we would highlight this theme and see what we can say about it.

How do we intend to run the IoT track?

We will bring together software architecture practitioners and researchers to share and learn from real-world experiences tackling architecture challenges in the IoT space. Don't worry! This will continue to feel like an architecture discussion. We will organize the track in a way that addresses the following questions:

  • What architecture challenges do IoT problems highlight?
  • What are the key quality attributes of IoT solutions, products, or platforms?
  • What architecture patterns and tactics are best suited to address these problems and to achieve these key quality attributes?

The IoT theme is intended to provide a relevant, large-enough problem space for attendees to engage in deep discussions and learning about real-world applications of architecture principles. Building on the software architecture technology and best practices of the past 25 years, speakers will share novel design and architecture advances in machine-to-machine connectivity, time-series data, big-data analytics, containerization, microservice design, cloud-native development, platforms, user experience, and cyber security as well as other architecture topics that provide the foundation for IoT solutions.

We will put together a track that blends both methodology and practice, but with a little bias toward submissions that demonstrate the value of software architecture in the successful delivery of quality software solutions in IoT space.

How can you contribute?

Submit a session proposal to this track and share this blog with your network. If you stumbled across this blog post by searching for what is happening in the IoT space, then check out the SATURN 2016 Call for Submissions.

Now that you found this blog, bookmark it and come back again as we plan to keep the discussion going. So stay tuned!

Amine Chigani, GE Digital
Jørn Ølmheim, Statoil

SATURN 2016 Technical Co-Chairs

The 12th SEI Architecture Technology User Network (SATURN) Conference 2016 will be held at the Sheraton San Diego Hotel & Marina in San Diego, California, May 2-5, 2016. We are pleased to announce that the co-technical chairs of SATURN 2016 will be Amine Chigani of GE Digital and Jørn Ølmheim of Statoil.

The SATURN 2016 Call for Submissions is now open.

What's New for 2016

SATURN 2016 will feature the Internet of Things (IoT) as a theme for one of its four tracks. This theme is intended to inspire the SATURN architecture community to cut through the hype and discuss real architecture challenges and solutions to building IoT reference architectures, products, and services. For more about the decision to dedicate a track to IoT, see this post by Amine and Jørn.

This year's technical program is organized into four tracks: (1) Architecting for the Internet of Things, (2) Architecture Methods and Design Patterns, (3) Technology and Tools, and (4) Leadership and Business. More information about these tracks and about session types and lengths is available in the SATURN 2016 Call for Submissions.

All proposals must be submitted to the online submission system no later than January 15, 2016. Presenters whose proposals are accepted will receive free or discounted admission to the conference depending on the submission type.

Lots more information about SATURN 2016 will be forthcoming here on the SATURN blog and on the SEI and SATURN 2016 websites. We hope you will begin making plans to join us in San Diego next May and that you will consider being part of the technical program by submitting a proposal.

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.

  • Did the speakers have an impact on their organizations related to the lessons or insights proposed?
  • Do the speakers appear to be knowledgeable of the topics proposed?
  • Do the speakers have a history of successful, engaging, educational, energetic, passionate, or entertaining presentations?
  • Have the speakers shown an attention to detail in preparing their proposal?
  • For participative sessions and tutorials, will the proposed session create an effective learning experience for attendees?

Lasting sessions have appeal beyond current fads and attempt to weave new ideas into our overall understanding of how we develop software systems.

  • Does the proposed session advance the current state of practice?
  • Does the proposed session improve our depth of understanding in software architecture?
  • Does the proposed session present a unique or novel project experience?
  • Does the proposed session offer a unique or fresh perspective on "classic" topics?

Our intent in sharing this information is to help you to write the best proposal possible. Use these evaluation guidelines to tailor your proposals and help create the best SATURN Conference yet. Strong proposals will have some "yes" answers in each of the guidelines. Also note that these are only guidelines and not hard-and-fast rules. We are excited to see all the great ideas that are proposed!

- Amine Chigani
- Jørn Ølmheim
SATURN 2016 Technical Co-Chairs

SATURN 2016 will be held in San Diego, California, May 2-5, 2016. See the SATURN 2016 Call for Submissions to learn how you can submit an abstract to present your ideas at SATURN 2015. Please submit proposals for 15-, 30-, and 90-minute sessions to the online submission system no later than January 15, 2016. The technical committee will offer discounted conference attendance to those selected to be part of the program; specific compensation details will be posted on the SATURN 2016 website soon.

For those who were unable to attend the Software Engineering Institute (SEI) Architecture Technology User Network (SATURN) 2015 Conference, videos of many SATURN 2015 presentations are now available to view online

SATURN 2016 will be held at the Sheraton San Diego Hotel & Marina in San Diego, California, May 2-5. The SATURN Technical Committee will release the Call for Submissions for SATURN 2016 during the first week in September. We are opening the Call early this year to allow more time to submit proposals for the outstanding presentations you have come to expect from SATURN as the premier architecture conference for senior engineers. Watch for an announcement here soon!

Software engineering educators gathered August 3-5 at the SEI's Pittsburgh headquarters for the 12th annual Architecture-Centric Engineering (ACE) Workshop for Educators. The SEI hosts this event to foster an ongoing exchange of ideas among educators whose curricula include the subjects of software architecture and software product lines. The SEI's Grace Lewis and Robert Nord led the workshop, which was attended by 16 educators representing institutions located in the United States, Canada, Mexico, Peru, and Thailand.

Read more about the workshop on the SEI website.

If you would like to participate next year, please send email to get added to our mailing list for the event.

The Software Engineering Institute (SEI) is conducting design research on the SEI website in an effort to make the site more user friendly. We are asking for the help of those with a technical background to take a brief usability test, which requires technical knowledge though there are no right or wrong answers. The test should take about 10-15 minutes, and those who take it will be entered into a raffle to win a $50 Amazon gift card (you will be asked for your email address, which will be used to select the winning participant).

The test will be open until Friday, August 21 and can be accessed at http://ows.io/tj/y3u67ty6

Thanks in advance for your help!

Software: Catalyst of Change

With the increasing reliance on and penetration of software into everyday lives, the need for organizations to predictably develop, acquire, and sustain high-quality software systems has never been greater. To address this need, the Carnegie Mellon University Software Engineering Institute (SEI) is pleased to announce that it will host its first Software Solutions Conference (SSC) at the Hilton Crystal City in Arlington, Va., from Nov. 16 through 18.

Review the conference program here.

The conference is designed to focus attention on emerging technologies and technical strategies for assuring quality, timeliness, trust, and affordability in current and future software-reliant systems. These technologies and strategies are vitally important to the missions of the U.S. Department of Defense (DoD), government agencies, and the industry that supports them.

Highlights of the technical program include

  • sessions in three tracks: Project Experiences, Research Topics/Emerging Technology, and Acquisition Practice
  • a broad range of presentations on key topics including legacy-system modernization, large-scale Agile development and Agile for defense programs, system complexity, system and software testing, high-assurance software for real-time systems, systems of systems, acquisition, risk, cloud computing, decision-support systems, computing at the tactical edge, DevOps in the federal government, measurement and analysis, software architecture, software sustainment, and technical debt
  • an expert-panel discussion about open systems architecture
  • joint presentations by SEI staff with DoD and government collaborators
  • a summary of the SEI research program by SEI Chief Technical Officer Kevin Fall
  • a question-and-answer panel discussion with senior SEI leaders
  • social events and opportunities for attendees to network with industry leaders, conference speakers, peers, and experienced innovators, and to influence the SEI technical research agenda.

Registration is now open. Discounted registration will be available to U.S. government and military personnel, employees of small businesses, and attendees whose organizations send three or more people to the conference.

To review the full conference schedule, go to http://www.sei.cmu.edu/ssc.

Researchers in the Software Solutions Division at the Carnegie Mellon University Software Engineering Institute (SEI) are seeking volunteers to participate in a study to identify and measure complexity in software models and to evaluate quality, productivity, and modeling tool usage outcomes in the context of complexity. The Effective Reduction of Avoidable Complexity in Embedded Systems (ERACES) Experimentis seeking up to 70 participants from two communities:

  • computer science students at a college or university
  • industry and government professionals from the software development domain

The call for participation is open now through June 30, 2015.

On Monday, April 27, before the start of SATURN 2015, a small group of 16 software engineers met to explore ideas around the emerging microservices architecture trend. Microservices have seen a rapid rise in popularity over the past year or so, and we thought it would make an interesting topic of discussion. Sam Newman's book covers significant ground and yet there there are still many nuances that we don't fully understand.

We were honored to have Gregor Hohpe, chief IT architect at Allianz, as one of our three keynote speakers this year at SATURN. In fact, we have been trying for several years to persuade Gregor to speak for us; this was the first time we succeeded.

Gregor has kindly posted his impressions of SATURN 2015 to his blog, and I urge you to read them. SATURN, writes Gregor, is "an amazing event [that is] a perfect blend of structured thinking from the academic edge combined with valuable industry experience."

Many thanks to Gregor for his contributions to SATURN 2015 and his great blog post.

Bill Pollak
SATURN 2015 General Chair

Since 2010, the SEI and IEEE have been conferring two attendee-selected awards at SATURN. The IEEE Software SATURN Architecture in Practice Presentation Award is given to the presentation that best describes experiences, methods, and lessons learned from the implementation of architecture-centric practices. This year's award winners were Jochem Schulenklopper and Eelco Rommes of inspearit for their presentation titled Why They Just Don't Get It: Communicating Architecture to Business Stakeholders.

Mark Schwartz, U.S. Citizenship and Immigration Services Schwartz discussed some projects that he has led and lessons learned from the experiences in building systems for the government. He is CIO of one of three agencies that deal with immigration. USCIS processes 7 million applications per year for green cards, refugee status, citizenship, and other cases. USCIS is part of the Department of Homeland Security, which is important because the agency is under two tiers of enterprise architecture, and everybody wants to tell everybody else what to do. USCIS manages about 70 legacy IT systems, and Schwartz discussed three new projects.

Marisa Sanchez, Independent Consultant Sanchez works in the arena of large-scale technology change and facilitated a participatory session on how to engage your most critical stakeholders to support your project. Her stakeholder engagement framework has three steps:

(1) identify stakeholders,

(2) analyze stakeholders, and

(3) develop engagement strategies.

Jungwoo Ryoo, Pennsylvania State University, and Rick Kazman, University of Hawaii and Carnegie Mellon Software Engineering Institute

by Jacob Tate, Mount St. Mary's University

In his talk titled "Architectural Analysis for Security (AAFS)," Jungwoo Ryoo explained that there is an absence of security practices in software architecture. His research concerns developing and implementing a methodology to test and secure software systems starting at the design phase. The architectural analysis is basically a structured way of discovering these security issues. It has frequently been common to implement methods like this after the design of the system, and Dr. Ryoo warned against this.

Amine Chigani and Yun Freund, GE Software

At GE, software is a horizontal capability in the company, with over 14,000 software professionals in the business. GE Software is launching the Predix™ platform, which will be a common theme across all of GE's industries, and the company will make this platform available to the world later this year.

Jeromy Carriere, Rick Buskens, and Jack Greenfield, Google
Evolving Mission-Critical "Legacy" Systems, Rick Buskens

Buskens's team is a multisite team that works on a suite of projects focused on Google's internal structure, while others are external-facing and cloud. The infrastructure for running services at Google is built on Borg, a cluster-management system that runs hundreds of thousands of jobs across thousands of applications in clusters of tens of thousands of machines. Borg is an internal cloud infrastructure, whose users have many different needs; a service configuration specification called BCL (Borg Configuration Language) allows users to tell Borg what those needs are. Buskens's team works on Borg Config, which interprets the service configuration for Borg; it manages the millions of jobs running each day. BorgCron works for scheduled and repeated tasks at Google scale.

Jane Orsulak and Julie Kent, Raytheon
by Jacob Tate, Mount St. Mary's University

Jane Orsulak and Julie Kent kicked off the experience-presentation session on SATURN's final day by talking about "System Characterization: An Approach to Modernizing Disparate Legacy Systems." In this presentation, they gave a summary of some of the training that soldiers have to go through, such as live training and virtual training.

Rebecca Wirfs-Brock, Wirfs-Brock Associates, and Joseph Yoder, The Refactory, Inc.

How do you make quality happen? Budget time for quality discussions and quality testing. During envisioning and requirements gathering, identify core qualities. The core goal of agile and lean was not just to go faster, but to get rid of waste. Quality can be a result of those processes, but you need to engineer for quality by architecting for quality and then testing for it. You'll also need to determine appropriate times when qualities can be tested and delivered.

Len Bass; Sascha Bates, Chef; Sam Newman, ThoughtWorks
by Jacob Tate, Mount St. Mary's University

Len Bass, Sascha Bates, and Sam Newman started off the afternoon session with a presentation titled "DevOps: Essentials for Software Architects." Dr. Bass introduced this session by explaining exactly what the speakers will mean by "DevOps." He stated that after software architects or engineers finish their job, it often takes too long to get their code into production. DevOps is concerned with reducing the time from code completion to code production. Errors in code and miscommunication about which versions of which tools are being used are some of the biggest problems causing the process to be slow. We can speed up deployment by setting up an architecture so that development teams do not have to coordinate with each other; this coordination is where a lot of time is lost.

Matthias Naab, Fraunhofer IESE; Ralf Carbon, John Deere; and Susanne Braun, Fraunhofer IESE

by Jacob Tate, Mount St. Mary's University
Drs. Ralf Carbon and Matthias Naab kicked off the short-presentation afternoon session with their talk titled "Never Again Offline?!? Experiences on the Outstanding Role of Data in a Large-Scale Mobile App Ecosystem." As you might gather from the lengthy title, there was an abundance of information packed into these 30 minutes.

Gloria Ingabire, Carnegie Mellon University

OpenMRS is an existing, robust medical record system (MRS), and Ingabire is proposing some additional functions for it, called OpenMRS+. She was inspired to take on this challenge by her mother's history of diabetes and uncle's history of cardiovascular disease. If people knew the likelihood of getting a non-communicable disease, they might be more likely to take precautions.

Simon Brown, Coding the Architecture

by Jacob Tate, Mount St. Mary's University
Simon Brown taught us a lot in his session titled "Software Architecture as Code." From teaching us where Jersey is to how to extract architecture from code, Brown gave a riveting talk on bridging the gap between architecture and code. Diagrams for software architecture are often messy; one developer cannot distinguish another's way of thinking by looking at sloppy boxes and mismatched lines. Would we write our code this way? Our code does not map to the architectural views we created, and this is a problem.

Forrest Shull, Carnegie Mellon Software Engineering Institute (SEI);
Thomas DuBois, The Boeing Company;
Nick Guertin, Office of the Deputy Assistant Secretary of the Navy for Research, Development, Test, and Evaluation;
Michael McLendon, SEI;
and Douglas C. Schmidt, Vanderbilt University and SEI

Forrest Shull opened the session with a brief introduction to Open Systems Architectures (OSA), an initiative within the DoD, to make systems more configurable and adaptable than they are today. This initiative ties in with the Better Buying Power Initiative, which focuses on making systems more efficient and effective. It's about system architecture, but software architecture is buried within that. How do we make systems more modular, more open, and still deal with interfaces between the components when the systems are part of a community? How much to make open and how much to keep behind the wall are issues that this initiative must deal with. Each panelist gave a brief on their opinions of where OSA stands today and what its challenges are.

Ariadna Font Llitjós, IBM Watson Group; Jonathan Berger, Pivotal Labs; and Jeff Patton, Jeff Patton & Associates
Font Llitjós began this conversation-style panel with a brief review of Design Thinking 101: "Design is not a product designers produce"; "design is a process designers facilitate." Then she introduced IBM's method, which includes four modes of design thinking: Understand, Explore, Make/build/prototype, and Validate/iterate.

Paul Boos, Santeon Group
by Jacob Tate, Mount St. Mary's University

Paul Boos introduced us to a little Japanese in his talk titled "Improving Architectural Refactoring Using Kanban and the Mikado Method." These methods have been employed by such companies as Toyota to drastically increase production speed while tracking progress. But how does this translate from assembly lines to software?

Rick Kazman, University of Hawaii and Carnegie Mellon Software Engineering Institute, and Humberto Cervantes, Universidad Autónoma Metropolitana-Iztapalapa
Design is hard. Architects need insight into types of architectural drivers, guidance on selecting design concepts, and what drives certain design decisions to make good decisions by considering these consciously. Architects also need an approach to negotiate with management and stakeholders better to make these good decisions. In this tutorial session, Kazman and Cervantes presented an updated version of the 2006 Architecture-Driven Design Method 2.0 to address these concerns.

Einar Landre and Jørn Ølmheim, Statoil

by Jacob Tate, Mount St. Mary's University
Einar Landre presented an experience report at the last morning session titled "Systems of Action: A Stack Model for Capability Classification." The subject matter of this presentation delved into the importance of structuring a class of systems that can observe phenomena or processes and then interpret this data and make intelligent decisions.

Michael Keeling, IBM Watson Group
The concept of design as a way of thinking comes from Herbert Simon in 1969. Companies would empathize with the user and work to solve their problems, but this approach had the unintended side effect of focusing too exclusively on the user interface, and there is more to design in software than the user interface. Software architecture is the perspective that holds all the perspectives together: users, business needs, and more.

George Fairbanks, Google
In this experience report, George Fairbanks discusses his recent experiences from assembling large bits of software. He reminds us of how sneakily dependencies become complicated through the analogy of the frog in a gradually heating pot of water. Architects could solve the complexity problem up front in a waterfall process, but how and when can they architecturally intervene in an incremental development process?

Mary Shaw, Carnegie Mellon University

by Jacob Tate, Mount St. Mary's University
The SATURN 2015 Conference is underway, and what a great start! As the largest SATURN Conference to date with over 200 attendees, you can feel the excitement and buzz of the people who traveled from all over the globe to attend. It kicked off yesterday with a few special sessions and classes, but more notably with the introductions and the first keynote speaker this morning. Mary Shaw gave a fast-paced lecture on the progress of engineering in terms of the software discipline. She explored the question "Is software engineering really engineering?" and systematically explained the various definitions of engineering, such as "creating cost-effective solutions to practical problems by applying codified knowledge and building things in the service of mankind."

At SATURN 2015, the software architecture community will put microservices on trial. Here is an abstract of this event, which will take place on Tuesday, April 28, from 5:00 to 6:00 pm:

Microservices architecture has emerged as a widely discussed style of building distributed web and internet systems. Proponents argue that this variant of service-oriented architecture (SOA) is well suited to address the challenges of cloud computing, scalability, increased flexibility, and complexity, among others. But haven’t we seen this all before? Is there really anything new and interesting about microservices architecture? Or is this simply a case of history repeating itself, like the last time service-oriented architectures were all the rage? Microservices architecture is hereby charged with being an attractive nuisance in the first degree. SATURN 2015 has recruited an expert panel of judges to debate the benefits and perils of microservices architecture and help you, the jury, learn the facts and determine the final verdict.

Seventh International Workshop on Managing Technical Debt (MTD 2015) October 2nd 2015, Bremen, Germany, in conjunction ICSME 2015 http://www.sei.cmu.edu/community/td2015/ Delivering complex, large-scale systems faces the ongoing challenge of how best to balance rapid deployment with long-term value. Theoretical foundations and empirical evidence for analyzing and optimizing short- term versus long-term goals in large-scale projects are needed. From the original description—“not quite right code, which we postpone making right”—various people have used the metaphor of technical debt to describe many kinds of debts or ills of software development. On one hand, the practitioner community has increased interest in understanding and managing debt. On the other hand, the research community has an opportunity to study this phenomenon and improve the way it is handled. We can offer software engineers a foundation for managing such tradeoffs based on models of their economic impacts. The workshop will be held in conjunction with the International Conference on Software Maintenance and Evolution (ICSME 2015), September 29--October 1, 2015, Bremen, Germany. For more information and to participate, see the Workshop Program.

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.

Women in Software Architecture
As part of National Women's History Month, Pittsburgh Urban Media salutes Dr. Mary Shaw, recipient of the National Medal of Technology and Innovation in 2014. Dr. Shaw is a leader in software engineering research whose work on software architecture helped establish it as a recognized discipline, and PUM's interview with her reveals how she got an early start in a field dominated by men and what she is most proud of today. We are pleased that Dr. Shaw will give a keynote talk at SATURN 2015, and we use this week's link roundup to highlight other women of the software architecture discipline who will also present at SATURN 2015. Discovering Alexander's Properties In Your Code: In this presentation from Smalltalks 2014, Rebecca Wirfs-Brock of Wirfs-Brock Associates explains how Christopher Alexander, the building architect, inspired the first software patterns with his patterns for buildings and architecture and why she thinks his latest work could influence how you code.

by George Fairbanks and Michael Keeling, SATURN 2015 Co-Technical Chairs

When we attend technical conferences, the sessions we appreciate most and remember long after the conference ends are those in which influential, creative thinkers share and explore ideas that excite them. If you have had this experience at conferences you have attended, you'll agree: when a gifted speaker expands minds by challenging well-worn assumptions and articulating groundbreaking ideas, you can feel the energy in the room.

Because we wanted this experience at SATURN 2015, both for ourselves and for our attendees, we invited some of the most influential thinkers in the field of software architecture to participate in the conference program. And not only did we invite a collection of people we knew would electrify a room with their ideas; we also asked them to curate their own sessions by inviting additional speakers who have inspired them. The result: we are pleased to introduce the Invited Speakers Series, new this year at SATURN 2015.

Billions and Billions Served: Real-Time Distributed Messaging

Dissecting Message Queues: Tyler Treat at Brave New Geek reports an analysis of several different message queues and describes the differences in throughput and message latency between brokered systems (such as NSQ) and brokerless systems (such as ZeroMQ). Graphs of his results may provide information about which type of system is best for different contexts and needs.

NSQ: A Realtime Distributed Messaging Platform: Bitly developers Matt Reiferson and Jehiah Czebotar have designed NSQ to "operate at scale, handling billions of messages per day." It serves as the backbone of an infrastructure composed of loosely connected services running on many computers. With no single point of failure, it has high availability, reliability, and fault tolerance. For use with any data format, NSQ is easy to configure and deploy.

The Fun of Experimenting with a More Advanced Microservice Application - Building a Slack "Done This" Tracker: Ad Van der Veer at Giant Swarm explains how he used NSQ as one of three components of a method to manage complexity in the architecture layer of a microservice setup.

Second International Workshop on Software Architecture and Metrics at ICSE

Florence, Italy, May 16, 2015
http://www.sei.cmu.edu/community/sam2015/

We are pleased to announce the program for the Second International Workshop on Software Architecture and Metrics (SAM 2015) featuring keynotes from Radu Marinescu and Tim Menzies, invited presentations on architecture quality and measurement, and interactive sessions to discuss progress on architecture and metrics, measurement, and analysis; to gather empirical evidence on the use and effectiveness of metrics; and to identify priorities for a research agenda.

The workshop addresses both academic researchers and industrial practitioners for an exchange of ideas and collaboration. The workshop will be held in conjunction with the International Conference on Software Engineering (ICSE 2015), May 16-24, 2015 in Florence, Italy.

For more information and to participate, see the Workshop Program.

The 12th SEI Architecture-Centric Engineering Workshop for Educators will be held at the Software Engineering Institute in Pittsburgh, Pennsylvania, USA, on August 3-5, 2015. The SEI hosts this annual event to foster an ongoing exchange of ideas among educators whose curricula include the subjects of software architecture and software product lines. The event is free of charge and open to any accredited, college-level educator.

This year's event will incorporate the SEI's course on DevOps from a Software Architecture Perspective. This course is helpful if you wish to adopt DevOps practices and continuous-delivery workflows. The architecture component of the course focuses on the relationships among application software, the deployment environment, and the supporting tooling.

WICSA/CompArch 2015 - 12th Working IEEE / IFIP Conference on Software Architecture and 9th Federated Conference SeriesComponent-Based Software Engineering and Software Architecture Call for Workshop Papers
May 4-8, 2015 Montreal, Canada
http://wicsa2015.org/workshops.html

WICSA | CompArch 2015 workshops provide a unique forum for researchers and practitioners to present and discuss the latest R&D results, experiences, trends, and challenges in the field of software architecture, component-based software engineering, and software system qualities.

At SATURN 2015, to be held in Baltimore, Maryland, April 27-30, 2015, the SEI will augment the three-day technical program with three one-day courses offered on Monday, April 27. SEI courses are created and delivered by recognized experts who have practical experience in the disciplines they teach. Our courses feature participatory tasks and real-world scenarios to enhance your learning

Big Data: Architectures and Technologies (instructors, Ian Gorton and John Klein) Scalable big-data systems are significant long-term investments that must scale to handle ever-increasing data volumes, and therefore represent high-risk applications in which the software and data architectures are fundamental components of ensuring success. This one-day course is designed for architects and technical stakeholders such as product managers, development managers, and systems engineers involved in the development of big data applications. More information Register now


Software Architecture Modeling
Last summer, a Mother Jones article by Tasneem Raja asked, "Is coding the new literacy?" The answer is yes and no, because the point is not to increase "the number of kids who can crank out thousands of lines of JavaScript" but "to boost the number who understand what code can do" and can think up good ways to apply it. To do this, computer science education must first undergo a paradigm shift, from "reinforcing the notion that code is just for coders" to leading with computational thinking, which CMU's Jeannette Wing defines as "solving problems, designing systems, and understanding human behavior."

In its list of "top 100 careers with big growth, great pay and satisfying work," CNN/Money calls "software architect" the best job in America. We'll be coming out in a week or two with details about the technical program at SATURN 2015, to be held in Baltimore, Md., April 27-30. One new component of the program this year will be what we are calling Architecture Boot Camp--a series of presentations intended to provide basic information about software architecture. These presentations would be great for someone who does not currently hold the best job in America, but aspires to do so.

Centralized Architecture
At Phys.org, Dr. Norbert Aschenbrenner recently wrote about the First Series Production Vehicle with Software Control. Siemens and partners are developing information and communications technology for electric cars, and their first production vehicle uses a central electronics and software architecture called RACE. This centralized architecture is intended to reduce development time and make it easier to add new functions later. This SATURN link roundup offers several recent blog posts and a podcast on the topic of centralized architecture. Selecting the Right Computing Architecture for Your GIS: Dave Peters at Esri Insider offers some advice on how to choose between centralized and distributed architectures. IoT Drives Business Decisions: In a podcast from the 2014 IoT Summit, Gary Butler, Chairman and CEO of Camgian Microsystems, and Gary Audin, President of Delphi, discussed two approaches to connecting the Internet of Things (IoT), centralized architectures and architectures distributed at the network edge.

Clouds at Hyperscale
For media services everywhere, January is the time to write summaries of the previous year and make forecasts about the next one. Lisa Wirthman of Forbes Magazine helps us transition to the new year with How the Top 5 Cloud Trends of 2014 Will Impact the Enterprise in 2015. The fourth of Wirthman's five trends is about the maturing cloud market in 2014 and the growth of a few cloud providers operating at a global scale in 2015. This SATURN link roundup offers a few recent blog posts on clouds at hyperscale. A Rare Peek Into The Massive Scale of AWS: Amazon Web Services has revealed the size and scope of its cloud, and Timothy Prickett Morgan at EnterpriseTech reports that it is really, really big. Morgan runs through some of the numbers and discusses the datacenter architecture of the AWS cloud. You can also watch AWS Senior Vice President Andy Jassy's keynote talk from the AWS Re:Invent 2014 Conference.

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 =============== Abstract submission: Jan 12, 2015 Paper submission: Jan 16, 2015 Notification: Feb 16, 2015 Camera-Ready: Feb 27, 2015 Conference: May 16-17, 2015

Date: January 21, 2015 Time: 1:30 PM ET - 3:00 PM ET Cost: Free

About the Webinar

Trends and New Directions in Software Architecture, by Linda Northrop 1:30 PM ET - 2:15 PM ET Software architecture has enormous influence on the behavior of a system. For many categories of systems, early architectural decisions can be a greater influence on success than nearly any other factor. After more than twenty years of research and practice, the foundations for software architecture have been established and codified, but challenges remain. Among other trends, increased connectivity, a shift to the cloud and to mobile platforms, and increased operational and market tempos have precipitated the need for changes in architectural practices and decisions. The first talk shares a perspective on the trends influencing the need for change, the related architectural challenges, and the applicable research and practices.

Refactoring
In December 2014, Andre Infante of CoinReport wrote about a Bitcoin developer's warning that the rapid development of Bitcoin software may be "introducing consensus bugs." In Peter Todd Warns of Potential for Accidental Bitcoin Forks, Infante describes how the pace and scale of refactoring may have created a fork in the development. If the fork is not corrected, the network may not be able to achieve consensus about official versions of events, which could wreak havoc for a payment system. This link roundup offers several recent blog posts and a conference presentation on the topic of refactoring. Sacrificial Architecture: Martin Fowler of ThoughtWorks, and author of Refactoring, explains why he hopes that in a few years you'll need to throw away the code you are creating today. Architecture Seams: Jean Barmash at Hello FooBar! expands Michael Feathers' term seam from the book Working Effectively with Legacy Code from code to architecture, then discusses how to exploit architecture seams in a large-scale refactoring project.