Selecting a Strategic Toolset
Posted February, 2014 in IBM DeveloperWorks
So, we've made our decision. We're going to deploy Acme Inc.'s configuration management tool since one of our flagship projects desperately needs to get its house in order with regards to version control. Although there are more comprehensive tools on the market, Acme Inc.'s offering is cheaper and is up to the job. We'll be on to the vendor in the morning to tell them the good news. Our work is done and we can rest easy. This scenario is typical of many organizations where tooling decisions are made based on the immediate tactical need. While the short-term need may indeed be addressed, such an approach to tool acquisition often leads to frustration as an organization, over time, builds up a catalogue of tools that overlap in capability, fail to integrate, place a huge burden on the IT department to maintain as new tool versions become available, and so on. The purpose of this paper is to highlight 5 themes that IBM Rational considers key considerations when selecting a strategic toolset and that tackles the challenges described above from the outset.
|Download PDF (0.61 MB)|
Define the Scope of Your Development Environment
Posted May, 2011 in IBM DeveloperWorks
A development environment contains everything required by a team to build and deploy software intensive systems (where software is an essential and indispensable element). Many organizations are looking to reduce time-to-market, reduce cost and improve quality and all of these business goals are directly influenced by the quality of the environment used to produce their software-intensive systems. Having a consistent and comprehensive definition of a development environment at hand will ensure that nothing is overlooked when we're planning an initiative to improve the current environment, defining requirements on the environment,architecting the environment, assessing the environment, ensuring an appropriate return-on-investment when changing the environment and so on. Fundamentally, a development environment definition, the subject of this paper, is a critical input to all of these tasks.
|Download PDF (0.30 MB)|
Modeling and Sharing Architectural Decisions
Posted August, 2008 in 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
Posted April, 2008 in 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.
|Download PDF (0.31 MB)|
Understanding Architectural Assets
Posted September, 2007 in 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.
|Download PDF (0.38 MB)|
The Benefits of Software Architecting
Posted May, 2006 in 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.
|Download PDF (0.14 MB)|
The Process of Software Architecting
Posted April, 2006 in The Rational Edge
This paper considers the themes, or characteristics, that underly the process of software architecting.
|Download PDF (0.17 MB)|
Characteristics of a Software Architect
Posted March, 2006 in 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.
|Download PDF (0.13 MB)|
What is a Software Architecture?
Posted February, 2006 in 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.
|Download PDF (0.20 MB)|
Realizing service-oriented solutions with the IBM Rational Software Development Platform
Posted October, 2005 in IBM Systems Journal, Volume 44, Number 4
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
Posted July, 2003 in 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
|Download PDF (0.68 MB)|
An Introduction to the Java 2 Platform, Enterprise Edition
Posted September, 2002 in 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!
|Download PDF (0.25 MB)|
An Introduction to the Rational Unified Process
Posted September, 2002 in 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!
|Download PDF (0.52 MB)|
Capturing Architectural Requirements
Posted November, 2001 in 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.
|Download PDF (0.12 MB)|
Posted October, 2001 in 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.
|Download PDF (0.35 MB)|
Distributed Object Patterns
Posted May, 2000 in 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.
|Download PDF (0.62 MB)|