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
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.
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!
“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.
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.
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.
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.
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.
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.
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!
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!
Server Response from: ETNASC02