WICSA2008 WS2 Knowledge

From WICSA Conference Wiki

Jump to: navigation, search

Contents

WS2 - Knowledge

Session Chairs: Jeff Tyree and Patricia Lago

Tuesday 19th February - 13:30 - 17:30

Contributions

Attendees

Do you plan to join us? add your name to the following list!

  • [[User:<wiki id>|<add your name here>]]

Session Overview

Software architecting is a highly knowledge-intensive process demanding and producing a large and rich amount of information. To remain competitive, companies and organizations working in the IT sector must be able to manage this knowledge portfolio and effectively exploit and reuse it. In the era of Web 2.0, knowledge grids, social networking, global development and semantic web, this working session addresses the problem of building a knowledge community in the field of software architecture. To this end, we aim at exploring the wishes of academics and industrial organizations, on the one hand, and their boundaries on the other.

Here are the slides opening the session: Media:WICSA08-Knowledge-w2.pdf.

Preliminary list of Discussion Topics

Please join the discussion and add to this list.

Our goal in this Working Session is to compare and contrast the inputs from academia and industry, and gain a shared understanding about what can be done now, and in the near future. We will start the WS with the following discussion topics, but further suggestions are very welcome.

  • Our first main question is "What is the relevant architectural knowledge we want (and can) share?". In more detail,:
    • Is it possible to define a shared body of knowledge about software architecture?
    • Is it possible to standardize the meta-models for architecture knowledge through a generic core meta-model?
    • How to bridge the gaps between the different architecture knowledge meta-models of various organizations?
    • What are the different categories of architectural knowledge? Is generalized, domain-, organization-, or project-specific architectural knowledge a good categorization?
    • What is the boundary of architecture knowledge in the problem space and in the solution space?
  • The second question is "How can we share architectural knowledge?". This can be further refined into:
    • How can we deliver or make accessible the right knowledge to the right person at any given point in time?. And what is the right knowledge?
    • How can we realize the necessary knowledge management strategies?
    • Can we build a common knowledge base for a web community?
    • What can the community contribute by populating the knowledge base?
    • Do managers and architects realize the significance of storing such architectural knowledge for their architectural projects?
    • How can we motivate the knowledge producers to put the effort in documenting their knowledge?
    • How open can the knowledge base be? Public access or restricted to communities?
    • What is the aim, goals and indented audience of such a knowledge base?
    • Can we initiate a wiki-based encyclopedia for architectural knowledge?
    • What are the relevant issues in populating such architectural knowledge encyclopedia?

The Economics of Sharing Architecture Knowledge

During the working session we discussed the importance of understanding the business value, or economics, of sharing architectural knowledge. Specifically, we discuss the following facets that need consideration:

  • Minimizing the time spent by an architect on deliverables means that the architect has freed up bandwidth to work on other important business objectives
    • Bredemeyer's notion of a "minimalist" architecture is compelling
  • A pragmatic reward mechanism needs to be instituionalized to encourage architects to populate the shared repository
  • In an ideal state, architecture should provide the characteristics of self-service, in that various stakeholders should not have to rely on the architect that designed a system (or system of systems) to explain the architecture. A self-service approach will allow various constituents to find the relevant information and consume it. This again, frees up critical resources for more business relevant tasks.
  • A shared repository should value the legacy works, such as critical algorithm design and solutions to specifically difficult problems.
  • The right metrics need to be in place to ensure that we are trackign the behavior that we find desirable.
  • The repository needs to reflect the importance and role of domain knowledge on an organization's ability to design good systems.
  • An approach to a shared community needs to factor into the vision the cost of adoption (and/or migration)

A few items remain a challenge, such how do you measure the value of

  • Preventing rework
  • Measure the value of architecture reuse


Architecture Knowledge Assets

In this working group we focused on the architecture knowledge assets that organizations can reuse in order to leverage and exploit their architecture knowledge.

Types of Assets

We have identified the following types of assets

  • Reference architectures
  • Packaged applications
  • Legacy applications
  • Architectural frameworks
  • Architectural mechanisms/aspects/tactics
  • Architectural building blocks (TOGAF style)
  • Component libraries
  • Components
  • Patterns, categorized according to three dimensions that are not orthogonal to each other
    • Abstraction (architectural, design and programming)
    • Application domain (embedded systems, web-based systems)
    • QA (security, fault-tolerance)
  • Method, which contains various reusable elements
    • Best practices
    • Guidance (techniques)
    • Work product templates (e.g. architecture description template)
    • Work product examples
    • Reasoning frameworks/test scenarios
  • Problems Space elements
    • Requirements
    • Scenarios/stories/use cases
    • Risks
    • Drivers
    • Concerns
    • Decision Topics
  • Reference models (provide input to the work of the architect)
    • Glossary of terms/vocabulary
    • Business/domain models
    • Analysis models

Classification Criteria for Assets

A classification is simply a way of "automatically" matching assets based on one or more asset attribute values.

  • E.g. All assets associated with the telecoms business domain
  • E.g. All assets whose cost is less than $100

The original output from the workshop is as follows (superseded by the statements above):

There are different classifications that can be performed according to the needs of the organization. These criteria are not orthogonal to each other:

  • Scope (Systems vs. Software Architecture)
  • Problem/Solution space (can be both depending on stakeholder’s point of view)
  • Lifecycle phase (e.g. Inception, Elaboration, Transition)
  • Software Engineering Discipline
  • Development process (RUP, IBM global services)
  • Application/business domain
  • Granularity
  • Variability
  • Articulation

Attributes of assets

These attributes are the metadata of the assets. An organization can include these metadata as a "cover page" of the assets.

  • General attributes
    • Contained artifacts
    • Name
    • Related assets
    • Usage instructions
    • Version
  • Process-related attributes
    • Author
    • Feedback
    • Rating
    • Reviewer
    • State (e.g. pending, draft, finished)
    • Time to live
  • Architecture-related attributes
    • Application type (e.g. packaged application, custom application)
    • Articulation (specification, implementation)
    • Asset type
    • Business domain (e.g. telecoms, finance)
    • Development discipline (e.g. requirements, testing, design)
    • Development process (e.g. RUP, IBM Global Services Method)
    • Granularity (e.g. large-grained, small-grained)
    • Level of abstraction (e.g. logical, physical)
    • Lifecycle phase (e.g. Inception, Elaboration)
    • Non-functional properties (e.g. cost, performance)
    • Scope
    • Source
    • Technical domain (e.g. embedded devices)
    • Variability
    • Visibility (e.g. classified, public domain)

The industrial perspective on limitations, advantages and requirements for an AK community

In this working group we discussed the limitations and advantages that industrial practitioners see in setting up a virtual community sharing AK. Specifically, we focussed on the hypothesis of having a fully open community, sharing both vocabularies and contents, and then various scenarios (less innovative) of closed communities. W concluded summarizing our discussion in a first research agenda to start with.

The long-term objective would be to build a kind of Wikipedia for AK (an "AKopedia") where the SA community would provide, consume, share knowledge in the field of software architecture.

Research agenda

  • the pros/cons of AK sharing are pretty clear within companies, but unclear what are the realistic scenarios/conditions for external sharing
    • possibilities are: membership in the profession like participating in standardization bodies (alignment with own commercial strategies); sharing with partner consultancies
  • a realistic starting set of AK that can be shared externally: decouple contents from the vocabulary
    • (speed up common understanding with partners in business)
    • normalizing vocabularies and process descriptions are definitely an option for public sharing
  • industry needs tools to replay reasoning as based on past decisions
    • (speed up decision making==> faster transition from innovation to commodification ==> focus better & come faster on the market)
  • find better way to "push" validated data to the relevant people
    • (enable architects to perform their job better/faster/gain know-how)
    • (requirement: control on the quality of pushed data, control on the production of quality data)

Industrial Limitations

  • security issues: contents that is possible to share with the outside world
    • legal and risks issues in publishing knowledge (what is my ROI and what is the risk in making AK available)
    • appropriate repository mechanisms to control access seem not sufficient
  • organisation culture: innovation/R&D or professional/closed culture
    • furthermore, micro-cultures within organizations further complicate the situation

Industrial Advantages

  • reasons for AK Sharing internally:
    • internal reviews
    • architectural decisions are an easy sell, enabling to e.g. motivate (decision making processes) with the management; easier to evolve the organization to accommodate new opportunities
    • assumptions to increase trust of potential business partners
  • sharing meta-level AK (enables the company to do a good job, corporate level) and engineering-level AK (provides guidance for V&V)
  • rejection of alternatives gives information about what constrains reasoning
  • makes it possible to have active IT portfolio management
  • different levels of inference: automated reasoning (old, does not work), and suggestion supporting reasoning of the architect

Requirements for a Hypothetical AKopedia Community

  • being non intrusive in the architecting process
  • mechanisms to operate regulations for retention: companies need to maintain information for a long time period, e.g. 10 years
  • (similar) mechanisms to operate regulations for destroying knowledge.
  • if AKopedia would be available "from others", professionals would like to do:
    • search by category
    • visualize trade-offs and what-if scenarios (similar to financial portfolios analyses)
    • pull information
    • push information to people in the company (enable architects with information)

SOA Decision Modeling (SOAD)

Anticipating Paris's call to action, Olaf started to get his hands dirty, capturing and sharing knowledge through his SOAD project :-)

First SOAD content can be found here:

(have a look at my ECOWS 2007 keynote http://soadecisions.org/download/BIT-SOADecisions4ECOWSExt.pdf and my OOPSLA tutorial http://soadecisions.org/download/t052-zimmermann-3.0.pdf

Retrieved from "http://wwwp.dnsalias.org/wiki/WICSA2008_WS2_Knowledge"
Personal tools