May 16-20, 2011 | San Francisco Airport Marriott in Burlingame, California
Architecture in the Age of Compositionality
Jan Bosch,Vice President of Engineering Process and head of Central Mobile Technologies, Intuit, Inc.
The nature of software engineering is changing. Whereas building systems was previously the predominant activity, the focus has more recently shifted toward composing systems from open-source, commercial, and proprietary components, and to only build the functionality that truly is competitively differentiating. In addition, the way software is developed has changed, focusing especially on short development cycles and frequent (or even continuous) deployment.
Because of these requirements, teams are often organized around features, rather than components, and can change all components in the system, including their interfaces. A third trend is the increasing adoption of software ecosystems, where significant development of functionality relevant for customers occurs outside the platform organization. Obviously, however, the quality attributes necessary for system success remain important, as well as the ability to easily incorporate new requirements into the system in a cost-effective fashion.
As a result, the role of software architecture (and that of a software architect in particular) is more important in this new world, but there is significant evolution in its implementation. This talk starts by characterizing the new approach to software engineering and the role of compositionality. It then explores the implications for software architecture and the role of the software architect. The talk will present examples from several industries to illustrate specific focus areas.
The Intimate Relationship Between Architecture and Code: Architecture Experiences of a Playing Coach
Dave Thomas, CEO of Bedarra Research Labs, Managing Director Object Mentor
Why is that with so many architects we have so little true software architecture, so much technical debt, and such large intractable legacies? Perhaps it is the fault of the developers who are not listening; not conforming to the architecture guidelines; style; patterns; or UML models. Perhaps it is the fault of profit-driven organizations, which devalue architecture and opt for near-term gratification, thereby encouraging corruption of the code base and violation of the architecture. Clearly it can't be the architects' fault—after all, more and more of us are now certified architects! Or... are we part of the problem? Are our disparate views, from the ivory tower of enterprise architecture to the dismissive Agile developer's emergent architecture, really helping? In the end, our job is to produce software that meets the requirements of both today and tomorrow. Good software is a marriage of architecture and code reflecting the team that designed and built it.
In this talk, I explain why architecture needs to be intimately composed and refined along with the code, and argue that architect is a role, not a job. In my experience, architects with "no code on their hands" have limited positive impact, and even worse, may have substantial negative impact. Architects must express the essential architecture in a tangible way that is easily, effectively, and practically communicated to developers and testers. It is time to put an end to the whole idea of non-functional requirements that get dispatched to specialists who are patched in at the end of the life cycle. Given that what we ship is code, it is imperative that the architecture become an integrated part of the code. We cannot continue to produce "Once upon a time..." diagrams on the wall or cryptic architecture description languages known only to archbishops and call them "The Architecture." We need to abandon the notion that embedded or database applications are special, and are therefore exempt and lacking tangibility. Only if the architecture and code co-evolve can the product retain its architecture and evolution history.
Architecture at Internet Scale: Lessons Learned from Serving Half a Billion Customers
David Chaiken, Chief Architect, Yahoo!
Imagine that your boss walked into your office and asked you to
Let's say that you resist your initial impulse to run screaming for the door. What do you do? Where do you start?
It turns out that the principles that you've learned as an architect equip you to deal with systems at Internet scale, but there are some important lessons to learn from building these systems.
This keynote stress tests our understanding of how to manage complexity, the core challenge that architects try to solve on a day‐to-day basis. It draws from large-system use cases to show how to apply basic principles of software architecture to balance requirements and constraints. For example, a use case from a system that processes more than a billion transactions per day demonstrates how to solve simultaneously for the well-known principles: "don't optimize prematurely" and "don't pessimize prematurely." Other case studies show how architects can work with a variety of stakeholders (engineers, business analysts, product managers, executives, and others) to find creative solutions to challenging systems problems. Analyzing these real-‐world examples gives a realistic but encouraging view of the evolving role of software architects in our industry.
May 16-20, 2011
SATURN 2011 Conference
News from SATURN
SATURN Network Blog Posts
Get the latest SATURN news, important dates, and announcements on our blog, signing up for our e-mail updates or following us on LinkedIn.
SEI Customer Relations
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.