Notes by Brendan Foote
How to Build, Implement, and Use an Architecture Metamodel
Chris Armstrong, Armstrong Process Group, Inc.
Armstrong discussed the architecture-description standard UML model, showing how an architecture description expresses an architecture, fulfills the concerns of stakeholders, and more. He uses the difference between raw accounting data and the common views the way, say, a CFO would need to because of the way that an architecture is standardized by the RFC 42010 (that is, what subset of the entire UML model is particularly useful?). This leads to his refined viewpoint metamodel. His process group has added the “architecture scenario” to the metamodel, which he points out is not in conflict with the standard. This scenario is defined by a stakeholder, and it contextualizes an architectural concern. He goes on to show how stakeholders and concerns are also connected by architecture viewpoints, of which there are several types. Those types are defined differently depending on whether you talk to TOGAF, DoDAF, etc., but a modeling system should allow you to render your viewpoints in different ways for different consumers (e.g., a grid, diagram, catalog, or dashboard).
As the tutorial chair for SATURN 2013, I would like to share with you some of the exciting highlights from our tutorial program this year. You will want to make plans to stay all week. We start off the week with a series of very strong tutorials wrapping up the week Friday with tutorials from two of our featured conference speakers, Mary Poppendieck and Phillipe Kruchten.
Our selection of 10 tutorials covers the spectrum of conference topics including software design, backend integration/application hosting, methods and tools, and technical leadership. The tutorial program starts on Monday afternoon with an introduction to principles and patterns of RESTful web services (T1) and a practical guide to techniques and behaviors that will help you to successfully coach an architecture team (T2). Tuesday begins with an overview of a risk- and cost-driven architecture approach (T3) and a pattern-driven approach to architecture recovery and discovery (T4). Tuesday afternoon we continue with a tutorial on the key concepts of NoSQL databases from an architect’s perspective (T5) and a simple approach for developing software architecture diagrams (sketches) given by Simon Brown (T6).
Posted in SATURN Conference
Tagged agile release planning, documentation, Lean, SATURN 2013, SATURN Conference, SEI, software architecture, software design, software development, software engineering, Software Engineering Institute
In 2013, the Software Engineering Institute (SEI) Architecture Technology User Network (SATURN) software architecture onference will celebrate its 9th year. Each year SATURN attracts an international audience of practicing software architects, industry thought leaders, developers, technical managers, and researchers to share ideas, insights, and experience about effective architecture-centric practices for developing and maintaining software-intensive systems.
Posted in Architecture and Agile, Architecture-Centric Engineering, Architecture-Centric Practices, Conferences and Events, Quality Attribute Analysis, SATURN Conference, Service-Oriented Architecture
Tagged architecture certification, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, attribute-driven design, Carnegie Mellon, cloud computing, documentation, non-functional requirements, SATURN 2013, SATURN Conference, SATURN Network, SEI, SOA, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute, system architecture, system of systems, systems architecture, technical debt, testing, ULS systems, ultra-large-scale systems
Agility and Your Wetware: How to Get Uncomfortable with Agile and Jumpstart Your Creativity
Andy Hunt, Toolshed Technologies
Looking back at Agile Manifesto.
Really hard problems have nothing to do with hard science. Real hard problems is that it’s us writing, or managing the people who write, code. The problem is that it is us. If we’re problem, what can we do to fix it?
by Andy Hunt, Toolshed Technologies
Whether you are an aspiring software architect or an experienced practitioner, the SATURN 2012 Conference offers courses, presentations, tutorials, and talks tailored to your level of knowledge and experience.
Relative newcomers to architecture-centric engineering and development can take the introductory course in the SEI Software Architecture Curriculum, Software Architecture: Principles and Practices (SAPP) on Monday and Tuesday, May 7-8 at a discounted price. This popular course, offered each year at SATURN and taught this year by Rob Wojcik of the SEI, introduces participants to the essentials of software architecture. Also offered at SATURN this year is a half-day tutorial on Tuesday, May 8 by Peter Eeles of IBM Rational titled Software Architect 101. This tutorial (T1) provides attendees with a solid grounding in all aspects of software architecture and a framework on which they can build a deeper understanding of the role of the architect. Other Tuesday tutorials cover effective stakeholder collaboration (T2), integration of software architecture-centric methods into object-oriented analysis and design (T3), and architectural implications of cloud computing (T4).
Posted in Architecture and Agile, Architecture-Centric Engineering, Architecture-Centric Practices, Cloud Computing, SATURN Conference, Service-Oriented Architecture, Ultra-Large-Scale Systems
Tagged architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, cloud computing, documentation, EA, enterprise architecture, non-functional requirements, SATURN 2012, SATURN Conference, SEI, SOA, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute, technical debt, ULS systems, ultra-large-scale systems
The SATURN 2012 technical committee has put together a robust program of technical sessions, courses, tutorials, keynote presentations, and plenary talks that will allow practitioners at every level to walk away with knowledge that they can use at their organizations immediately.
Choose your path at the SATURN 2012 Conference on May 7-11, 2012 in St. Petersburg, Florida. Technical sessions will be divided into 8 tracks designed around aspects of software architecture from collaboration within an organization, to large-scale systems’ use of architecture-centric engineering. Architects at any level can delve deeper into the aspects of software architecture they choose. Personalize your SATURN 2012 experience by choosing from the 8 technical tracks: Continue reading
Posted in SATURN Conference
Tagged agile, architectural patterns, architecture certification, architecture evaluation, Architecture-Centric Engineering, documentation, enterprise architecture, Large-scale, SATURN 2012, SATURN Conference, software architecture
A new course from the SEI, Advanced Software Architecture Workshop, will be offered publicly for the first time at SATURN 2012 in St. Petersburg, Florida on May 7 and 8. Register now.
The course, taught by Felix H. Bachmann of the SEI, is targeted to
- software architects and software lead designers who want to practice what they learned in the SEI software architecture curriculum, and
- seasoned software architects who want to get ready for a project that requires major architecture improvements
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Conferences and Events, SATURN Conference
Tagged architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, documentation, non-functional requirements, SATURN 2012, SATURN Conference, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute
Software architecture—the conceptual glue that holds every phase of a project together for its many stakeholders—is widely recognized as a critical element in modern software development. Practitioners have increasingly discovered that close attention to a software system’s architecture pays valuable dividends. Without an architecture that is appropriate for the problem being solved, a project will stumble along or, most likely, fail. Even with a superb architecture, if that architecture is not well understood or well communicated the project is unlikely to succeed.
Documenting Software Architectures: Views and Beyond, 2nd Edition by Paul Clements and 8 other authors provides the most complete and current guidance, independent of language or notation, on how to capture an architecture in a commonly understandable form.
See this book review and interview with co-author Paulo Merson in the November 1 edition of InfoQ.
The SEI has long advocated software architecture documentation as a software engineering best practice. This type of documentation is not particularly revolutionary or different from standard practices in other engineering disciplines. For example, who would build a skyscraper without having an architect draw up plans first? The specific value of software architecture documentation, however, has never been established empirically. This blog post at the SEI blog by Rick Kazman describes a research project that the SEI is conducting to measure and understand the value of software architecture documentation on complex software-reliant systems.
In many professions, people use graphical models to represent what they are creating or studying. For example, chemists have 2D and 3D diagrams to model molecules; cartographers use various kinds of maps to represent different geographical aspects of a region. If you’re a software developer, you’ve seen diagrams that represent some facts about the software design. UML is a visual language commonly used to create such diagrams.