Top 10 Reasons to Use ER/Studio Repository

By: Gregory Keller

Abstract: A guide to using ER/Repo and its benefits

Top 10 Reasons to Use ER/Studio Enterprise Repository

Reason to Use

Pain

How solved

1

Accelerate development

I have developers who take forever to complete the design portion of projects as they need to wait for each other to complete their aspects, and pass to the next. This takes way too long! Our document management system isn’t working as only one resource at a time can safely check out a model to work on.

  • Radically improve developer productivity by allowing a centralized collaboration system between modelers.
  • Allow many developers to work safely and collaboratively on the same designs at the same time.

2

Integrate project stakeholders

Data architects hand us specs and changes in paper documentation that developers must parse through and then implement in database code (DDL). We are woefully inefficient with our current process!

  • Integrate data architects using business/logical data models DIRECTLY with developers using physical system models
  • Repo becomes a centralized up where the business and development can SIMPLIFY collaboration between them to reduce time to market problems and increase efficiency when a data modeler needs a change that  a developer must pick up and implement.

3

“Build once, use lots”

We have developers CONSTANTLY re-building the SAME data elements and model patterns over and over. This costs us UNTOLD time and money by replicating the structures and THEN having to fix/or transform the data to have it meet corporate data standards.

  • Use Repo to standardize sets of model patterns AND smaller data elements…e.g. columns/domains.
  • Advertise them through the repo so developers can re-use them over and over…all the while saving time, and reducing errors

4

Reduce project risk

When we implement something in production OFTEN a developer has made an errant mistake and we then need to do a fire drill to find out the issue in the schema…and it’s often like looking for a needle in a hay stack! It takes hours which could cause delays in getting the system back up to previous/stable conditions.

  • Use Repo’s configuration management system to manage versions of model, and individual model objects
  • Understand who did what when VERY simply to data models/schemas
  • Roll back efficiently in seconds to ‘gold’ schemas to restore systems.

5

Centralize and standardize data metadata

We have definitions in various places…Excel sheets, some data models I see hanging on cubes and I think there is an Access database but not sure who owns it anymore. We really have no central place of knowledge about our systems and the types of data they manage.

  • Use ERStudio to scan and input models into a centralized repository in minutes.
  • Leverage sophisticated tools and automation to rapidly document the meanings of the systems and underlying data.

6

Communicate to the business

We have various parties coming to us here in data architecture  for knowledge about where specific data lives in systems. It’s KILLING our productivity to constantly respond to these needs…we have to write custom reports every day for ETL developers, business analysts and warehousing stewards.

  • With all ER/Studio models centralized and documented in the REPO, use PORTAL to communicate to the business this rich information in a ‘self provisioning’ style.

7

Create an effective change management process

We have a fairly clumsy process for when the business needs something done./added/deprecated in database systems and how our developers need to act on it. Now it takes place through Remedy tickets but the developers still need to understand the semantics a bit better before implementation. We need a way to smooth out data modeler to developer to database ‘fix’ process.

  • Use Repository to flow information from data architects instigating required changes to developers directly through repository.
  • Developers can leverage ERStudio’s well known database modification systems once they have been notified to check out specific  models ready for implementation on systems.

8

Secure privileged information

We have many systems that manage sensitive/proprietary data. Right now, it is a struggle to communicate all those fields that must be secured/encrypted in systems and ensure that our IT managers know we are following regulatory practices at those low levels on the data.  

  • Use the secure data tagging system in ER/Studio then easily report upon where these finite elements live across the various data models/systems managed in the repository.

9

Preserve historical perspective

It seems like every quarter or so a fire drill erupts by management to understand how many systems we have, who manages them, what data they contain, etc. Every time we do a system scan and generate some Excel workbooks which then get reviewed…and subsequently lost. We’re tired of this!

  • Centralize knowledge of the database systems being managed in your enterprise by cataloguing them in the repo
  • Use extended metadata properties to tag who manages the systems, the types of applications and processes tapping into the data.
  • Generate reports the same way every time on this data OR use Portal to allow management to get this information in real time when they need it…not just during fire drills.

10

See the impact across the enterprise

When the business says ‘I need a change’, I sweat. This typically means we need to analyze how a change of an element may traverse ACROSS systems…not just how it may impact object dependencies on the single system. We have no easy way to know what will happen across systems!

  • Use Repo’s Enterprise Data Dictionary system to understand how changes to data elements may be required across MANY systems…e.g. many data models.
  • Visually understand where specific elements are in use to radically improve research time to estimate system wide impact to data changes.

Server Response from: ETNASC04