Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Definition

A "Brick" is a EA tool used in planning and communication. It is based on the NIH Enterprise Architecture Brick. A brick has the following categories, arranged in the ideal lifecycle flow from emerging to retirement.

 

Emerging

Strategic

Tactical

  • Technologies we are watching because they look promising for our organization
  • Technologies to evaluate
  • Useful to track innovation work
  • Recommended for use in 2 - 5 years 
  • Technologies we plan to invest in when 
    • they mature and/or are "ripe" for consumption
    • or we as an organization mature and/or are ready to consume
  • Recommended for use for 0 - 2 years
  • Worthy of investment for immediate needs

Baseline

Containment

Retirement

  • Recommended for use now
  • Technologies that are in use and have full support
  • Technologies in which we do not currently want to increase our investment
  • Technologies that may deliver great business or technical value
  • Scheduled for end-of-life

Brick Usage

  • The term "technology" includes tools, products, platforms, and protocols. Bricks could also be used to categorize the lifecycle of things other than technologies.
  • A technology can exist in one or more brick categories. For example, "HTTP" may be both baseline and containment, while "HTTPS" is both baseline and "tactical". 
  • The categories "tactical" and "strategic" can provide roadmap qualifications to "baseline" technologies
  • Typical lifecycle of technologies in a brick: emerging -> baseline -> containment -> retirement
  • Technologies typically enter the lifecycle as emerging.
  • Baseline technologies exit the environment through retirement, and almost always by passing through containment. 
  • Scope of a brick can vary, but the brick becomes less useful when it is too big or too small.
  • Strive for an open environment with one brick per domain area rather one brick to communicate to customers and one brick for internal team communication
  • Maintain a brick through periodic review

Issues

  • How to track pilots?
  • How to track things that have been evaluated and dismissed ("misfit bricks")?
  • How do we capture investment levels?
  • Should a brick communicate service levels? How do we communicate how long we expect to endorse something for?

 

 

  • No labels