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 15 Next »


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.





  • 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




  • 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.
  • Technologies in tactical and strategic designations should be selected for future implementations and will begin to, or continue to, reside in the baseline.
  • 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
  • A technology typically enters the environment designated as "emerging". If the technology is approved and supported, it will become "baseline". It will 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


  • 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