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.
Meetings
Meetings are nominally every other week on Thursdays (10am EST). To join or sit in our meetings contact Jim Conallen for conference number information.
Architecture Management Meetings
OSLC AM Specification
The OSLC AM 2.0 specification will be the first finalized release from this work group. While the team did work on a 1.0 specification draft the timing of it was such that its release and ratification overlapped introduction of the OSLC Core workgroup. The decision was made to adapt the AM 1.0 work to make it compatible with Core 2.0. It was also decided to change the version number of the initial release of our spec to 2.0 making it consistent with the other specifications, and avoiding confusion over compatbility with the core.
OSLC AM 2.0 Specification (Finalized)
This workgroup made the decision to skip over finalization of a 1.0 style specification, and instead start with an OSLC Core 2.0 compliant specification, and hence start the version numbering with 2.0 to be consistent with the other OSLC specifications. The original draft of the OSLC AM 1.0 specification can be found here.
OSLC AM 3.0 Specification (Under Development)
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.
Some thoughts on Architecture Management and the semantic web.
This section of the wiki points to working collaborative documents that the team is using to work on. They do not consistute the specificaiton itself, but rather are working documents and if appropriate will be moved or transcribed to specification documents when ready.
Mailing Lists
OSLC Community
AM Workgroup
