The following papers have been authored by Peter Eeles.
|
Modeling and Sharing Architectural Decisions
August 2008
IBM DeveloperWorks
|
Architectural decisions capture precious knowledge that is worth sharing. Text templates and tools designed solely for documentation purposes fail to facilitate such knowledge exchange. In this series of articles, learn about a domain meta model specifically designed to capture and share architectural decisions, explore a reusable architectural decision model for SOA, and find out more about Architectural Decision Knowledge Wiki, a Web 2.0 collaboration platform. This first article outlines why and how architects should consciously identify, make, and enforce architectural decisions. Co-authored with Olaf Zimmermann and Nelly Schuster.
|
|
The Rise of the Development Environment Architect
April 2008
The Rational Edge
|
IT is a critical element for many organizations, whether their IT supports internal systems or the creation of software products that represent their core business. In both cases, software is an essential element of their success, and these organizations naturally seek an environment for developing high-quality software in a timely, cost-efficient manner. Our experience has led the Rational team to define a role within the software development lifecycle called the "development environment architect." In October 2007, one hundred of Rational's most experienced development environment architects from across the globe gathered together in the first conference dedicated to this role to share their experiences. This paper is a result of that conference and the discussions that took place.
|
|
Understanding Architectural Assets
September 2007
The Rational Edge
|
This article discusses the various kinds of reusable assets available to the software architect, explains their characteristics and interrelationships, and offers tips on how best to make use of them.
|
|
The Benefits of Software Architecting
May 2006
The Rational Edge
|
This paper discusses the benefits that a business and an IT organization can derive from a sound software architecture. In general terms, software architecting is a key factor in reducing cost, improving quality, timely delivery against schedule, and delivery against requirements. This paper focuses on specific benefits that contribute to meeting these objectives. It is also worth noting that, as an architect, we sometimes have to justify our existence. This paper provides some useful ammunition for treating architecting as a critical part of the software development process.
|
|
The Process of Software Architecting
April 2006
The Rational Edge
|
This paper considers the themes, or characteristics, that underly the process of software architecting.
|
|
Characteristics of a Software Architect
March 2006
The Rational Edge
|
This is the second article in a four-part series on software architecture. This paper considers the role that is responsible for the creation of the architecture -- the architect. The role of the architect is arguably the most challenging within any software development project. The architect is the technical lead on the project and, from a technical perspective, ultimately carries the responsibility for the success or failure of the project.
|
|
What is a Software Architecture?
February 2006
The Rational Edge
|
This introduction to the relatively new discipline of software architecture is the first of a four-part series on "architecting" in general. The paper begins by defining the discipline's key terms and goes on to explore what a well-designed architecture contributes to the environment in which it is deployed.
|
|
Realizing service-oriented solutions with the IBM Rational Software Development Platform
Volume 44, Number 4, 2005
IBM Systems Journal
|
Creating service-oriented architecture (SOA) solutions means rethinking the practices currently in use to build systems, reconsidering the skills in an organization, and redefining the ways in which team members collaborate. A service orientation contributes to the development of solutions that are assembled from disparate applications, and SOA is an architectural style that emphasizes loose coupling of independent service providers. This perspective on service orientation is known as service-oriented development of applications (SODA). SODA encompasses composition, adaptive process management, service-based interoperability and integration, discovery and description, and rapid application maintenance.
|
|
Modeling for Enterprise Initiatives with the IBM Rational Unified Process
July 2003
The Rational Edge
|
Out of the box, RUP focuses on the execution of a single project to develop a single software application, but it is highly suitable for developing more complex systems as well. In particular, this paper considers RUP as a process framework for typical enterprise initiatives such as enterprise architecting, enterprise application integration, packaged application integration, strategic reuse, systems engineering and outsourced development.
This paper is in 2 parts. Part 2 of the paper can be found at http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/oct03/t_modeling_pe_me.pdf
|
|
An Introduction to the Rational Unified Process
September 2002
The Rattle (internal Rational magazine)
|
This paper is actually one of the chapters from Building J2EE Applications with the Rational Unified Process. Possibly the most concise summary of RUP you'll find!
|
|
An Introduction to the Java 2 Platform, Enterprise Edition
September 2002
The Rational Edge
|
This paper is also a chapter from Building J2EE Applications with the Rational Unified Process. Possibly the most concise summary of J2EE you'll find!
|
|
Capturing Architectural Requirements
November 2001
The Rational Edge
|
Capturing requirements is difficult. Capturing architecturally significant requirements is particularly difficult. This paper discusses the root causes of this difficulty, and suggests a systematic approach to capturing architectural requirements to ensure that these elusive, and yet extremely important, system specifications are not overlooked.
|
|
Layering Strategies
October 2001
Rational Unified Process white paper
|
Layering is a decomposition technique that has been adopted in numerous software systems and espoused in many texts as well as the RUP. It is, however, often misunderstood and incorrectly applied. This paper clarifies what is meant by layering, and discusses the impact of applying different layering strategies
This paper is shipped with the Rational Unified Process. The link is to the version published in the Rational Edge.
|
|
Distributed Object Patterns
May 2000
Rational Architecture Workshop
|
The development of distributed systems brings with it a new set of problems that the technical community must address. The focus of this paper is a discussion of the distributed environment, and the role that patterns have to play in assisting the development of products targeted at such environments.
|