Join the SATURN Technical Committee, speakers, and staff for a networking reception that includes light snacks and the chance to ask questions about the upcoming conference. If this is your first SATURN conference, we can help you navigate the program and find the sessions that you’re really interested in attending. Plus, you can meet other attendees and make new contacts.
The right architecture can make or break a project, or an entire company. Participants will learn what architects do, why it is important, and some tips on how to talk about architecture with stakeholders. We'll start with some definitions and case study examples of how architecture supports business goals. Then we'll dig into how an architecture's separation of concerns helps us deal with complexity. We'll also look at some rules of thumb for creating good architectures, consider how to incorporate architecture into agile projects, and finish up with a map of architecture-centric processes.
"It's just a detail." Have you ever said that or been told that? Whether it's about implementation or requirements, we often use the word detail to suggest that something is not important enough to worry about. There are so many things to worry about in software development that we need to prioritize—too much detail, not enough focus. The problem is that in software, the details matter because that is what software is: lots of details brought together in combination. If we don't focus on the details, we get debt, defects, and delays.
The success of your DevOps team depends on collaboration between developers and cloud operations teams, the maturity of development processes, security architecture, guiding software architecture principles, and the ability of the team to automate the delivery of software and infrastructure to customers. These factors, along with infrastructure management and integration challenges, are amplified in a cloud or hybrid environment. UPMC Enterprises is the commercialization arm of UPMC. Our portfolio includes seven health information technology companies and several ongoing initiatives, and our current cloud footprint consists of 12 nonproduction and 8 production environments. In this presentation, we will describe our DevOps implementation plan from inception to cost management. We’ll share our operation automation practices and security guidelines for integrating cloud-based services and solutions with on-premises systems. We’ll compare deployment automation options and container management approaches. And we’ll review our software choices, which included packages provided by vendors such as Amazon, Microsoft, and Dell and open-source software such as GitHub, Artifactory, Jenkins, Docker, and Kubernetes. We will summarize challenges we faced during this initiative, its positive impact on the organization, and our DevOps roadmap for 2017.
Getting the right attention and setting priorities for development projects can be hard, especially now that many product businesses try to adapt to a world of online services and new revenue targets. As an architect, you understand the value of all the tasks in your backlog, but a limited budget and deadlines force you to prioritize. Inspired by the Strategyzer books, we applied value proposition design to build transformation plans for some of ASSA ABLOY Scandinavia’s software products. We profiled our customer’s jobs and pain points and matched them to values enabled by our software products. Gaps between the stories of our customers and the functionality in our software helped us prioritize our backlog and build a plan that our sales and business colleagues could understand. Do you want to overcome lengthy backlogs and tight development budgets? Would you like to win over your stakeholders by delivering customer value quickly and iteratively? In this session, you'll learn how to use Strategyzer's value proposition design method to prioritize and communicate your development plan.
The right architecture can make or break a project, or an entire company. Participants will learn what architects do, why it is important, and some tips on how to talk about architecture with stakeholders. We'll start with some definitions and case study examples of how architecture supports business goals. Then we'll dig into how an architecture's separation of concerns helps us deal with complexity. We'll also look at some rules of thumb for creating good architectures, consider how to incorporate architecture into agile projects, and finish up with a map of architecture-centric processes.
We want our organizations and systems to be agile. We want them to evolve with the needs of the business, customers, and stakeholders and to be resilient in the face of changing market conditions and the external environment. The architecture of the systems we create must support adaptability and responsiveness. Meanwhile, the complexity of the environment is increasing, with cloud, DevOps, continuous deployment, and microservices adding to the factors that architects must consider. Larger systems and larger organizations have more dependencies that must be managed and more stakeholders whose needs must be addressed. To create resilient and antifragile systems, architects need the ability to dynamically shift their decision-making approach to help them better navigate the complexity of their environments. Participants in this hands-on session will learn how to apply lessons from complexity science—in particular, sense making and the Cynefin framework—to become more agile and, in turn, develop architectures that are more agile and adaptive to the needs of the organizations they serve.
Some business processes in medical diagnostics involve many large-scale systems distributed through the Roche enterprise and customer clinical laboratories. The systems fulfill valid purposes, can operate separately, and are managed for their own purpose rather than the purposes of the whole. Allocating business functions to specific system components and defining interfaces present significant challenges for architecting such large and complex IT and software system-of-systems (SoS). It requires supporting decision criteria with data and accommodating fast evolution of the architecture. For architecting SoS in Roche’s product context, we defined a customized method based on the U.S. Department of Defense Architecture Framework. The method has six steps, with start/finish criteria and deliverables for each. In this talk, I will illustrate the steps using examples from Roche. The method can be applied in Agile projects if the sprints are oriented on implementation of workflow. The customized method for architecting SoS at Roche was applied to business processes related to Remote Solutions and the Internet of Things. It facilitated quick definition of models, derived data to support decision making and allocation of business functions and resources to existing and to-be-developed systems, and identification of common resources and interfaces for their exchange.
The key concepts in DevOps are CALM: Culture, Automation, Lean, and Measurement. How does an architect support the transformation to DevOps in the four CALM areas?
In this presentation, we'll talk about patterns, interactions, and behavior that architects will want to consider to keep CALM in the face of DevOps.
In this talk, we view software architectures as systems of connectors. Physically independent connectors decouple components without performance costs. Services optionally built into connectors intersect orthogonally with component functions. Connectors considerably simplify DevOps scenarios in industrial environments. Connectors are a means of realizing blue/green deployments, canary releases, and performance monitors, all of which are necessary for DevOps scenarios that work in industrial environments. The presentation is divided into four parts. First, we introduce the minimal connector and explain the consequences and benefits of developing, testing, and configuring component systems. Second, we develop the minimal connector into light connectors containing plain interfaces (call and callback) and then into heavy connectors with additional extra-functional services. Third, we apply connectors for structuring a system whose development follows the DevOps methodology. Finally, with a better understanding of our motivation, objectives, nature, assemblage, and application of connectors in our practice, we work out similarities and differences in comparison with the Interceptor pattern and Component-and-Connector views.
Too much design up front, and you could lose time. Not enough design, and your system could crumble in reality. How do you make the right decisions at the right time, and make them with due diligence? How do you embrace the cloud and microservices without risking different failure scenarios or overly complicated maintenance and ripple effects? Product Thinking—understanding the use and need—is critical to avoid over-engineering a product. In this session, we will walk through visualizations that help teams blend product thinking with architecture. Along the way, we will look at microservices, domain modeling, chaos engineering, and fault tolerance and how to emphasize the right strategy at the right time. You will leave this session with simple visualizations and approaches that you can apply immediately to start blending product with architecture, especially if your system will run the cloud.
Being the only software architect in a company with many fully autonomous and agile development teams can be exasperating. The role looks simple on paper: drive good, technical solutions to business problems. But with so much going on at any given moment and constant iteration, affecting outcomes across the organization is impossible. If you can't even keep up, how can you meaningfully engage in the decision-making process? In this environment, “command-and-control”-style architects encounter significant opposition and find themselves ineffective. Instead, let’s explore a different approach. The Influential Architect is fusion of advisor, mentor, facilitator, communicator, and storyteller. As an Influential Architect, our aim is to improve outcomes across the organization without it becoming reliant on us to make key decisions. To achieve this, we must change the level of abstraction: where previously our purview has been decisions, we must now focus on people. In this talk, we'll explore what it means to be an Influential Architect, as well as some of the tools and techniques we can use to succeed. We'll cover transparent decision making, technical vision, visual storytelling, architecture principles, sensible defaults, strategic thinking, team suitability, architect suitability, and evaluating outcomes.
Architecture is critical for business success. A solid architecture helps prevent defects and system failures. It helps a development effort save money and get quality products to the market faster. Most software-reliant systems are required to be modifiable and reliable. They may also need to be secure, interoperable, and portable. Data demonstrates that the most costly technical debt that organizations are struggling with results from making poor architectural choices and inadequately managing architectural decisions. How do you know whether your software architecture is suitable or at risk relative to its target system qualities? How do you assess whether it has technical debt? This Architecture Boot Camp session covers practical and proven architecture analysis and evaluation techniques that identify risks early in the development lifecycle, using scenario-driven peer reviews and the Architecture Tradeoff Analysis Method (ATAM), a tested process that has been used in many evaluations over the past 15 years. In addition, it covers a practical and easy-to-implement approach for making technical debt visible through an organization’s issue tracking system.
Have you heard the term container without fully understanding what it means? Then this session is for you! Containers are lightweight virtual machines that have become default packaging mechanisms for deploying systems. Docker is the pre-eminent container system. This session will provide some theory of containers and explanations of how containers work. Then in a supervised hands-on experience, participants will build, execute, deploy, and save a Docker container in a repository. Attendees should have preloaded Docker and executed "Hello World" before the session.
Failing fast, failing forward, and learning from failure are all the rage in the software and technology industry right now. Tech company "unicorns" talk endlessly about how they reframe failure as success. Yet many of us are still required to design and implement backup system capabilities, redundancies, and controls into our software and operations processes. And when those fail, we cringe at the conversation with management that will ensue. So is all this talk of reframing failure as success within our organizations just that—talk? In this interactive session, we'll cover
Agile software development methodologies are now mainstream. But one nagging question that teams face is “How do we establish the architecture for a system in an agile way?” Architectural decisions have a key impact on various system qualities. Therefore, these decisions must be made early and carefully. How do you avoid BDUF while applying incremental and iterative agile methodologies, meeting architecture requirements, and mitigating risk? In this session, I will use concrete examples from real projects to cover
Software development has evolved. Agile is now the de facto standard. The role of an architect in an agile project is very different than the typical role in a more classic waterfall approach. Using an updated interpretation of “viewpoints and perspectives,” this talk will demonstrate how to make rapid, agile delivery sustainable in a constantly changing world. These viewpoints and perspectives will be linked to easy-to-produce models that can be used immediately in your projects. The talk will provide examples of how to determine which models are architecturally significant and worth the effort. Developers have always been very important stakeholders of an architectural description. A good agile architect needs to strive for consensus and buy-in.
Docker has matured and is expanding from being predominantly used in the build and test stages to production deployments. Similarly, microservices are expanding from being used mostly for green-field web services to being used in the enterprise as organizations explore ways to decompose their monolith to support faster release cycles. Running microservices-based applications in a containerized environment makes a lot of sense, for both build and test as well as for runtime in production. Docker and microservices are natural companions, forming the foundation for modern application delivery. However, managing microservices and large-scale Docker deployments poses unique challenges for enterprise IT. This talk describes the modern requirements for building, deploying, and operating microservices on a large-scale Docker-ized infrastructure. It covers
Office-hours sessions are conducted by some of our conference speakers. The sessions give attendees a chance to meet with these experts directly and explore their ideas in greater depth.
Scheduled for this session are:
Sairam Tadigadapa (3 - 3:30)
J. Paul Reed (3:30 - 4:30)
As the pace of innovation increases, IT groups are using agile approaches and short release cycles to deliver systems rapidly. As a result, IT architectures evolve quickly, and validating architectures a few times is not enough. We present a new approach for continuously validating architectures. The objective of this architecture validation technique is to ensure that the future system meets its business objectives and quality attribute requirements, without slowing down the pace of continuous delivery. This presentation describes how to use our approach to validate architectures in any type of project. First, we define what we mean by Architecture Validation. Then we focus on when to conduct Architecture Validations. We then discuss the roles required in an Architecture Validation. We finally detail how we conduct architecture validations by describing some industry-recognized techniques such as questionnaire-driven approaches, scenario-based approaches, and decision-based approaches. To illustrate the concepts introduced in this presentation, we will use a real-life example of Continuous Architecture Validation, showing how various approaches can be combined to effectively validate a project.
Software architects need to have it all: exceptional technological know-how, up-to-date programming experience, good people skills, ability to abstract, knowledge of important architectural styles and tactics, and visionary leadership. It has always been difficult to find all of these aspects in a single person. Modern development efforts set in highly dynamic, agile contexts and the emergence of polyglot technological environments make it even more challenging. This talk introduces alternatives to the classic role of the software architect that showed a boost in delivery speed, overall product quality, and organizational flexibility in real-life projects of various domains. The alternatives work well in an agile project setup and embody a distributed approach of handling architectural concerns. The talk covers important factors for choosing between the approaches as well as the core concepts that make them effective even in more complex environments, including low-viscosity design, architecture communities, and tests of quality attributes.
In this talk, I will share lessons learned from implementing microservices architecture for a regulatory initiative as the Director of Software Engineering at Capital One. The talk will cover the business drivers for the microservices architecture, the lessons we learned from an architecture perspective, and why DevOps practices were important. Key success factors included moving to the cloud, using DevOps methods, and employing domain-driven design. Other practical considerations involved handling production support issues and increased complexity. I will also discuss what cultural and software engineering best practices helped most and some specific communication imperatives to emphasize when you are building an enterprise microservice.
Mission-critical and even safety-critical applications have crept into the Internet of Things (IoT). In these applications, failure might lead to injury and even loss of life. This talk will present the architectural challenges that come with deploying mission-critical IoT systems in hazardous industries. Attendees will learn about hazardous industries, some of their challenges, and how the IoT can help. We will dive into new challenges that have emerged in the IoT, the need for trustworthy software, impacts on software architecture, and finally how to mitigate the threats from common mode failures, human error, and even malware. These things must be addressed before we have problems, not as a post-mortem of a capsized system.
I wrote my first program in the Spring of 2001, around the same time Mr. Agile moved into my neighborhood. I didn’t get to know him until early 2004 when his entourage grew into a dedicated community of fans and followers. Back then, I had one trusted mentor and an old friend, Mr. Architecture. Becoming friends with Mr. Agile was new and exciting but brought challenges to my relationship with my old friend. Therefore, growing up as a software professional was about learning how I could maintain friendships with both, reconcile their differences, and become better at what I do because of it. In a nutshell, I grew up in Mr. Agile’s world.
In this DEV@SATURN talk, I’ll narrate the story about growing up as friends with Mr. Agile and Mr. Architecture. I don’t intend to indulge the “agile vs. architecture” debate. On the contrary, I’ll annotate my story with examples from our journeys together, sharing experiences with some of Mr. Agile’s friends who advocated architecture sabotage as well as situations where the outcomes were better because I had a foot in both neighborhoods and had won the internal struggle about how to reconcile them. Join me in this talk—I’m sure you’ll find resemblances to your own journey.
Sponsored by Travelers. Starting at 6:00 p.m. on Tuesday evening, buses will transport SATURN attendees from the hotel entrance to Wings Over the Rockies, Air & Space Museum, a WWII-era hangar, built in 1939, that sits in the heart of Denver’s historic Lowry neighborhood. There, we will enjoy a buffet dinner and drinks in the museum’s main hangar, socialize and try out the museum’s MaxFlight and Aviation Xtreme simulator, and view other aircraft exhibits in the hangar. SATURN guests will also be able to see the Da Vinci Machines Exhibition “Discover the Architect of Flight!” Buses will return attendees to the hotel throughout the evening and after the reception concludes.
The microservice architecture is becoming increasingly popular. However, frequent references to using “a microservice to solve a problem” suggest that the concept is not universally well understood. In this talk, I define the microservice architecture as an architectural style and explain what that actually means. I also describe how the primary goal of the microservice architecture is to enable continuous delivery and deployment, and how it achieves that. You will learn why the architecture that you pick for your application matters. And you will learn how to solve key challenges with decomposing an application into microservices. This talk explains why there is no such thing as a microservice!
A myriad of point tools, frameworks, and infrastructures are involved in your software delivery process. While many of these tools are free and open source, the operational and technology overhead of orchestrating the hand-offs from one tool to the next in the process are not without cost. To improve developer productivity and resource utilization—and to enable enterprise-scale, cross-project visibility and shorter time to market—organizations are working to automate the entire tool chain across the end-to-end delivery pipeline. This presentation will use a real case study to show how you can orchestrate your entire software delivery pipeline. Learn how to create a fully automated release pipeline by tying in common tools that you likely use in your process from CI build to release: including Git, Jenkins, Selenium, Chef, Docker, and more. Seamlessly orchestrate third-party tools to automate your entire process from start to finish, get visibility into your end-to-end application release pipeline, and deploy any application to any environment using any tool set—for free.
For 40 years, cyclomatic complexity has been the de facto standard for measuring testability and maintainability. While it's absolutely accurate for testability, the same can't be said for maintainability. Cognitive complexity solves the problem and returns "fair" relative measurements of control flow complexity. In this session, you'll learn what the cognitive complexity methodology is and why you should add it to your metric suite. You’ll see how it applies to a number of code samples from open-source projects on SonarQube.com. And you’ll learn how to use a method's cognitive complexity score as a guide to designing better code and refactoring existing code to be simpler and more maintainable. Because there's no "cost of entry," high class-level cognitive complexity is a reliable indicator that a class contains a lot of logic, not just a lot of methods. That is, you can use cognitive complexity to sift domain classes from the logic-intense classes that impose a higher maintenance burden. Cognitive complexity is already available as a new rule in some Sonar code analyzers and should be available throughout the SonarQube ecosystem by the end of 2017.
Designing, developing, and deploying microservices is changing dramatically with the introduction of container technology like Docker. Individual microservices are deployed via immutable containers, and with a growing number of containers the need to manage them becomes critical. Kubernetes is an open-source specification as well as a reference implementation for container orchestration. Applications can be built, tested, and deployed via continuous integration and delivery pipelines using an integration of Kubernetes and Jenkins pipelines. This presentation will give an introduction to Docker and Kubernetes and then dive into microservices development and deployment using CI/CD pipelines. The open-source nature of the full stack allows deployment to public as well as private clouds. One of the demos will run on a cloud-in-a-box mini private cloud running on ARM64-based open-source hardware.
A few decades ago when the first architecture books were being written, today's large-scale web systems were an oddity, but now they are mainstream. Our architecture pattern languages have changed as have our development, deployment, and operating procedures. During this transition, one source of ideas has been the functional programming (FP) community. FP itself mostly happens within a module, and many software architects treat it as an implementation choice, unrelated to architecture. But some ideas from the FP community are helpful in architectural design: statelessness, immutability, and pure functions. They underlie DevOps practices and are at the core of many distributed systems patterns in our architectures. Although functional programming ideas have been around for a long time, conditions are ripe for applying them now. This talk surveys how modern web systems are built with FP patterns, shows how they work, and considers why they are increasingly popular. We will dig into one client-side example and demonstrate how FP ideas can simplify tasks.
As your organization invests in DevOps to release more frequently, you need to treat the database tier as an integral part of the automated delivery pipeline—you build, test, and deploy database changes just as for any other part of your application. However, databases are different from source code and pose unique challenges to continuous delivery, especially in the context of deployments. Updating the database can be more demanding than updating the application layer: database changes are more difficult to test, and rollbacks are harder. Furthermore, for organizations that strive to minimize service interruption to end users, database updates with no downtime are laborious operations. Your database stores transaction data, business data, and user information—the most mission-critical and sensitive data of your organization. As you update your database, you want to ensure data integrity; atomicity, consistency, isolation, and durability (ACID); and data retention and have a solid rollback strategy in case things go wrong. This talk covers strategies for database deployments and rollbacks.
The cloud has enabled reduced time to market and low startup cost in the software industry, but designing applications with resiliency is an enormous task. While the cloud is ubiquitous, cloud failures are unavoidable, unpredictable, and risks to the systems. Traditional approaches can’t predict all failure modes because of changing data conditions, complex request patterns, ever-increasing innovation, and growing scale. Chaos engineering is a discipline to simulate failures. In this talk, we describe our Cloud Detour solution, a chaos engineering approach that subjects applications to failures in the cloud and helps them weigh against resiliency levels. Mission-critical applications can register themselves to test against several failure scenarios and demonstrate their resiliency level. Cloud Detour can help you develop solutions that provide adequate resiliency and a solid disaster recovery strategy.
A dependable cyber-physical system (CPS) correctly performs the functions for which it was conceived in its intended environment, without adverse effects. In particular, a dependable CPS responds correctly and timely even in situations where system parts have failed, either temporarily or permanently. This requirement also applies when tests check reliability, availability, and performance properties of these systems in the lab and in the field. A CPS with test probes built into all hardware and software components throughout its lifecycle can fulfill these requirements. Tests of such systems require that their architecture be designed for testability. Starting from here, we first characterize the CPS we use as an example: an integration platform of an X-by-wire eCar. We elaborate a series of design tactics that enable or improve the system’s testability, focusing on test probes. Test probes can execute deterministic, efficient, and reliable real-time tests or act as safety monitors that observe and potentially intervene in a system. In this session, you will learn how to design a testable system that incorporates test probes as central system elements and how to write non-intrusive tests that yield reliable results.
An existing REST-based microservice, a new requirement to use gRPC, a team under pressure to ship… In this talk, we describe how we moved backing Watson Discovery microservices from REST to gRPC and the lessons we learned in the process.
The APIs for components in fine-grained service-oriented architectures strongly influence the eventual properties expressed in the system. REST over HTTP is a popular choice for microservices APIs because it promotes openness, self-discovery, and simplicity. One alternative to REST is gRPC, an implementation of Protobuf. As an RPC-based API, gRPC inhibits openness and self-discovery but promotes performance and, depending on the implementation, can provide stronger compile-time (or at least call-time) guarantees, which help developers avoid mistakes. By the end of this talk, attendees will know
At SATURN 2016, I introduced a novel lean approach to developing product architecture that combines Lean Model Canvas, Design Thinking, and Agile practices. This year, I am excited to share a case study of how it was applied at GE Renewables Digital to bring software products to renewables assets. My fellow architects rallied both executive and product management sponsorship to launch two product lines in 2017—Digital Wind Farm and Digital Hydro Plant. This session is based on my experience leading GE Digital Renewables architecture strategy for Asset Performance Management and Operations Optimization. Renewables energy presents unique and diverse challenges to delivering software at scale. Connecting thousands of wind turbines and solar panels, fine-tuning analytics at the edge and the cloud, and assuring NERC compliance through secure DevOps are some of the concerns. I will take attendees on the journey to migrating both existing applications and building brand-new applications on a cloud platform and describe how architecture best practices accelerated the management and minimization of technical and functional debt. The session also presents the tradeoffs both at tactical and strategic levels for moving forward with new technology and capturing market opportunities for innovation leveraging horizontal products.
Being agile, with its attention on extensive testing, frequent integration, and important product features, has proven invaluable to many software teams. When building complex systems, it is easy to focus on features and overlook software qualities, specifically those related to software architecture. Time has shown that agile practices are not sufficient to prevent or eliminate technical debt, which can affect maintainability and reliability. Without good validation through tests and constant attention to the architecture and code quality, many issues arise. It is important to recognize what is core to the architecture and the problem at hand while evolving it. Insufficient attention to the architecture and code can allow technical debt to creep in and become muddy, making it hard to deliver new features quickly and reliably. Two principles that can help teams deliver more quickly and with confidence is to focus on code quality and delivery size. Small, frequent deliveries with constant attention to a good codebase are crucial to sustaining faster reliable delivery. Practices that can help keep the code clean or prevent it from getting muddier include Testing, Divide & Conquer, Gentrification, Quarantine, Refactoring, and Craftsmanship. This talk examines various practices and techniques that lead to better software quality, all of which enable teams to deliver faster and with more confidence.
Most of the AI breakthroughs in the past 4 years have resulted from deep learning. Can deep learning help software developers? Most work in this field has been devoted to metrics and estimates. Metrics are shadows of snowflakes, and thus not particularly informative for understanding the purpose of a system or the behavior of a component. Improving estimation, while an interesting application and a laudable goal, likewise does not directly help developers create better software faster or manage the growing complexity of real-world systems. Can we apply machine learning (ML) in ways that help guide development, inform software archaeology, and reduce effort for developers? If so, can it help us take on the systems-of-systems-of-systems of the future, where million-line code bases will be considered quaint? After a brief survey of existing work in the area, we'll investigate the question "what does software look like?" and examine the more interesting question of "what does good software look like?" Then we’ll use these insights to explore how ML can enable developers to create and manage ever-larger software systems. No ML experience required. Lots of pretty pictures.
The success of a software architect relies on his or her ability to influence development teams and decision makers and gain trust from other stakeholders. To achieve this, an architect should communicate effectively, encourage the engagement of other stakeholders, deal with their concerns and successfully handle conflict and opposition. In this talk, I will share the techniques, mindset and character traits required for effective technical leadership, based on my own experiences and lessons learned from years of working as a software architect in a global organization and from studying dozens of the greatest writings from the fields of business, leadership, and communication.
Performance is a critical architecture quality attribute, and it is a nonfunctional requirement that is used as an acceptance criterion for almost every project and system. Performance impacts usability and the user adoption rate after the system goes live. But performance issues usually arise during the later phases of a project or during system implementation. The probable cause is a lack of nonfunctional requirements on performance at an early stage of the architectural design. This presentation will show how to salvage a troubled project with performance issues by focusing on performance and storage tradeoffs and using the Architecture Analysis Tradeoff Method (ATAM). I will share a specific tailored solution to move data aggregation and sorting from a backend database to Solr or Elasticsearch as an indexing service so that data aggregation and sorting can be indexed ahead of time and accessed over http through query parameters. I will also discuss performance concerns from end to end in systems that deal with heavy data aggregation and sorting using real-world implementation examples. By the end of this session, you will have some strategies to address performance concerns and turn around a troubled project in a short period of time.
Industry practices around how we develop and deploy software are moving quickly toward a few simple yet wildly influential trends centered on software running and scaling in the cloud. Enterprises and startups alike are adopting cloud technologies, containerization, infrastructure automation, and agile methodologies and applying them to large-scale deployments. As a software engineer on a Cloud R&D team helping enterprise customers adopt these modern trends, Topher has experienced the gamut when it comes to cloud transformation journeys and upcoming trends in how software is developed, deployed, and managed in the cloud. This talk will give an overview of emerging trends covering how cloud-native applications, platform as a service, automation, and infrastructure as code can help with deploying software as well as migrating software from one infrastructure-as-a-service provider to another. Attendees will learn how to navigate through the buzzwords in cloud computing and leave with an understanding of how to deploy, manage, and scale their software in the cloud.
As a software architect for your organization, you may be required to efficiently and effectively evaluate the validity, quality, health, or maturity of a proposed, new, or legacy software architecture. This presentation describes a simple process you can follow to perform a rapid assessment of any software architecture effort, regardless of its size, complexity, or stage of development. It focuses on capturing the most critical aspects of the software architecture, including quality attributes, key architectural decisions, and architectural design. The process emphasizes identifying and documenting references to existing artifacts. It generally requires an interview with the most knowledgeable software engineer on the proposal, development, or maintenance team to identify both available artifacts and information that has never been documented. In the typical two-day process, information is gathered and recorded one the first day. On the second day, the information is analyzed, expert opinions are formulated, and a report is prepared and disseminated to relevant stakeholders. The process is a simple and straightforward mechanism for capturing software architecture and rapidly performing a valuable assessment at any time in the product lifecycle.
Most people have heard of Bitcoin, and they know that blockchain is one of the underlying concepts behind this cryptocurrency. Blockchain is an emerging technology that is receiving a lot of interest—and hype—across enterprises and among analysts. But what does blockchain technology mean for the broader enterprise? It has the potential to greatly disrupt a large number of business processes across various verticals, far beyond Bitcoin. How can blockchain technologies be applied in different verticals, and what does this mean for traditional database-centric approaches? Join this session to learn about blockchain, associated concepts such as smart contracts, and how these technologies may be applied in various use cases and verticals.
Office-hours sessions are conducted by some of our conference speakers. The sessions give attendees a chance to meet with these experts directly and explore their ideas in greater depth.
Scheduled for this session are:
Although Event Sourcing has been around for many years, it remains outside the mainstream paradigm of software development. But it is an approach to building software with a long track record of success. With Event Sourcing, we place the highest value on the simple capture of essential business events without attempting to interpret them. By placing business concepts at the heart of our code, we can decouple systems into small services that can be quickly built, changed, and replaced. The resulting systems have single responsibilities and are decoupled from each other, which makes them simple to modify. Event Sourcing can enable us to move faster by supporting rapid experimentation with new perspectives, new user interactions, and new insights into our business. This talk will show you how.
Over the last decade, the architecture discipline has matured from up-front design to a stream of architectural decisions that address concerns related to ever-evolving software systems. The word stream implies a continuous process, but in real life that stream is far from homogeneous. Architects make decisions that have widely varying impact, based on information with differing levels of uncertainty, throughout the life of a software solution. The way these decisions and their impact are communicated evolves as the audience and focus of the architectural communication change. In this tutorial, we explore the metaphor of a human lifetime to illustrate aspects of architectural decision making throughout a software solution’s lifecycle. Amid the stream of design decisions, we will look for anchor points with common concerns to address recurring communication needs. We will see how the nature of architectural decisions changes from birth (the first architectural outline) to graduation (making the business case), and find guidance on communicating the architecture at times of life-defining milestones like marriage (committing to the architecture) and revolutionary changes to the solution. The points will be illustrated by real-life examples from an interesting case study. The tutorial is based on Risk- and Cost-Driven Architecture, but no prior knowledge of it is required.
This talk introduces “cognitive” APIs, such as those for image recognition, text analysis, recommendations, and predictions. I will explain what cognitive APIs are and how to use them and do a live comparison of four image-recognition endpoints. I will show the similarities in usage patterns and highlight the differences in API design, implementation, and capabilities, including pre-trained APIs and trainable-models-as-a-service. The second half of this talk is a live demo of an e-commerce chatbot that uses a combination of natural-language understanding and API orchestration to deliver commerce features over a conversational interface. I will then explain how the bot is built and where the “smarts” come from. I will discuss the ever-increasing importance of cognitive APIs and how no-screen interfaces like chatbots will stimulate the API economy.
The Colorado River Agency—among other Bureau of Indian Affairs utilities—has a disparate electrical system in Arizona spanning substation, multiple transmission, secondary and primary electrical networks, and apparatus. Information modeling and standards are key to apply reusable solutions.
Passionate individuals and businesses both try to create successful Communities of Practice (CoPs) for myriad reasons, from honest desire to networking to a financially driven goal of sharpening worker skills. Why do some well-funded efforts fail while rag-tag startups succeed? In this session, hear the story of my struggles and successes to grow a networked community of architects that now stretches across the globe. There is no single formula to creating a successful community. But if you've got passion and take the time to really ask "Why?" your journey will start off on the right foot! Choose vision-driven techniques over old-school mechanics to jump-start new groups or resurrect ailing ones. You will walk away energized and ready to try a few of the techniques that worked, such as
Software is an increasing part of our everyday lives. From the phones we carry, to the cars we drive, the thermostats that regulate our homes, even our lightbulbs, software is everywhere. But how much do we know about it? How secure is the banking app you use? What bugs might turn your home into a tropical paradise during your next winter trip? How convoluted is the code that runs your car? The last plane you took? The last traffic light you went through? As consumers, we take nutrition labels on food for granted. A few simple, standard numbers let us make smart choices about the food we consume. Similarly, quality numbers should be routinely available for software, which is omnipresent and unavoidable in modern life. As consumers, we should have the data to make smart choices. After all, candy bars will only kill you slowly. Bad code could kill you very quickly.
Enterprise IT organizations attract and foster mediocrity. This is a fundamental reason why large enterprises don’t outperform leaner organizations even though they have more resources. This talk describes a fictional organization (albeit slightly inspired from reality) with huge cultural problems to illustrate how bad enterprise IT can be and how it came to be this way. In the first half of this session, we describe the mess we're in and how we got there; in the second half, we consider how we could have avoided this situation and how we can get out of it. Our premise is that a solid culture of learning and continuous improvement as well as a focus on good software architecture and practices could have prevented the mess, and that it is not too late to turn it around. I promise an entertaining talk with a lot of humor, and possibly some insights that you can take back to your organization so that you don't end up in the same mess (if you aren't already there).
How we think of architecture shapes what we do as architects, and what we do, shapes how we think of architecture. We will explore our conception of architecture in this dual sense, with an emphasis on visualization and visual expression of design (intention and reflection).
Winner of the 2017 Linda Northrop Software Architecture Award, given to an individual or team that has used software architecture to significantly improve practices, outcomes, or both in an organization or in the software-development community.
Have you heard stories about how systems were designed in an ivory tower by someone who didn’t understand the customer or the goal? Architecture is about the customer. How do you make sure that you are bringing value to the customer through your architecture? Use customer-centric design processes, often called contextual design or design thinking. In this highly interactive session, participants redesign a system by interviewing a customer, creating a prototype, reviewing it with the group, and getting feedback on the design. Using the methods taught in this session, you can create value for your customers through your architecture and become their hero, or at least not the person in the ivory tower who is ruining their lives. Participants will learn
Developing software for complex and ever-changing business domains is challenging enough, but factor in the need to integrate with multiple legacy systems while working closely with business experts and it can feel overwhelming. In EventStorming, developers and business experts use sticky notes to map out an event-based story of how a software system behaves. This improves communication and collaboration, uncovers misunderstandings early, and accelerates deeper domain knowledge. Learn how to facilitate an EventStorming workshop with your team, and see how the approach cultivates shared understanding and improves productivity, especially when designing loosely-coupled, distributed, event-based systems.
Office-hours sessions are conducted by some of our conference speakers. The sessions give attendees a chance to meet with these experts directly and explore their ideas in greater depth.
Scheduled for this session are:
Ken Power (11:30-12)
This talk introduces serverless computing, a new paradigm for deploying applications in the cloud that requires no server administration and which scales transparently in both function and cost. With the release of AWS Lambda and API Gateway, it has become possible to build RESTful interfaces without managing a server infrastructure. Leveraging these and other AWS services, you can build entire business applications in a secure, scalable fashion, without provisioning virtual machines or taking on the system administration tasks that entails. There has since been a lot of buzz around “serverless” development, with entire frameworks and tooling built to support such an approach. In this talk, I will discuss the tradeoffs of taking such an approach, how to technically execute such an approach within AWS, and what my own experiences have been in building and running serverless applications in production. My goal is to equip attendees with enough knowledge to be comfortable trying this approach.
Rackspace has been in a hyper growth pattern for many years. The rate of change has presented significant challenges for the software transformation journey we experience in a fast-moving environment, where agility and producing tangible, timely business output is the key. In this presentation, a team of architects from Rackspace will present the enterprise-wide SOA transformation that we are guiding at Rackspace. We’ll detail the legacy ESB mayhem, use cases and decisions, introducing service-oriented architecture, our progress toward continuous integration and delivery, RESTifying Rackspace, lessons learned from this project, and future plans. At the end of the presentation, attendees will be able to relate our case study to similar technological transformation challenges they face at their organizations and to apply some of the suggested guidelines for accomplishing large-scale technology transformations.
Some call it the fourth industrial revolution. Some call it the age of digitalization. No matter what you call it, we are harvesting more and more data about people and businesses. This data is then connected to other data and exposed as services, which need to be protected properly. As software architects, our primary security goal is to write secure software. Secure software has a technical aspect that is well covered (if not understood) in developer literature, but there are also human and organizational aspects of security that software architects must manage. These aspects often go beyond the boundaries of the software development organization and are influenced by forces well beyond the company walls. On the path to security, many tradeoffs will be made, and some of them are made outside the IT organization. After working for more than 20 years in large organizations, I have found certain signals that can be used to identify whether you have a weak security culture. In this talk, I will cover topics such as balancing prevention, detection, and response; balancing short-term gains with long time security impact; handling security incidents; and communicating security concerns beyond the IT organization.
The modern web developer has an unenviable task. Users have become familiar with popular web applications and expect perfect uptime, bug-free experiences, a simple and intuitive UI, and perfect security. Fortunately, the proliferation of high-quality frameworks for virtually everything—frontend, backend, and infrastructure—has made the developer’s job much easier. In this talk, I'll outline how my team used the Django web framework and Twitter Bootstrap to build a complete production reporting solution in less than three months. These tools are incredibly powerful and can save you hundreds of hours of work. We'll also discuss the tradeoffs associated with training and the impacts of choosing to train your team extensively or more sparsely on the tools you develop. After we describe the benefits of using Django and Bootstrap, we'll explain how to set up your team for success. We've had great success using these tools to quickly build complex business applications and user-friendly, maintainable, modular web applications. You can too!
Office-hours sessions are conducted by some of our conference speakers. The sessions give attendees a chance to meet with these experts directly and explore their ideas in greater depth.
Scheduled for this session are:
“Serverless” is a newly popular buzzword and, as with many technology buzzwords, is a complete misnomer (“cloud,” anyone?). In this session, we will discuss what serverless really means, what the differences are among various providers, why you would consider using a serverless architecture, and how you would implement one. We’ll discuss greenfield development as well as a migration path for existing web applications. Other topics will include how the development workflow will change and why, what testing will look like in a serverless world, and some pitfalls to avoid. While a serverless approach can be applied to applications written in a variety of languages, JavaScript will be the language used for this talk, so we will examine some popular serverless JavaScript frameworks, including apex.js, claudia.js, and serverless.js. If you’re interested in full-stack development, DevOps, microservice architecture, containers, cutting operational costs, or just keeping up with the latest application architecture approaches, this talk is for you. For this 90-minute, interactive, participatory workshop, you will need a laptop, a GitHub account, and an Amazon AWS account.
The software architecture discussed and carefully created is often not entirely followed in the implementation. In this session, we'll look at an easy-to-use, automated solution to improve architecture conformance. This solution has been successfully applied in a mid-size organization for the past six years. It uses free open-source tools and helps raise architecture knowledge across the development team. Through examples and guided exercises, you'll learn the basics of a free open source static analysis tool for creating custom checks in Java for architecture conformance. We'll also discuss strategies for how to enforce the architecture continuously by integrating the custom checks to your CI infrastructure and how to make this setup effective. In this session you'll do some basic coding. To execute the activities, bring your laptop loaded with JDK 1.7+ and Apache maven 3+.
Documenting architecture design decisions is commonly considered a good practice, but few teams take the time to write down the decisions they make. This happens for a few reasons: architecture documentation is rejected as being too heavyweight, documentation is typically out of sight and out of mind, and many developers don't know what to document. Architecture Decision Records (ADRs), a lightweight documentation approach proposed by Michael Nygard, solves these problems by recording design decisions in a simple markdown template in the same repository as the code affected by the ADR. In this talk, we will share our experiences and lessons from using ADRs over the past year while working on multiple projects for IBM Watson. By the end of this talk, you will be able to create effective ADRs, introduce them to your team, and avoid common pitfalls with the method.
We present a battle-proven architecture for collaboration between loosely coupled actors that share their state using an immutable store and a publish-subscribe pattern. Our data model is suitable for high-performance and complicated algorithmic flows, where multiple threads require access to shared in-memory objects. Our method of managing shared state supports high-performance data-driven and event-driven applications, with generic handling of persistence, record/replay, and application logging. We have implemented it in C++ and used it successfully as the application framework for the iTero intra-oral scanner.
The software development community is slowly realizing that maximizing the velocity of delivery is paramount. As Jack Welch said, "If you are not moving at the speed of the marketplace, you’re already dead—you just haven’t stopped breathing yet.” But it's an unfortunately accepted actuality that the software development and delivery velocity of an organization inexorably decrease over time. This happens not just in the context of a single codebase, which could be explained mostly by straightforward technical phenomena, but also across entire teams or companies. In this talk, I'll draw on my experiences with companies from tiny (startups I've co-founded) to large (Microsoft, Google) to offer some observations about the reasons behind the apparently unavoidable slowdown that software development teams experience. These reasons range from purely technical, such as the accretion of technical debt, to organizational and legal. But it's not all bad news: I'll also suggest a few concrete techniques that I've seen have a positive impact on velocity in software development.