Home

Pflogging

the never-ending quest for pragmatic solutions, useful plans, flawless execution, and designs that endure
Home

User login

  • Create new account
  • Request new password

A number of key features are only available to registered users. They include:

  • Access to the full content of top-rated material (only teasers are available to anonymous users after the material has been posted for 45 days)
  • The ability to search site content
  • The ability to access reviews of books relevant to site material
  • The ability to access key quotes relevant to site material
  • The ability to access content from partner sites
  • The ability to rate material
  • The ability to post comments
  • The ability to post new information and propose it for publication
  • The ability to request email notification when selected content is added or updated

Recognizing and organizing domains

  • View
  • links
Submitted by Bryan Pflug on Thu, 12/22/2011 - 14:10

A domain is a specialized body of knowledge, area of expertise, or collection of related functionality over which rules and control can be exercised. Domain engineering is a deliberate process to discover commonality and variation for a designated area of domain knowledge, establish a modular architecture for that domain, and exploit that knowledge in shaping new product architectures and product lines which are designed to reuse components and artifacts across new product development and production.

Where traditional development approaches focus on producing a single product, domain engineering goes beyond this to concentrate on identifying the architectural changes that will allow modularity to be established for a product line. domain model for a set of product domains) .

When performed in a disciplined manner, businesses can use domain engineering to reduce costs and cycle times by selecting and evolving the best concepts and implementations from prior product development activities, and applying them in crafting new products over time.

For example, the telecommunications domain involves components, standards, and architectures for functions such as message transmission, switching, routing, sequencing.

Ships - airplanes - autopilot, sensors, stabilizers, propulsion systems, electrical power generation, waste systems, crew and passenger provisions, payload systems. Jim McCarthy describes the difficulty which arises when core product customers are internal: 

Key contributions in this context:

  • Product (as opposed to project) planning
  • Customer advocacy
  • Evangelism
  • Business value determination

Reuse through product lines is thus both different from traditional development and traditional replication. It is generally more costly to develop the core assets and accompanying architectural flexibility in core assets than it is to develop a specific solution the first time. Just as attention must be placed in how an individual product will be specified and constructed over time, before the goal of establishing a product line within an organization can be realized, analysis and design must be invested into a product line architecture and into creating corresponding members of the core asset base.  As a result, significant payoffs can accumulate as each new product is developed and deployed, once the core asset base is in place.

Technical product management must oversee core asset development and product development activities and ensure that those who build core assets and new products are engaged in the required activities of each effort, follow the processes defined for producing product lines and products, and collect data sufficient to track progress across these efforts.

core assets

up
  • Login or register to post comments