SE News

In this unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects — including Neal Ford, Michael Nygard, and Bill de hOra — offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from years of experience. You’ll learn what top software architects think is important, and how they approach their projects.

To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project. If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.

Richard Monson-Haefel

http://oreilly.com/catalog/9780596522704

Ward Cunningham coined the metaphor of technical debt in 1992. “Shipping first-time code is like going into debt,” he said. “A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid.”

For large software projects, using debt is often a wise financial strategy. But incurring debt is always a risk, especially if it is high-interest debt and you’re not paying close attention to the cost. The same is true of technical debt, and it applies not only to code but also to architectural design and even to requirements analysis.

What is your project’s analysis debt load? What’s the difference between good and bad analysis debt? What are causes and remedies for such debt? Mary Gorman and Ellen Gottesdiener explore the concept of analysis debt and consider strategies for prudent investing.

Mary Gorman/Ellen Gottesdiener

http://www.stickyminds.com/s.asp?F=S15549_ART_2

Systems engineers often focus on the system currently under development, without much concern for the larger enterprise it supports. This article explores the connection points between the enterprise architecture and the system architecture, and discusses how the enterprise architecture both provides input to and constrains system development. Its goal is to help systems engineers gain a deeper understanding of how their efforts on projects that create or modify systems are both constrained by, and can modify, the architecture of the enterprise those systems support. In today’s business-driven enterprise, there is a direct relationship between the enterprise’s business capability and the functionality implemented on projects.

Dave Brown
Peter Bahrs

http://www.ibm.com/developerworks/rational/library/edge/09/jun09/enterprisearchitecture/index.html

The advancement of ubiquitous computing technologies, such as wireless networks and mobile devices, has greatly increased the availability of digital information and services in our daily lives and changed how we access and use them. Another technology that extends digital resources to the real world is the Internet of Things, which connects such resources with everyday objects by augmenting the latter with RFID or Near Field Communication (NFC) tags. This way, real-world objects get digital identities and can then be integrated into a network and associated with digital information or services. These objects can facilitate access to digital resources and support interaction with them - for example, through mobile devices that feature technologies for discovering, capturing, and using information from tagged objects.

Gregor Broll
Massimo Paolucci
Matthias Wagner
Enrico Rukzio
Albrecht Schmidt
Heinrich Hußmann

http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/1109/W_IC_Perci.pdf

In turbulent times, budget pressures increase and IT spending is scrutinized. We will describe a technique that Microsoft architects around the world use every day to ensure that IT projects have both a clear alignment with the strategic goals of the organization and a strong demonstrable impact. This is used to prioritize the project portfolio to maximize return on investment (ROI) and determine the projects that should receive budget and resource allocation.

Methods include Microsoft Services Business Architecture (MSBA) to identify what to change and the Benefits Dependency Network (BDN) to understand fully whythe changes must be made. This leads to a clear alignment withhow the projects will make those changes. By using these methods, we identify the people, processes, and technology that are to be changed and provide clear alignment with organizational goals so as to achieve both financial and nonfinancial benefits. Many organizations have subsequently incorporated these methods into their project management and portfolio-prioritization processes.

Martin Sykes
Brad Clayton

http://msdn.microsoft.com/en-us/architecture/aa902621.aspx

We started talking with the idea we should minimise ambiguity in our students’ minds about when and where they should use the ArchiMate box symbols to represent those architecture entities that are named in an architecture method (be it TOGAF or any other method).

This paper is the fourth in a series, edited from our conversation over several months, in which we explore the possibilities of using the ArchiMate language with an architecture method, and in particular with TOGAF. The series consists of the following papers:

• ArchiMate is not just a set of box and line symbols, it has a meta model and philosophy that may or may not match those of any given architecture method. The first paper provides a kind of method maturity model, which you can use to assess the suitability of your architecture method for use with the ArchiMate language.
• The second paper applies the model in the first paper to an example architecture method. It shows that TOGAF supports some ArchiMate distinctions more clearly than others. And that the two approaches feature different kinds of “realisation” transformation.
• The third paper shows that ArchiMate draws a structure-behaviour dividing line in a different place from the ISEB reference model and from the TOGAF meta model. It also explores how people use the term Function loosely and generically where the terms Service, Process, Interface and Component could be used more precisely.
• This paper: Using ArchiMate box shapes to draw diagrams is trivial; it does not mean you are using your chosen architecture method in accord with ArchiMate’s meta model and philosophy. This fourth paper provides the kind of careful entity-by-entity analysis that is needed if you want to use ArchiMate to support your chosen architecture method. Again, TOGAF is the chosen example.

In this paper, we investigate the mapping between ArchiMate’s concepts and TOGAF’s implicit and explicit meta models along the following lines. First, we ask whether TOGAF’s meta model aligns with ArchiMate’s. We investigate the generic, meta meta level of both and go deeper into the business architecture, data architecture, applications architecture and technology architecture as prescribed by TOGAF, to see whether we can express the required TOGAF notions in ArchiMate. We conclude with recommendations to the designers of both ArchiMate and TOGAF.

Graham Berrisford and Marc Lankhorst

http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf-2.html

For the IT profession to truly excel and flourish, IT professionals must understand how to present information in both technical and nontechnical terms. Editorial board member Wes Chou describes how to move beyond “geek think” and truly excel at serving the overall organization, from users to customers.

Wes Chou

http://www2.computer.org/plugins/dl/pdf/mags/it/2009/03/mit2009030004.pdf

Specialist certification is still a somewhat vague concept in the IT world. Some see it as proof of participation in a training program, whereas others believe it demonstrates that an IT professional has certain proven qualities and experiences. The value assigned to any given certificate can vary widely depending on the granting organization’s credentials, and the reasons people seek certification can be just as varied. Many workers obtain certificates for self-development or career-improvement reasons, whereas others are obliged by their employers to qualify for certification to work on certain projects. On both ends of the employer–employee spectrum, substantial ambiguity remains in the case for and against certification. Is it just marketing hype, or does certification fit with the constantly evolving professionalization and industrialization of IT?

Gerard Coes
Karel Schotanus

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_IT_CertificationWhoDares.pdf

The Army Strategic Software Improvement Program (ASSIP) is a multiyear effort targeted at improving the way in which the Army acquires software-intensive systems. The ASSIP has funded a number of programs, in conjunction with the Carnegie Mellon Software Engineering Institute (SEI), to conduct software architecture evaluations using the Architecture Tradeoff Analysis Method (ATAM). Additionally, in cases when a system’s architecture did not exist or was not ready to evaluate, the ASSIP sponsored Quality Attribute Workshops (QAWs). During the period of this effort, several other programs funded their own ATAM evaluations and QAWs. The goal of this study was to determine the benefits associated with using the ATAM and QAW.

This special report describes the results of a study of the impact that the ATAM evaluations and QAWs had on Army programs. All 12 programs that used the ATAM and/or QAW responded to a questionnaire whose objective was to determine the impact of the experience in terms of the quality of the system, the practices of the involved program office, stakeholders, and suppliers, and the overall value of the engagement.

The data gathered confirms that the use of ATAM-based architecture evaluations and QAWs are generally beneficial to system acquisitions and suggests that maximal benefit is achievable only if architecture-centric practices are built into the acquisition process.

Robert L. Nord, John Bergey, Stephen Blanchette, Jr., and Mark Klein

http://www.sei.cmu.edu/publications/documents/09.reports/09sr007.html

Coverity Inc., the software integrity company, today announced the publication of application architecture data from over 2,500 popular open source software projects at http://www.scan.coverity.com. As an outgrowth of its contract with the U.S. Department of Homeland Security (DHS), Coverity collected this data via the Scan site using the Coverity Architecture Analyzer product. This new, publicly accessible resource includes application architecture files and generated diagrams that will benefit developers planning to incorporate open source packages in their applications, as well as developers that want to learn the architectures of successful projects to improve the structure of their own applications.

http://www.testdriven.com/modules/news/article.php?storyid=773

The Internet isn’t really for us. We’re here at the beginning, stumbling around, just figuring out what it’s good for and how to use it. The Internet is for those born into it, those who have woven it into their lives from the beginning. The Internet is the greatest generation gap since rock and roll, and only our children can hope to understand it.

As architects of the Internet, we have a special responsibility to our children to build an Internet that future generations will be proud of, one that encompasses basic human rights and values. We do this when we build systems that offer universal access support, open interfaces, and net neutrality, bypass censorship, limit surveillance, fight repression, give people control over their digital presence and digital personas, and foster individual liberty and privacy—especially privacy.

Bruce Schneier

http://www.schneier.com/essay-253.html

The book “Zen of SOA” by Tom Termini introduces an original view to the challenging world of SOA. He refers to the Zen philosophy as a “therapeutic device” helping SOA practitioners to get rid of prejudices and opinions in order to apply a clear mind-set based on real-life experiences and the application of technology knowledge. Each chapter of the book is prefaced by Zen Truism that the author suggests to “revisit, reflect on it longer, and see if you are able to establish a truth from the narrative, as well as from your own experiences.” In fact, the book is about a SOA Blueprint outlining a methodology for building a successful SOA strategy. The target audience is C-level Executives, IT Managers and Enterprise Architects undertaking or intending to undertake adoption of SOA throughout their organizations. I strongly recommend the book to all SOA practitioners involved in implementation of SOA.

Alex Roussekov

http://books.slashdot.org/books/09/01/16/1437231.shtml

The field of architecture in the digital world uses a plethora of terms to refer to different kinds of architects, and recognizes a confusing variety of competences that these architects are required to have. Different service providers use different terms for similar architects and even if they use the same term, they may mean something different. This makes it hard for customers to know what competences an architect can be expected to have.

This book combines competence profiles of the NGI Platform for IT Professionals, The Open Group Architecture Framework (TOGAF), as well as a number of Dutch IT service providers in a comprehensive framework. Using this framework, the book shows that notwithstanding a large variety in terminology, there is convergence towards a common set of competence pro. les. In other words, when looking beyond terminological differences by using the framework, one sees that organizations recognize similar types of architects, and that similar architects in different organizations have similar competence profiles. The framework presented in this book thus provides an instrument to position architecture services as offered by IT service providers and as used by their customers.

The framework and the competence profiles presented in this book are the main results of special interest group ‘Professionalisation’ of the Netherlands Architecture Forum for the Digital World (NAF). Members of this group, as well as students of the universities of Twente and Nijmegen have contributed to the research on which this book is based.

Roel Wieringa, Pascal van Eck, Claudia Steghuis, and Erik Proper

http://www.sdu.nl/catalogus/9789012580878

Architecture is omnipresent and natural. Every child applies it, and it will keep doing so as a grown-up. Both Salvador Dali and Vincent van Gogh were guided by functional and constructional principles. Examples of functional principles for them were to shock or to please. Examples of constructional principles were to use oil color or water color. Design principles are the operational shape of architecture. Conceptually, it is normative restriction of design freedom. The rationale for architecture is simply that our design freedom is always too large. The question then is: how are you going to use this freedom? Through the whole history of mankind, people have answered the question in much the same way; they use design freedom for expressing their individual or collective vision.

In this book, architecture is introduced and elaborated for the area of business and ICT (information and communication technology). Fortunately, there is a lot of talk about architecture in this area. Unfortunately, the original notion of architecture has degenerated into something like a blueprint or a global design. This degeneration process must be stopped, the sooner the better. Certainly, there is also a need for global understanding of complex systems, for abstraction from irrelevant details. However, for this goal we have the notion of system ontology. It provides the understanding of a system in a coherent, consistent, complete and concise way, fully abstracted from all implementation aspects.

The aim of the book is to make the notion of architecture crisp and clear and to show how one can bene. t from it in (re) designing and (re) engineering systems in the area of business and ICT, ranging from infrastructural networks to enterprises. Having a corporate strategy is good but having the means to make this strategy operational is better. That is what architecture can achieve: to build strategy into design.

This book is the final report of the xAF (Extensible Architecture Frameworks) working group of the NAF (Netherlands Architecture Forum).

Jan Dietz

http://www.sdu.nl/catalogus/9789012580861

De community heeft grote stappen gezet, maar de eisen aan de architectuur zijn misschien nog wel meer toegenomen. Businesscase, veranderingsmanagement, politieke besluitvorming. Maar laat je niet gek maken, je hoeft het niet allemaal alleen te doen.

http://www.informatie.nl/