|
...all of his or her financial information, it is often necessary to integrate hundreds of legacy systems dealing with various financial instruments, dozens of databases storing account information, and myriad rules and constraints. The challenge for the IT architect is to organize and analyze initial descriptions of customer needs as well as the existing IT environment, and to design an appropriate solution. This activity often involves progressively formalizing information and building up architectural models. The resulting models and design rationale must then be incorporated into number of overlapping work product documents for a variety of stakeholders, and these documents must be kept up to date and consistent as the system evolves.
IT architecture
To better understand this challenge, we consider IT architecture in greater detail. Many definitions of IT architecture exist (see, for example, Reference 1), but most agree that an architecture describes the structures of an IT system--both hardware and software--and their relationships to one another. It defines components that need to be bought, built, or reused, focusing on their externally visible properties. It defines the operational infrastructure (e.g., servers, network connections, etc.) on which these components will be deployed, and it ensures that the system will meet its functional and nonfunctional requirements (to be defined in the following). IT architecture also provides a high-level breakdown of the necessary development work and documents key decisions and their underlying rationale.
There are several methods and languages employed for describing architectures, such as IEEE 1471, (2) the Rational Unified Process* (RUP*) "4+1" view of architecture,(3) and the Unified Modeling Language ** (UML ** (4)). In the IBM Global Services organization (IGS), an IT architecture is documented in a number of work products, often using the Architectural Description Standard (ADS (5)) for terminology and notation, all of which is defined by Global Services Method (GS Method). Regardless of the methods followed, architectures are typically implicitly connected sets of models, usually documented with combinations of diagramming, spreadsheet, and word-processing tools.
There are a number of GS Method work products that are often among the work products that an IT architect is responsible for producing. The system context work product shows the IT system solution as a black box that exchanges information with specified external actors--human users and other IT systems. This documents the scope of the solution. The architecture overview diagram illustrates key elements of a solution, such as actors, locations, components, servers, network connections, and subsystems. This work product draws elements from across the breadth of an architecture, for purposes of communicating key concepts to various external stakeholders and sponsors. The use case model elaborates on the information exchange between the IT system solution and the external actors. This work product describes functional requirements of the system, and is often annotated with nonfunctional requirements (i.e., requirements that pertain to system qualities or constraints, such as performance, availability, security, and standards compliance).
The nonfunctional requirement (NFR) work product collates nonfunctional requirements from throughout the architecture. The component model defines software components and, their responsibilities, interfaces, and static relationships such as dependencies, as well as the dynamics of the collaborations by which components interact to support use case scenarios. This work product documents the functional aspect of the solution. The operational model documents the infrastructure of the solution and the deployment of the application components onto that infrastructure at three levels: conceptual, specified, and physical. Finally, the architectural decision work product documents the architecturally significant decisions that were made across all aspects of the architecture, along with alternatives that were considered and the rationale for the choices that were made. This work product is critical for understanding a solution, for preserving its integrity as it undergoes maintenance and evolution, and for reusing parts of this solution in other designs.
Although GS Method defines many other work products, these are some of the key architectural ones. These work products illustrate the interconnected nature of an architecture, as there are many relationships among the elements described in each of these work products. In an ideal world, these work products consistently document different aspects of a single architecture and combine to produce a complete, coherent, and unambiguous picture of the system under design.
The balancing act
In the field, architects spend much of their time scavenging mounds of unstructured information for useful tidbits--in stark contrast with neat descriptions of well-structured work products. A path from the copious incomplete, inconsistent, and informal material gathered from meetings and existing documents to the well-structured specifications required for solution development is unclear.
Architects often start by gathering vision statements, sketches of requirements and system structures, descriptions of existing systems with which to integrate, and other informal documents. They add structure and rigor, sketching and fleshing out ideas as their understanding deepens. When they do formalize, it is often only to the extent that it helps clarify important ideas for themselves or their colleagues. Architects are constantly balancing opposing forces, thinking fluidly but within well-defined structures.
Architects need to grasp myriad details without losing sight of the larger picture. They need to respond rapidly to high-level changes and understand their impact throughout the architecture. In addition, they must interact with a steadily increasing set of stakeholders as disciplines such as enterprise architecture, service-oriented architecture and asset-based consulting business architecture mature. They must balance the specific needs of their solution against enterprise-level standards, including technical standards ensuring coexistence and interoperability.
Time-to-market pressures can cause architects to trade precision for expediency. They try to rapidly capture their thoughts (even if incomplete and ill-formed) and then clarify them and remove inconsistencies as time permits. They juggle ideas, sketch out approaches, weigh alternatives, articulate a vision to various stakeholders, and produce the work products, usually as deadlines loom. Among other things, the transformation of the unstructured material into a coherent set of work products is a huge information management challenge. Throughout the architectural process they analyze, consider issues and trade-offs, raise and address concerns, and make decisions. For all of this they rely upon their training, drawing on their experience, methods, interactions with colleagues, documented best practices, and whatever tools are available.
The tools of the trade
Despite a number of special-purpose modeling tools (such as Rational * Software Architect or the Telelogic System Architect **), IT architects often use the same tools to create an architecture that high-school students use to complete a homework assignment, namely, standard office-presentation, spreadsheet, and word-processing tools. These tools are sometimes tailored to produce one or more of the output work products discussed earlier, but often without regard for the thought process that goes into composing them or the interrelationships among the artifacts. For example, architectural decisions are typically documented with a tool such as Microsoft Word, which has no explicit representation of the domain of architecture, while operational models are often documented with Microsoft Visio **. Not only do these tools lack semantics, but they are not oriented toward easily interacting with and consistently maintaining a large network of related and only partially complete models.
Even when a special-purpose modeling tool is used for one aspect of an architecture, common office tools are still used for the other parts of the architecture, and similar deficiencies exist. As an example, when component models are created with Rational Software Architect, interrelationships with operational models made with Visio or architectural decisions described in Word documents are not possible.
Without a tool that understands the many facets of architecture and their interrelationships, developing an architecture is tedious and prone to lapses that ultimately result in failures of the designed system to meet its requirements. Maintaining the architecture and continuing its evolution is even more daunting. In practice, many architectural documents quickly go out of date as the system evolves, creating difficulties for those charged with maintaining or enhancing the system.
Furthermore, while developing an architecture is a journey from an unclear understanding of unstructured information to a well-structured specification, the tools typically employed do not support this transition. Some tools are well-suited for unstructured information--word processing tools, semantics-free drawing programs, or white boards, for example. Other tools are well-suited for more structured information--UML diagramming tools or formal requirements management tools, for example. However, none of these support the transformation from unstructured to structured information that is inherent in the task of developing an architecture.
A tool facilitating the practice of the art of IT architecture
Our goal was to design a tool that supports the realities of practice, while supporting the formalities of a given architectural method. To that end, we formed a team of researchers and IT architects and analyzed the working methods and thought processes of the architects. Based on this analysis, we incrementally built a tool that attempts to match not only the formalisms of the practitioners' methods, but also the realities of their creative process and working styles. We wanted a tool that would let architects balance formalism and freedom, while helping them transform unstructured information into sufficiently formal work products. The initial result of this work is the Architects' Workbench (AWB).
After a brief overview of AWB from a user's perspective, we discuss in more detail some of its key features and its underlying design rationale. Next, we discuss the overall design and architecture of AWB, with particular emphasis on those design decisions that facilitated key developments. We then report on users' experience with AWB in field trials, where IT architects have found AWB to be highly effective in "live" use in major customer engagements. Finally, we conclude with a discussion of related efforts and future directions for AWB.
Without loss of generality, examples and method-specific discussions in the remainder of the paper will be based on GS Method and ADS. Nonetheless, these discussions apply equally to other methods and metamodels. In fact, as will be described later in the paper, the metamodel- and method-related parts of AWB have been factored out as "pluggable components," and AWB can be (and has been) used as a workbench based on any of a number of different methods and metamodels.
A BRIEF TOUR OF AWB
AWB is an Eclipse ** (6) -based tool, providing several views and editors tailored to the "balancing act" described previously. Figure 1 shows the AWB user interface (UI) configured for system context work--that is, sketching the boundaries of the system and its relationship to associated systems and people. In this example, the Music Web System is being developed. The project view is on the left side of the UI. The Outline pane of the project view consists of a textual hierarchy that shows the model elements important for system context work, starting with the Music Web System. The Reminders pane shows model elements requiring...
NOTE: All illustrations and photos
have been removed from this article.
More articles from IBM Systems Journal
Model driven development for business performance management., July 01, 2006
UML 2: a model-driven development tool., July 01, 2006
Feature-based survey of model transformation approaches., July 01, 2006
Using logical data models for understanding and transforming legacy bu..., July 01, 2006
A measurement framework for evaluating model-based test generation too..., July 01, 2006
Looking for additional articles?
Search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication
name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company
analysis or best practices in managing your organization,
Goliath can help you meet your business needs.
Our extensive business information databases empower business
professionals with both the breadth and depth of credible,
authoritative information they need to support their business
goals. Whether it be strategic planning, sales prospecting,
company research or defining management best practices -
Goliath is your leading source for accurate information.
|
