SE News

Virtualization has a profound impact on IT environments, as it abstracts the physical characteristics of computing resources from users. Virtualization techniques are mainly used for enhancing capacity (using excess computer resources efficiently), compatibility (running legacy applications on modern platforms), and manageability (easy patch management and deployment). However, one must not confuse virtualization technologies - such as OS virtualization and application virtualization - with virtualization itself. In principle, virtualization can be applied to provide an abstraction layer that helps solve complex problems in software architecture.

In this article, we examine the impact of virtualization on software architecture to support desired attributes - such as high dynamic scalability, high availability, and geographic distribution - in modern composite applications, as well as the benefits of extending a virtualized environment to traditional applications.

Nishant Thorat

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

Too often in our work as architects and designers we focus on the task at hand, seldom reflecting on the past. We should really know better, how else do you improve? This article summarizes six learnings from 55 months as an architecture team lead at Skype. Some of them will be technical while some will focus on softer aspects of an architects work.

Andres Kutt

http://www.infoq.com/articles/learnings-five-years-skype-architect

With the latest statistics claiming that 15- 50% of projects are cancelled before they deliver anything, perhaps what we have always gotten is not what we have always wanted. Intentionality is a property of a decision. A decision that is the result of explicit examination of relevant factors is an intentional decision. It takes longer to make an intentional decision so many managers don’t make the effort. They go with the default, business as usual, and they get what they have always gotten.

John McGregor

http://www.jot.fm/issues/issue_2010_01/column1/index.html

Given the critical importance of architecture to software project success, it follows that the architecture cannot be effective unless it is effectively captured in documentation that allows the architecture’s stakeholders to understand and use the architecture in the way it was intended. That is, the documentation of the architecture inherits the criticality of the architecture itself. An architecture that cannot be understood (or, worse, is misunderstood) because of deficient documentation will fail to meet its goals as surely as a poorly chosen architecture.

Put succinctly, if your architecture is not well described, it doesn’t matter if it’s well designed.

Robert Nord,
Paul C. Clements.
David Emery,
Rich Hilliard.

http://www.sei.cmu.edu/library/abstracts/reports/09tn030.cfm

Many agile proponents give software architecture a bad rap: big design up front, massive documentation, the smell of waterfall, and so on. Architecture seems nonagile. Is agile architecture a paradox? An oxymoron? Two totally incompatible approaches? The real issues, past the rhetoric and posturing, suggest that the two cultures can sometimes coexist and support each other.

Pekka Abrahamsson,
Muhammad Ali Babar,
Philippe Kruchten.

http://www.computer.org/portal/web/csdl/abs/html/mags/so/2010/02/mso2010020016.htm

In these turbulent times, with increasingly constrained capital and diminished labor resources, organizations are focusing on deriving measurable business value from their IT investments. Forward-looking firms see this as an opportunity to transform their business models to better satisfy demands for new types of services and products. These strategic shapers expect IT to enable business transformation.

Elby M. Nash

http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2010/0110/rW_IT_ITandBusiness.pdf

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