April 29 to May 3, 2013
Use these links to go directly to each tutorial.
T1: SOA with REST: Principles, Patterns, and Constraints
Cesare Pautasso, University of Lugano
Recent technology trends in web services indicate that a solution eliminating the perceived complexity of the WS-* standard technology stack may be in sight. Advocates of representational state transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve problems related to enterprise application integration and to radically simplify the plumbing required to implement a service-oriented architecture (SOA). In this tutorial, we give an update on how the REST architectural style has been recently rediscovered to become the foundation for so-called RESTful web services, a trend that has now made a strong impact on the architectural design of large-scale service-oriented systems. Our goal is to show that the notions of open systems, dynamic discovery, interoperability, reuse, loose coupling, and statelessness usually associated with service-oriented computing can be naturally expressed within the set of constraints given by the REST architectural style. We will answer questions such as these:
We will use the ensuing discussion to highlight some open research problems related to this emerging and important area of software service engineering.
The tutorial is directed to SATURN 2013 attendees with an interest and optionally some background in software service engineering and the design of SOAs. Whereas we will keep the material self-contained, we will assume attendees have some experience browsing the World Wide Web and a basic understanding of the HTTP protocol. Any professional familiar with the concepts of architectural style and software service will be able to follow the material. Attendees should be interested in learning not only the basic principles and patterns of RESTful web-service design but also in assessing how REST significantly differs and potentially improves upon existing approaches centered around WS-* technologies. If time permits, we will also include some quick technology demonstrations so that attendees will be able to gain an understanding of the maturity, the benefits, and the main limitations of the current state of the art in RESTful web-service tooling.
Cesare Pautasso is assistant professor in the Faculty of Informatics at the University of Lugano, Switzerland. Previously he was a researcher at the IBM Zurich Research Lab and a senior researcher at ETH Zurich, Switzerland. His research focuses on building experimental systems to explore the intersection of model-driven software composition techniques with business process modeling languages. He is the lead architect of JOpera, a RESTful Web service composition tool for Eclipse. His university teaching, industry training, and consulting activities cover advanced topics related to middleware, service-oriented architectures, web development, and emerging web-services technologies. He coauthored the book SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST, published by Prentice Hall in 2012. He is also coeditor of the book REST: From Research to Practice, published by Springer in 2011. He started the WS-REST workshop series at the WWW conference and presented several editions of a successful tutorial on RESTful web services at WWW 2009–2010 and ICWE 2009–2010, ICSE 2011, and SATURN 2011. For more information, visit his website.
T2: Architectural Coaching
Felix Bachmann, Carnegie Mellon Software Engineering Institute
You are joining a team of architects for an exciting new project. Some of the architects have a lot of experience, while others have less. Some have strong personalities, and some enjoy teamwork. You have a clear idea of what this team should do to successfully create the next generation of that software system. Have you ever asked yourself, "How can I make the team do what I think are the right things to do?"
In this tutorial, you will learn techniques and behaviors that will help you to successfully coach an architecture team. You will learn what processes to apply, when to be assertive, and when it is time to step back while the team moves forward, so that at the end of the process you work in a fun team who can enjoy their success.
Felix Bachmann is a senior member of the technical staff at the Carnegie Mellon Software Engineering Institute (SEI) working in the Product Line Systems Program on both the Architecture Tradeoff Analysis and Product Line Practice projects. There he is the team lead for architecture-centric product line practices, a coauthor of the Attribute-Driven Design Method, a contributor to and instructor for the ATAM Evaluator Training, a coauthor of Documenting Software Architectures: Views and Beyond, and leading research on architecture design. Before joining the SEI, he was a software engineer at Robert Bosch, GmbH, in Corporate Research, where he worked with software development departments to address the issues of increased features and higher quality in the call-control software, the core of telecommunications products. As a result of these efforts, Bosch developed the OTES (Objects Through Essential Services) Method, in which Mr. Bachmann played a decisive role. Mr. Bachmann also defined the corresponding software development process that describes in three levels how to develop high-quality software in a timely fashion. Later he was a Resident Affiliate for Bosch at the SEI where he managed a collaboration in software architecture and product lines that was aimed at applying the SEI technology and methods in these areas within Bosch business units. Bachmann began his career in 1977, educating service staff on determining and rectifying software errors in the first computer-controlled telecommunication systems.
Most existing architecting methods focus either on complete enterprise-architecture frameworks (cf. TOGAF) or on predominantly technical aspects of software-intensive systems (cf. UP, ADD, and ATAM). For years, there has been a methodological gap between enterprise architecture and software/systems architecture—a void that more and more architects have to bridge in their daily work. Many architects working in this void have started calling themselves solution architects, a name that reflects focus on a specific IT-related solution, architected in the high-pressure context of a single bid, project, or product.
Risk- and cost-driven architecture (RCDA) is an approach that has been developed within CGI (formerly Logica) to support solution architects in a pragmatic, lean manner. RCDA consists of a set of principles and practices that have been harvested from practitioners' experiences, supplemented by insights from literature and research, and validated by CGI's architecture community.
RCDA contains guidance for architects on a more practical, solution-oriented level than enterprise-architecture approaches, while being generic enough to help architect solutions that incorporate multiple technologies and several architecture layers. The process of developing a solution architecture is context specific. Solution architects who try to apply a fixed architecting process (like IAF or TOGAF) often have problems fitting such a process in existing sales, design, and development processes. By separating architecting practices from the process, RCDA allows for broad usage of good architecting practices, without forcing teams to adapt a completely new process. Architects trained in RCDA report a significant positive impact on their solution-architecting work.
The tutorial is based on the popular three-day RCDA training that has been taught to 200 CGI architects in a dozen courses over the past three years. This is the first time RCDA training will be given outside of CGI. It is a condensed version of the three-day training, focusing on the following topics:
The tutorial is aimed at practicing enterprise, solution, software, or other architects in the digital world. The tutorial may also appeal to engineers and business managers interested in solution architecture. Attending architects learn how to pragmatically focus their daily work and discuss priorities and choices with their stakeholders in business terms. Because RCDA is structured in individual practices, it is easy for architects to apply its guidance in existing organizations or processes. RCDA's "best-fit practice" approach allows organizations to reap its benefits without having to change or adopt a completely new architecting process.
Eltjo R. Poort was born in Amsterdam, The Netherlands. After graduating with a specialization in theoretical physics at the VU University, he started a career in the software industry. In 1993 Eltjo joined CGI, formerly Logica, where he fulfilled various engineering and project management roles. He was appointed Lead Expert on Solution Architecture in 2004, becoming responsible for improving architecting practices and the architect training curriculum within CGI. During the last decade, Eltjo's reflections on his work in IT have regularly been published in academic circles, resulting in a PhD thesis in 2012.
For more information, visit his blog.
T4: The CrossModel Architecture Discovery Pattern Language
George Fairbanks, Rhino Research
Software architects often must recover, understand, or describe the architecture of an existing system. As a community, architects usually agree that systems should be described using multiple views. However, when it is time to build those views, each architect does it his or her own way, and the results are correspondingly idiosyncratic.
This tutorial describes CrossModel, a technique for architecture recovery, understanding, and description that is repeatable and yields a set of self-consistent views. It is described as a set of over 50 patterns and a pattern language that guides application of the patterns.
CrossModel is particularly good at revealing the functional aspects of a system and adequate at revealing quality attribute aspects. This is a good fit for architecture-discovery projects because most systems are Big Balls of Mud rather than optimized for chosen architecture drivers.
If you have never tried to recover the architecture of a system, you might think that it is a simple matter of interviewing experts and writing down your findings in a suitable notation. In practice, however, you get a set of incomplete and flawed descriptions from experts. From these vague clues, the architect must solve the puzzle: synthesize a coherent understanding of the system, recognize inconsistencies and gaps between views, and drive the discovery and creation of a complete and self-consistent model.
CrossModel makes this puzzle easier to solve by providing a mental framework to organize discovered details, techniques to discover inconsistencies and gaps, and a pragmatic process for interviewing experts. The name CrossModel evokes a crossword puzzle, which has scraps of information (clues) provided by experts that are scrutinized with the goal of making a consistent model (the puzzle).
George Fairbanks is an architect and mentor. As the president of Rhino Research, he has built Big Data systems for leading analytics firms, worked with CTOs to apply the CrossModel technique to understand existing systems, designed a hybrid public/private cloud product line architecture, and taught architecture and design classes at many companies and NASA. He has a PhD degree in software engineering from Carnegie Mellon University and is the author of the book Just Enough Software Architecture: A Risk-Driven Approach.
T5: All About NoSQL
Pradyumn Sharma, Pragati Software Pvt. Ltd.
NoSQL database platforms have evolved and matured very well and are a good bet not only for public websites with enormous amount of data but also for enterprise applications. With their flexible data models, elastic scaling, and relative ease of administration, they are a serious alternative to the relational database model for many—but not all—applications.
This tutorial will provide a detailed understanding of the key concepts of NoSQL databases from an architect's perspective. It will include
Pradyumn Sharma received the MBA degree from the Indian Institute of Management, Ahmedabad, and has nearly 30 years of experience in the IT industry. He has played many roles over the years: programmer, designer, solution architect, database administrator, trainer, coach, and consultant.
Sharma is the CEO of Pragati Software Pvt. Ltd., based in Mumbai, India. He regularly conducts training programs for experienced IT professionals in the fields of architecting for the cloud, NoSQL databases, agile methodologies, object-oriented analysis and design, UML, design patterns, and programming logic.
Sharma is a frequent presenter at conferences, such as Agile India, the Scrum Gathering, the Agile Conference, and SATURN.
T6: Effective Software Architecture Sketches
Simon Brown, Coding the Architecture
Agility is about moving fast, and this requires good communication. But it's surprising that many teams struggle to effectively communicate the architecture of their software. As an industry, we do have the Unified Modeling Language (UML), yet many people favor informal boxes and line-style sketches instead. The problem is that such diagrams rarely make any sense, usually need a narrative to accompany them, and ultimately slow the team down. While one can argue whether or not UML offers an effective way to communicate software architecture, that's often irrelevant because many teams have already thrown out UML or simply don't know it. Abandoning UML is one thing, but in the race for agility, many software development teams have lost the ability to communicate visually.
The code might well be the architecture, but at some point in time you're going to have to explain how it works, and that's when the whiteboard pens make an appearance. Where do you start, though? Should you use UML or block diagrams? How much detail should you include? Should you include technology decisions or omit them? In this tutorial, you'll design a software system and practice communicating your vision through a series of simple software architecture sketches. You'll learn about some of the patterns and anti-patterns related to using informal sketches. And you'll learn how to communicate software architecture in an efficient and effective way.
Simon lives in Jersey, the largest of the Channel Islands, and works as an independent consultant specializing in software architecture and technical leadership in modern software development teams. Simon regularly speaks at international software development conferences and provides consulting and training to software teams at organizations across Europe, ranging from small startups to global blue-chip companies. He is the founder of Coding the Architecture, a website about pragmatic, hands-on software architecture, and the author of Software Architecture for Developers, an e-book that is being published incrementally through Leanpub. He still likes to write code too, primarily in .NET and Java.
T7: The Lean Mindset in a Nutshell (SOLD OUT!)
Mary Poppendieck and Tom Poppendieck, Poppendieck.LLC
Analysis is a good thing. Being slow and careful is wise. Rewarding people for performance makes perfect sense. Creating a plan and following it is the best way to get things done. And we should strive to be the best at whatever we do. When we have our analytical hats on, we know these statements are true.
But they aren't the whole truth. Intuition is also a good thing. Being fast produces essential feedback. Purpose works better than incentives for engaging. Probing a complex environment and adapting to its response is the right way to change a complex system. And being the best can get in the way of getting even better. When we are wearing our intuitive hats, we feel that these things are terribly important.
So which hat should we wear? In the last quarter of the 20th century, western companies drifted into the habit of wearing analytical hats most of the time, while the intuitive hats got dusty on the shelf. But since the turn of the century, companies that sport intuitive hats seem to be doing very well. In fact, if we're not careful, they might become a threat to our business.
A company with a lean mindset wears both hats at the same time and knows how to leverage the advantages of each. For those of us who have gotten into the habit of wearing our analytical hats most of the time, a lean mindset means moving our thinking
This workshop will present research, case studies, and exercises to help you understand what a lean mindset is and how it can help your company become more productive, deliver faster, and experience significantly higher quality.
Mary Poppendieck started her career as a process control programmer, moved on to manage the IT department of a manufacturing plant, and then ended up in product development, where she was both a product champion and department manager.
Mary considered retirement in 1998 but instead found herself managing a government software project where she first encountered the word "waterfall." When Mary compared her experience in successful software and product development to the prevailing opinions about how to manage software projects, she decided the time had come for a new paradigm. She wrote the award-winning book Lean Software Development: An Agile Toolkit in 2003 to explain how the lean principles from manufacturing offer a better approach to software development.
Over the past several years, Mary has found retirement elusive as she lectures and teaches classes with her husband, Tom. Based on their ongoing learning, they wrote a second book, Implementing Lean Software Development: From Concept to Cash, in 2006, and a third, Leading Lean Software Development: Results Are Not the Point, in 2009. A popular writer and speaker, Mary continues to bring fresh perspectives to the world of software development.
Tom Poppendieck has 25 years of experience in computing, including 8 years of work with object technology. His modeling and mentoring skills are rooted in his experience as a physics professor. His early work was in IT infrastructure, product development, and manufacturing support and evolved to consulting project assignments in health care, logistics, mortgage banking, and travel services.
Tom led the development of a world-class product data management practice for a major commercial avionics manufacturer that reduced design-to-production transition efforts from six months to six weeks. He also led the technical architecture team for very large national and international Baan and SAP implementations.
Tom Poppendieck is an enterprise analyst and architect and an agile process mentor. He focuses on identifying real business value and enabling product teams to realize that value. Tom specializes in understanding customer processes and in effective collaboration of customer, development, and support specialists to maximize development efficiency, system flexibility, and business value.
T8: Architectural Implications of Cloud Computing
Grace Lewis, Carnegie Mellon Software Engineering Institute
As defined by the National Institute of Standards and Technology (NIST), cloud computing is "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction." Cloud computing is being adopted by commercial, government, and Department of Defense organizations as a way to reduce the operational cost of information technology because resources are scalable and billed on a usage basis as opposed to being acquired and maintained. However, for a software architect, cloud computing means that elements of a system or solution may reside outside the organization, and therefore systems have to be designed and architected to account for lack of full control over important quality attributes. This tutorial starts by briefly defining cloud computing, service models, deployment models, drivers and barriers for cloud-computing adoption, and the importance of architecting for the cloud. It then focuses on quality attributes that are critical for the cloud consumer such as security, interoperability, scalability, monitorability, and availability. The focus then turns to the cloud provider and critical quality attributes such as multitenancy, availability, scalability, and performance. Finally, it concludes with a discussion of the present and future of cloud computing.
Grace Lewis is a senior member of the technical staff at the Carnegie Mellon Software Engineering Institute in the Research, Technology, and System Solutions Program. She is the deputy for the Advanced Mobile Systems Initiative and the technical lead for the Edge-Enabled Tactical Systems research project. Lewis has over 20 years of professional software development experience, mainly in industry. Her main areas of expertise include service-oriented architecture (SOA), cloud computing, and mobile applications.
Before joining the SEI, Lewis was Chief of Systems Development for Icesi University, where she served as project manager and technical lead for the university-wide administrative systems. At Icesi University she held positions in all phases of the software development life cycle, from programmer to systems analyst to software architect. Other work experience includes Design and Development Engineer for the Electronics Division of Carvajal, S.A., where she developed software for communication between PCs and electronic devices and developed embedded software on the microcontroller that was used on the devices.
At the SEI she has worked in the area of commercial-of-the-shelf (COTS)-based systems, legacy system modernization, systems-of-systems engineering, and SOA, in which she has a number of publications, including a book in the Software Engineering Series, Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices. Her current area of work is mobile computing in resource-constrained environments as well as the intersection between mobile computing and cloud computing.
Lewis has teaching experience at the graduate and undergraduate levels. She is currently a member of the technical faculty and a mentor for the Master of Software Engineering program at Carnegie Mellon University (CMU). She holds a BSc degree in systems engineering and an Executive MBA from Icesi University in Cali, Colombia, and an MSE degree in software engineering from CMU.
T9: Attribute-Driven Design (ADD) in the Real World
Humberto Cervantes, Universidad Autonoma Metropolitana – Iztapalapa
Rick Kazman, University of Hawaii
The process for creating a software architecture is a complex endeavor. Methods such as Attribute-Driven Design (ADD) provide a way to structure the design process so that it can be systematic and repeatable.
In ADD, design decisions are based on two types of design concepts: design patterns and tactics. Making design decisions means selecting design patterns and tactics based on a subset of the architectural drivers and creating and connecting elements derived from these design concepts. The result is a structure that is a partial architecture design that grows iteratively until design decisions have been made to satisfy all the drivers associated with the software system. The result is an architectural design that is hopefully then documented, implemented, and evaluated.
There are, however, two problems in employing ADD in the real world:
These two problems complicate the adoption of a method such as ADD. For architects without experience, it is difficult to be confident in the selection of patterns and tactics. For experienced architects, adopting a method is difficult because it may not be clear how to connect their real-world experience to abstract design concepts like patterns and tactics.
This tutorial is aimed at people interested in practical architecture design. Some experience in designing software architectures (with or without a method) is desirable. The tutorial starts with a presentation of an extension to the ADD method that addresses the two problems previously discussed. This presentation is followed by an exercise in which participants will perform the design activities, combining a selection of tactics and patterns with a selection of frameworks. The exercise will put into practice the concepts discussed in the presentation. The tutorial concludes with a discussion in which we share experiences and identify ideas about how to address the two problems described above.
Dr. Humberto Cervantes is a professor at Universidad Autónoma Metropolitana–Iztapalapa in Mexico City. His primary research interests include software architecture design methods and their adoption in industrial settings. Dr. Cervantes is also a consultant for software development companies in topics related to software architecture. He has helped Quarksoft, a leading Mexican development company, to integrate architecture methods with the Team Software Process (TSP) and Capability Maturity Model Integration (CMMI). Dr. Cervantes holds a PhD degree from Université Joseph Fourier in France, and he has received the Architecture Professional and ATAM Evaluator certificates from the Software Engineering Institute.
Dr. Rick Kazman is a professor at the University of Hawaii and a visiting scientist at the Software Engineering Institute. His primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is the author of over 100 papers and coauthor of several books, including Software Architecture in Practice and Evaluating Software Architectures: Methods and Case Studies. Kazman was one of the creators of the SAAM (Software Architecture Analysis Method) and the ATAM (Architecture Tradeoff Analysis Method). Dr. Kazman received the B.A. and M.Math degrees from the University of Waterloo, an M.A. degree from York University, and a Ph.D. degree from Carnegie Mellon University. He is a senior member of the IEEE.
T10: Architecture and Release Planning
Philippe Kruchten, University of British Columbia
Robert L. Nord, SEI
Ipek Ozkaya, SEI
Release planning is the decision process by which we decide what we are going to do next in a software project for the best of its stakeholders, in face of all the uncertainties inherent in such an endeavor. While a simple strategy can focus on "delivering value," this rapidly becomes more complicated when we take into consideration dependencies, costs and benefits, software architecture work, defects, technical debt, the uncertainties on estimation, multiple stakeholders to satisfy, and the impact of time.
In this tutorial, we will
Philippe Kruchten has been a software architect for 35 years, first at Alcatel and then at Rational Software (now IBM), working mostly on large technical systems in telecommunication, aerospace, defense, and transportation. In 2004 he became a professor of software engineering at the University of British Columbia, in Vancouver, where he teaches software project management and entrepreneurship and conducts research on software processes—what does it really mean to be agile?— and on software architecture, including architecture knowledge management, technical debt, and complexity. He is the founder of Agile Vancouver, a senior member of the IEEE Computer Society, and a professional engineer in Canada. He has given presentations and tutorials all over the world, including Agile Conferences, Scrum Gatherings, the Java and Object Orientation Conference, and the International Conference on Software Engineering. For more information, visit http://philippe.kruchten.com.
Robert L. Nord is a senior member of the technical staff in the Research, Technology, and System Solutions Program at the Carnegie Mellon Software Engineering Institute. He is engaged in activities focusing on agile and architecture at scale and works to develop and communicate effective methods and practices for software architecture. He is coauthor of the practitioner-oriented books Applied Software Architecture and Documenting Software Architectures: Views and Beyond. He earned a PhD in computer science from Carnegie Mellon University and is a distinguished member of the Association for Computing Machinery.
Ipek Ozkaya is a senior member of the technical staff in the Research, Technology, and System Solutions Program at the Carnegie Mellon Software Engineering Institute. She works to help organizations improve their software development efficiency and system evolution. Her work focuses on software architecture practices, software economics, and requirements management. Ipek serves as chair of the advisory board of IEEE Software magazine and as an adjunct faculty member for the Master of Software Engineering Program at Carnegie Mellon University (CMU). She also organizes events such as tutorials, workshops, and sessions and is an invited speaker at software engineering, agile, and architecture venues such as ICSE, OOPSLA, SATURN, and WICSA. She holds a doctorate from CMU.
April 29 – May 3, 2013
Get the latest SATURN news, important dates, and announcements on the SATURN Network blog, sign up for our email updates, follow us on Twitter (@SATURN_News, #SATURN2013), and join the SATURN LinkedIn Group.
Phone: +1 412-268-5800
Toll Free (within the USA): +1 888-201-4479
FAX: +1 412-268-6257
Please tell us what you
think with this short
(< 5 minute) survey.