Tutorials


Tutorial T1: Architecting Cloud Computing Applications

Anna Liu, NICTA, Australia - Monday 20, Morning

Description
There is an emergence of cloud computing application development and deployment platforms such as Microsoft Azure, Google's AppEngine and Amazon's EC2/SimpleDB/S3. Startups and enterprise developers alike, lured by the promise of 'infinite scalability', 'ease of development', 'low infrastructure set up cost', are increasingly using these cloud service building blocks to construct their web based application, that in turn consume and deliver services. In this tutorial, we firstly provide an overview of these cloud computing platforms, both in terms of the technical platform architecture as well as the corresponding vendor business strategy. We also highlight the various service delivery and deployment models in cloud, and how different end user organisations may make use of the various cloud capabilities in accordance to their business goals. Next, we present some of our cloud platform evaluation and benchmarking results, and present our insights into some cloud architecture internals, cloud platform behaviour characteristics, and how the differences across various cloud platforms may impact the way cloud application developers will need to optimise their architecture design for different clouds. We will also present the architectural challenges of building high performance, high availability, totally consistent and highly scalable cloud applications. Lastly, we present a set of case studies based on NICTA's experience in working with some of the early adopters in Australia and around the world. We illustrate how cloud computing can be effectively used in a range of business contexts, and the corresponding architecture solution patterns. We will assume some basic understanding of software architecture and enterprise architecture experience from the attendees. For the industry attendees, this tutorial will present research and evaluation results and proof of concept experiences that will help with their evaluation and adoption of cloud computing. For the researchers/academics, this tutorial will present industry case studies, and technology insights that will help shape and validate their future research directions. The architecture analysis and evaluation techniques should be of interest to both researchers and practitioners.

Presenter’s bio
Anna Liu is currently a Research Leader at NICTA, heading up a team of 30 software engineering and software architecture researchers and PhD students. She also holds a Conjoint Associate Professorship at the School of Computer Science and Engineering, University of New South Wales. Her currently research interest is in cloud computing application design and development techniques for performance and scale. Prior to returning to academia, she was a Principal Software Architect at Microsoft Australia, leading various service-oriented architecture and enterprise application integration projects for financial services organisations and government agencies. Previously, she was a research leader at the CSIRO, in the area of component based software engineering and middleware technology evaluation. She has held visiting scientist appointment at the Software Engineering Institute SEI/CMU, and has presented numerous tutorials at international conferences including OOPSLA 2003, OOPSLA2005, ICSE2001 and WICSA2000.

- Top -



Tutorial T2: Architectural Knowledge Management with Semantic Wikis

Remco de Boer, ArchiXL, Netherlands - Monday 20, Afternoon

Description
Architectural knowledge is increasingly regarded as an organizational asset that should be managed. Consequently, the architecture community has been researching and developing tools and techniques to support architectural knowledge management. Ideally, such tools and techniques support management of formal, structured architectural knowledge (e.g., architectural decision graphs); documented, unstructured architectural knowledge (e.g., text) and even tacit architectural knowledge (e.g., community building). Semantic wikis are capable of delivering this type of support for managing architectural knowledge.
In this tutorial, the participants will learn how semantic wikis can be used to manage architectural knowledge. We will address the nature of architectural knowledge, and draw a distinction between tacit and explicit and between generic and organization-specific architectural knowledge. We will then look at what a semantic wiki is, and what its main differences and advantages are as compared to a regular wikis. This is followed by real life examples of different forms of architectural knowledge in Semantic MediaWiki, including models, principles, design decisions and their interrelations. We discuss the underlying knowledge model, how it can be registered in the wiki, and what types of inference can and cannot be performed from within the wiki. We finish the tutorial with an investigation of how a semantic architecture wiki can be linked to other repositories, such as modelling environments and even other semantic architecture wikis, thereby providing an effective means of reusing existing architectural knowledge.

Presenter’s bio
Remco de Boer is a consultant at ArchiXL, a Dutch independent IT architecture consultancy. He obtained his PhD from the VU University Amsterdam with a dissertation on architectural knowledge management. He combines his work as a practicing architect with further research into practical applications of architectural knowledge management methods and tools. His current work includes the application of semantic wikis to gather, record and disseminate architectural knowledge, with a particular interest in the reuse of generic reference architecture knowledge in organization-specific contexts.


- Top -



Tutorial T3: Software Architecture for the Business Analyst

Philippe Kruchten, UBC, Canada - Wednesday 22, Morning

Description
What would a business analyst need to know about software architecture? In this tutorial we will present the key concepts behind software architecture: the motivations, the practices, the tools, etc. and we will explore how architecture both enables and constrains the work of the business analyst.
For non-trivial, large-scale, long-lived software-intensive products, requirement management and architectural design evolve in parallel and support each other. Traditionally handled by different individuals and teams, they use language and concepts that seem totally foreign to each other, though we’ve come to realize now that they share a lot of traits. Both deal with making delicate choices in a risky and uncertain environment. Both exploit tacit knowledge of the organization, and rely on experience more than on precise recipes. Both drive the planning and implementation of the system. Like two different cultures, they are based on slightly different values, beliefs and mental models.
This course is primarily intended for business analysts, product managers, product owners, business or enterprise architects, UX designers, Information architects, IT managers, Procurement officers
Attendees will understanding the role of software architecture in the software development process; understand the difference between the various type of architectural activities; understand what input software or solution architects need to perform their work; understand the architectural decision process, the difference between value and cost, and how this affect planning; get a better sense of technical debt and its root causes.

Presenter’s bio
Philippe Kruchten is the founder and principal of Kruchten Engineering Services Ltd, in Vancouver, Canada. He is also a professor of software engineering at the University of British Columbia, where he holds an NSERC chair in Design Engineering. He’s had a 30+ year career in industry, where he worked mostly in with large software-intensive systems design, in the domains of telecommunication, defense, aerospace and transportation. Some of his experience is embodied in the Rational Unified Process (RUP) whose development he directed from 1995 till 2003, when Rational Software was bought by IBM. RUP includes an architectural design method, known as “RUP 4+1 views”. His current research interests still reside mostly with software architecture, and in particular architectural decisions and the decision process, as well as software engineering processes, in particular the application of agile processes in large and globally distributed teams.
Dr. Kruchten is a senior member of IEEE CS, member of ACM and INCOSE, the co-founder of Agile Vancouver, and a Professional Engineer in British Columbia.
He has a diploma in mechanical engineering from Ecole Centrale de Lyon, and a doctorate degree in informatics from Ecole Nationale Supérieure des Télécommunications in Paris. He is an IEEE Certified Software Development Professional (CSDP).


- Top -



Tutorial T4: Information Systems Architecture: Stakeholders, Viewpoints and Perspectives

Eoin Woods, Artechra, UK - Wednesday 22, Afternoon

Description
One of the difficulties in designing large software systems is the number of people who need to be satisfied with the result, from executive managers at one end, to IT operations specialists at the other, with end users, lawyers, software developers, technology experts and many others in between. Like most complex systems, a software system is also a multi-dimensional creation with many concerns to consider including its runtime functional components, how it is deployed into production, its information structure, how it is secured, whether it can scale to large workloads, whether it can be distributed geographically and so on.
One of the ways that software architects have tackled these complexities is to break the problem down so that each underlying structure can be considered separately, as a “view” of the system, which will be of interest to particular people. This approach has become known generally as the “viewpoints and views” approach to designing and capturing software architecture. A number of sets of viewpoints have been developed to guide architects through the process of designing and describing the different structures of their systems; a viewpoint being a guide to the creation of a particular type of view.
The limitation of most existing viewpoint sets is that they don’t really provide guidance on how to design the system so that it meets its critical non-functional requirements (its “quality properties”). This limitation led the presenter and his co-author to extend the approach with a complimentary concept, called “perspectives”, which are guides to help an architect with the process of designing systems to meet their quality properties.
This tutorial will provide a practical guide to applying viewpoints and perspectives to the problem of large scale information system design, using the set viewpoints and perspectives from the (forthcoming) 2nd edition of the book “Software Systems Architecture” by Eoin Woods and Nick Rozanski, due in late 2011. They are an extension and refinement of the set presented in the first edition of the book from 2005.

Presenter’s bio
Eoin Woods has been working in the software engineering field since 1990 for companies including Bull, Sybase, BGI and UBS Investment Bank, in applied research, server product development, consultancy and large-scale information systems implementation roles. Today, Eoin is a lead architect for one of the equity business lines at a major European investment bank.
Eoin main professional interests are software architecture, distributed systems, IT security and data management. He has published a number of technical papers in these areas and regularly presents sessions at industry conferences. He is co-author of the book “Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives”, published by Addison Wesley (2005).

- Top -



Tutorial T5: Strategic Management of Technical Debt

Nanette Brown, Robert Nord, Ipek Ozkaya, SEI, USA - Friday 24, Morning

Description
The technical debt metaphor acknowledges that development teams sometimes accept compromises in a system in one dimension (for example, modularity) to meet an urgent demand in some other dimension (for example, a deadline), and that such compromises incur a “debt” . If not properly managed the interest on this debt may continue to accrue, severely hampering system stability and quality and impacting the team’s ability to deliver enhancements at a pace that satisfies business needs.
Although unmanaged debt can have disastrous results, strategically managed debt can help businesses and organizations take advantage of time-sensitive opportunities, fulfill market needs and acquire stakeholder feedback. Because architecture has such leverage within the overall development life cycle, strategic management of architectural debt is of primary importance.
During this session, we will discuss the technical debt metaphor and learn about techniques for measuring and communicating technical debt. We will also play the Hard Choices game, an engaging technique for communicating the trade-offs of technical debt management to fellow colleagues and managers. In your quest to release a quality product, you must decide in the face of uncertainty whether to take shortcuts and incur penalties, or to traverse more of the board to potentially earn more value. At the end of the game, we‘ll compare strategies and share practices to help make these choices. We will conclude by raising awareness of efforts in the research community to move beyond the metaphor to provide software engineers a foundation for managing trade-offs based on models of their economic impacts.

Presenter’s bio
Nanette Brown is a Visiting Scientist with the Software Engineering Institute’s Research, Technology and System Solutions Program and is a Principal Consultant with NoteWell Consulting. She is currently engaged in an SEI Research Project on “Communicating the Value of Architecting within Agile Development” as well as other activities focusing on architecture within an Agile context. Previously, Nanette worked at Pitney Bowes Inc., most recently as Director of Architecture and Quality Management, where she was responsible for design and implementation of a customized software development life cycle that blended RUP and Agile practices.
Robert L. Nord is a senior member of the technical staff in the Research, Technology, and System Solutions Program at the Software Engineering Institute (SEI). He is engaged in activities focusing on agile architecting and works to develop and communicate effective methods and practices for software architecture. He is co-author of the practitioner oriented books, Applied Software Architecture and Documenting Software Architectures: Views and Beyond, published by Addison-Wesley and lectures on architecture-centric approaches. Dr. Nord is the chair of the steering committee of the WICSA conference series, in addition to organizing events (tutorials, workshops, and sessions) at software engineering and architecture venues (e.g., ICSE, ECSA, SATURN, WICSA, and SPLC).

- Top -



Tutorial T6: Architecture Haiku: The Art of One-Page Architecture Descriptions

George Fairbanks, Rhino Research, USA - Friday 24, Afternoon

Description
You can’t say anything in one page --- or can you? An Architecture Haiku is a one-page, quick-to-build, über-terse design description. No project wants “shelfware” documentation, but many must communicate their design to others. Brevity is hard --- what would you say in one page? With no page limit, experts suggest documenting everything but the kitchen sink. The one-page limit forces you to convey the essence of your design using compact language and concepts.
Normally, when someone starts talking about architecture, they can go on forever --- it seems like almost anything can be considered architectural. Constraining the description to one page (an architecture haiku) forces people to make choices. Consequently, they have to be direct and use the most compact language possible. Another interesting thing is that it clearly isn’t BDUF (Big Design Up Front).
Most folks who are asked to write their architecture on one page have a hard time. The point of the tutorial is to demonstrate that it is hard --- hence asking the participants to do it themselves --- but also go give a whirlwind tour of the essential ingredients of an architecture description. E.g., modules vs. components, viewtypes (module, runtime, allocation), quality attributes, tradeoffs, drivers, architecture patterns (map-reduce, client-server, n-tier, …). These are elements that aren’t directly expressible in programming languages (i.e., bigger than classes), so most developers won’t have a crisp idea about them.
This tutorial's direct objectives are to teach the participants how to tersely describe their architecture. This is desirable because few developers want to spend much time on architecture descriptions and one-page descriptions cannot take too long. The indirect objectives are to teach the canonical basics of software architecture including its terminology and standard abstractions. This normally dry subject is made interesting and relevant through the artificial one-page limit. Just as design patterns enabled compact, efficient communication about object- and class-level designs, software architecture concepts and terminology enables efficient communication about larger design ideas.
The tutorial is organized as follows: Participants will be exposed to a brief tour of software architecture concepts, led through the process of writing an Architecture Haiku, then work in small teams to write their own.

Presenter’s bio
George Fairbanks is the author of the book Just Enough Software Architecture: A Risk-Driven Approach. He holds a Ph.D. in Software Engineering from Carnegie Mellon University, advised by David Garlan and Bill Scherlis. His dissertation introduced design fragments, a new way to specify and assure the correct use of frameworks through static analysis. He has publications on frameworks and software architecture in selective academic conferences, including OOPSLA and ICSE. He has written production code for telephone switches, plugins for the Eclipse IDE, Android phone applications, and everything for his own web dot-com startup. He maintains a network of Linux servers in his spare time.

- Top -