Architecture Management

Introduction

Architecture Management (AM) is all about the evolution of the ideas and requirements driving the business needs and seeing them fulfilled in the applications and systems created by coordinated development teams. These activities include traditional planning, analysis, design and construction, and governance. However the emphasis is shifted to the driving business factors, and to the management of cross project and enterprise-level concerns. It also is concerned with how to do this in a constantly evolving environment. Architecture management strives to maintain the architectural integrity of solutions amid the constant churn of requirements, technology and business factors.

The tools of architecture management include those used in requirements management and change management and they introduce modeling as a first class artifact in the ALM story. Modeling addresses the inherent complexity of most software based systems today. Models are abstractions and simplifications of the things we want to understand or create. We use them for analysis and for communication of actionable information. They are seeing increasing use in automation as described by Model Driven Architecture (MDA) and Model Driven Development (MDD).

Architecture management as considered here encompasses Enterprise Architecture, Solution Architecture and Technical Architecture. Enterprise architecture tends to have a broader and larger scope than technical and even solution architecture. However regardless of the scope the fundamental needs for all architecture management is ensuring that the business needs are driving the evolution of the solutions.

The goal of this effort is to define a common set of resources, formats and RESTful services for use in modeling and ALM tools. This effort is not an attempt to define new modeling languages or storage formats, but rather enable the easy integration of existing ones through the use of simple services to link to and access them. This effort does include the definition of common meta-information associated with the models, and other AM artifacts, such that they can be intelligently leveraged by other efforts like Requirements Management (RM) and Change Management (CM).

Approach

The first step in this effort is in establishing the team. Ideally the team will contain those with a special interest is in architecture management, and also with a concern for the overall ALM process. Having representatives from both tool vendors and practitioners is vital to gaining an overall understanding of the concerns and issues in this space.

The team will first document the key artifacts and resources that are used in AM, and point out their uses and connections to other resources both within and without of the AM space. A minimal set of key scenarios, with clear business goals, will be chosen to guide the process. By business goals we mean those scenarios that provide value to those stakeholders outside of the AM space.

With the key scenarios understood and articulated, specifications will be drafted regarding the important meta-information about these artifacts and the services that make them accessible. The specifications exist not to dictate how to carry out AM activities, but rather how someone from the outside can make use of those resources and activities.

As with most AM activities these specifications will be developed iteratively with the emphasis set on the key scenarios. Once these scenarios have been satisfied by specification and proof of implementation, more scenarios will be considered. In keeping with the overall philosophy of the OSLC, we'll target deliverables like specifications and updates to happen about every 4 to 6 months. Team meetings will happen on a bi-weekly basis and are open to all.

Working Documents

OSLC AM 1.0 Specification

Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119. Domain name examples use RFC2606.

Terminology

Resource - An artifact used in the ALM space. A resource is directly addressable with an absolute URI.

Architecture Management Resource (AMR) - Directly addressable resources of some domain/notation (i.e. UML, BMPN, ER) that represent an abstraction of some behavior or construct of a system under development. An AMR maintains its identity after refactoring. In the semantic web, an AMR might correspond to a graph that is an instance of some vocabulary or micro-theory.

Link - A logical relationship from one resource to another resource. A link this the OSLC AM context is uni-directional. The subject (source) of a link represents the resource that 'knows about' and is referencing another resource (subject). The type of relationship is given by a predicate URI (link type). In semantic web termonology, a link might correspond to an RDF statement linking a particular subject with a specific object using a predicate. The predicate could be defined by property in an RDF schema.

Link Type (LT) - A URI that represents the predicate in an RDF triple which clarifies the type of link between the subject and object resources. Link Type URIs may be defined locally, within the OSLC, or externaly (i.e. Dublin Core terms). Link types could be defined in RDF Schemas.

Resource Collection - An ordered or unordered set of resources, typically generated as the result of performing a query or search.

Service Provider - An implementation of the OSLC Architecture Management specifications as a server. OSLC AM clients consume these service.

Service Description Resource - an informational resource describing the capabilities and contextual configuration needed for a set of Architecture Management-specific services.

Service Description Document - the representation of a Architecture Management Services Resource.

Documents

Milestones

Discussions

An important part of this specification is surfacing Architecture Management (AM) resources with perma links that other non-OSLC AM resources can reference. Conversely it is important that AM resources be able to reference (link) to other resources in a flexible and extensible way. It has been identified early on in discussions of this specification that it it is impractical to comprehensively identify and define all the possible and desireable 'link types' that will be in use. But rather it is goal of this specification to support any locally or globally defined link type using more open-world assumptions. A more detailed discussion of how links are managed in this specification is given here.

Status

Team home created, additional participation is still being requested, especially practioners.

Collecting an discussing scenarios to drive specification development.

Meetings

Interesting Links/References

An introduction to architecture management by Gary Cernosek of IBM. This high level overview of Architecture Management expresses how Rational views this topic.

The Object Management Group's Model Driven Architecture (MDA)

An introduction to Model Driven Architecture An excellent introduction by Alan Brown.

The wikipedia entries for

• Enterprise Architecture Management
• Enterprise Architecture
• Solution Architecture

Participants

JimConallen (lead)
RenRenganathan
Simon Helsen
Ian Green
Jin Li
Marnie Andrews
AndyBerner
DerryDavis VishyRamaswamy

Feedback

Mailing Lists

OSLC Community
AM Workgroup