SUMMARY:

• Eighteen years of experience establishing corporate data architectures; and building enterprise, subject area and application data models for clients in a variety of industries.
• This includes five years building ‘meta models’ for data repositories.
• A true business data modeling/data architecture expert.
• Familiar with several data modeling methodologies and CASE tools.
• Able to help clients expand their use of data to achieve corporate goals.
• Excellent communication and facilitation skills.
• Nine years Data Warehouse architecture and implementation experience, including data modeling, meta modeling, project management advice / consulting, ETL requirements and ETL testing, and source system documentation.
• Two years Database Design, Programming, and Technical Writing experience.

TECHNICAL SKILLS:

• ADW
• Data Resource Management;
• ITIL (Info Tech Infrastructure Library)
• Agile Development
• Data Scope
• JAD (Joint Application Development)
• Bachman
• Data Standards
• James Martin Methods
• Bill Inmon Methods
• Data Warehouse
• Life Cycle Diagrams
• Business Data Modeling
• Decision Support Systems
• Logical Data Base Design
• Business Information Modeling
• Derived Data
• Logical Data Modeling
• Business Process Reengineering
• Designer 2000
• Mapping
• CASE e - Business
• Master Data Management
• Common Data Layout (CDL)
• EasyCASE
• Meta Data
• Conceptual Data Modeling
• Enterprise Modeling
• Meta Model
• Entity Attribute Modeling
• Modelpro
• Data Administration
• Entity Relationship Modeling
• Normalization
• Data Analysis
• ERwin
• Oracle Designer
• Data Architecture
• ETL (Extract, Transform, and Load)
• PowerDesigner
• Data Definition
• Excelerator
• Reference Data
• Data Design
• Functional Architecture
• Relational Data Modeling
• Data Dictionary
• IDEF1X Methodology
• Repository
• Data Driven Systems Development
• IEF Composer
• Requirements Gathering
• Data Engineering
• Data Integration
• Information Architecture
• Information Engineering
• Source to Target Mapping
• Start Schema
• Data Integrity
• Information Management
• State Transition Diagrams
• Data Management
• Information Modeling
• Subject Area Data Modeling
• Data Mart
• Information Resource Management
• System Architect (tool)
• Data Modeling
• Information Systems Architecture
• Test Scenarios
• Data Quality
• Information Technology Infrastructure Library
• TOGAF (The Open Group Architecture
• Framework)
• Data Repository
• Information Warehouse
• Transformation Specifications
• Data Requirements
• Infrastructure Model
• Zachman Architecture

PROFESSIONAL EXPERIENCE:

DATA ARCHITECT CONSULTANT

Confidential, Boston

Responsibilities:

• ‘ Confidential Person’ - basic identifying and demographic information regarding the faculty members, other employees, students, etc of Confidential
• Faculty Appointments, Ranks and Tenure - academic appointments accepted by faculty members - their positions, contracts, tenure, ranks, etc
• Academic Disciplines - formally defined fields of study that faculty teach and conduct research in
• Sabbatical leaves of absence granted to particular faculty members
• Faculty Affiliations - formal relationships between faculty members and organizations affiliated with Confidential, relevant to the faculty’s academic or professional life, such as a professor at the medical school being affiliated with a hospital
• Faculty External Activities - professional work (paid or unpaid), such as consulting, for an organization outside of Confidential
• Based on reviews of business and IT documentation, and interviews with the relevant IT staff, produced a conceptual data model diagram for the above data, showing the principal entities and their relationships.
• After further meetings with relevant staff members, produced a logical data model (LDM) for the above data. This detailed model includes all the business entities (documented with business names and descriptions, synonyms, examples, and natural keys); the relationships between these entities; and the attributes contained in the entities (documented with business names, descriptions, synonyms, data type and optionality).
• Produced ‘Current State’ documentation for the above faculty data, identifying and describing:
• The Confidential ’s principal databases / files / workbooks that contain faculty data
• The relevant tables / objects / segments / worksheets within the above databases
• Produced matrices mapping the entities in the LDM to the above physical tables / segments / worksheets; to the Confidential ’s major business applications; and to the Confidential ’s faculty-related business functions.

Confidential, Raritan, NJ

Responsibilities:

• Produced a high level Data Scope Statement defining the data to be included in the first phase of the project.
• Interviewed IT managers and subject matter experts (SMEs), and defined and documented their information needs.
• Identified and described the major subject areas to be included in the first phase of the warehouse (‘Applications’, ‘Incidents’, ‘Service Requests’, etc).
• Identified data sources, and SMEs, for each subject area.
• Produced a Logical Data Model (LDM) for the first subject area (‘Incidents’) to be developed for the Warehouse.
• Met with subject matter experts; reviewed the metrics/key performance indicators to be produced by the Warehouse; looked at current Incident data.
• Produced a detailed Scope Statement defining the Incident data to be included in, and excluded from, the Warehouse.
• Produced a Conceptual Data Model, defining the major Incident-related data entities, and their relationships.
• Produced a Logical Data Model, defining all of the entities, their relationships, and their attributes. The entities are documented with good business names and descriptions, synonyms, and natural keys; the attributes with good business names and descriptions, synonyms, data type & length, and optionality.
• Mapped the Incident metrics/KPIs to the LDM, showing how the metrics’ answers would be produced.

Confidential, Norwood, MA

Responsibilities:

• Produced the ‘Data Model Deliverables’ document that defines the deliverables of the data modeling process, explains what these deliverables are, and identifies and specifies the constructs to be included in each deliverable.
• Wrote the name and description standards for the client’s new data architecture group.
• Established several other “best practices’ to be used by the new architecture group.
• Developed the initial Enterprise Logical Data Model ( Confidential ) for the client’s Health & Benefits line of business - the business of managing the various benefits their customers’ provide to the customers’ ‘participants’ (employees and retirees). This model formed the basis for the client’s long-term data strategy; and for the data aspects of several tactical projects.
• Developed the Data Scope Statement, defining at a high level the data that is included in, and excluded from, the Confidential .
• Interviewed several of the client’s business and technical subject matter experts (SMEs) regarding the data used by the company. Reviewed business and systems documentation, and existing database designs. Produced a high-level Conceptual Data Model (CDM) defining the data requirements for the following areas:
• Business Party - personal and contact data about the lives of the participants, their dependents, and insurance carriers.
• Participant Employment - information about the employment lives of the participants
• Benefit Offerings - the various benefits (health insurance, life insurance, savings plans, etc) offered by the client’s customers to the participants
• Business Rules - the rules used by the customers to determine who is eligible for which benefits at what price, etc
• Life Events - the events in participants’ lives (such as getting a promotion, or having a baby) that effect which benefits the participants are eligible for
• Eligibility, Pricing, and Elections - which participants are eligible for which benefits, at what prices; and which benefits the participants choose
• Starting with this conceptual model, and with continuing input from SMEs, produced a detailed, extensively documented Logical Data Model (LDM) from the above CDM, defining all of the relevant business entities, attributes and relationships. The entities are documented with good business names and descriptions, synonyms, examples, and natural keys; the attributes with good business names and descriptions, synonyms, primary-, alternate-, and foreign-key indicators, data type & length, and optionality.
• Reviewed the LDM extensively with the SMEs. Ensured that the data needs of the company were systematically and thoroughly analyzed. Encouraged people to model future, as well as current, information needs.
• Defined additional data constraints on the LDM’s attributes, beyond the constraints inherent in the model.
• Mapped the data elements in the client’s primary transaction system to the attributes in the LDM.
• Worked with the client’s data security / privacy staff to classify the LDM’s attributes’ data protection classifications.

Confidential, New Jersey

Responsibilities:

• Worked on a team developing a Proof of Concept for an Enterprise Data Warehouse (EDW) of financial information regarding the client’s professional services engagements.
• Produced a list of design decisions that should be made, and best practices that might be adopted, regarding the EDW.
• Developed the Data Scope Statement for the Proof of Concept; describing the data associated with two subject areas:
• Time (billed hours) charged to customers for work done by employees on professional services engagements
• Classifications of financial transactions - how billed hours, expenses, collections, etc, associated with employees and engagements are classified, how they are ‘rolled up’ by organizational structure, geographic location, types of services, etc
• Reviewed the EDW reporting and dashboard requirements for billed hours, and financial transaction classifications. Reviewed existing database designs and previous data models. Met often with analysts who know and use this data in their work.
• Produced the Logical Data Model (LDM) of this data, consisting of diagrams, entity and attribute definitions, sample data and derived data definitions.
• Assisted the technical folks in producing the physical database design from the LDM.

Confidential, Portsmouth, NH

Responsibilities:

• Established the ‘meta data requirements’ for the IM team’s data scope statements, logical data models, derived data specifications, and source system documentation (that is, defined the information that should be included in each of these artifacts).
• Produced the Data Scope Statement defining the data that will, and will not, be included in the client’s ‘Business of IT’ Enterprise Data Warehouse (EDW). Interviewed IT managers and subject matter experts, and defined and documented their information needs. Identified and described the EDW’s high level areas of data (hardware and software assets, IT services, IT projects, work force management, suppliers, applications, etc). Identified and described the main sub-areas of each of these areas. Identified likely sources of data for each area. Documented areas of data that will not be included in the EDW.
• Led the effort to document the systems / databases that will serve as sources for the data warehouse.
• Met with subject matter experts of the first four source systems, and produced the relevant documentation for those systems, including the business meaning of each element.
• Served as the data lead on the ‘Software Entitlements Repository’ project to build a database to capture the ‘entitlements’ to commercial software that the client has purchased or otherwise has a legal right to. An entitlement defines how many licenses of a particular software product the client is entitled to install / use and for how long; whether those licenses are covered by maintenance; the associated use rights (eg ‘maximum number of concurrent users’); restrictions on the use of those licenses; etc.
• Reviewed the existing spreadsheets containing some of this data, and the systems that might provide the rest of the data. Met with the business owners of the data and the business people who will use the Repository.
• Developed a Data Scope Statement for the Repository.
• Developed the Database Design for the Repository.
• Defined the input files by which the data for this repository would primarily be captured.
• Produced the specifications defining how these input files are mapped to the database design, and what processing is required to load the files into the Repository.
• Designed the tests needed to ensure that the ‘input programs’ load the Repository from these files properly (defined the business scenarios, input data, and expected results in the database); and tested the input programs.
• Assisted in designing the user interface for the Repository.
• Reviewed and commented on the business process requirements for the new system.

Confidential, Boston

Responsibilities:

• Instrument Classification. Produced a model representing how the client classifies financial instruments according to the instruments’ financial and trading characteristics. Produced a second, “generic”, model that allows different business units to adopt their own financial instrument classification schemes.
• Industry Classification. This model defines the data needed to classify organizations according to the type of business they are in, using standard industry classification schemes.
• Ratings. This model captures the credit ratings assigned to the financial instruments, and to the issuers of those instruments, by credit rating agencies. Took an existing model, and enhanced and documented it.
• Contact Mechanism. This is a standard data model to capture email and postal addresses, phone numbers, etc.
• Business Party. This is the beginnings of a model to capture the data needed by the client about the people and organizations the client does business with. This first phase of the Business Party model focused on the client’s counterparties, and the financial risk the client is exposed to by these counterparties.
• Produced a very “specific” data model suitable for business review, and a more flexible “generic” model to be used when generating the database.
• Produced the data modeling standards that define the major deliverables (conceptual, logical and physical data models) that are produced by the client’s Enterprise Data Modeling group.

Confidential

Responsibilities:

• Served as the data analyst on the ‘Risk Work Station’ project to automate the process of identifying and managing investor brokerage margin accounts deemed in danger of not being able to meet potential margin calls.
• Helped identify and define the data needed for the project - mostly data regarding stocks and other investment securities.
• Identified and documented sources for the required data in existing internal databases and systems.
• For the data that cannot be sourced internally, acted as the primary contact for industry vendors that might provide the data.
• Met with vendor sales and data people to define the data needed.
• Reviewed the vendors’ proposed mappings (where in their databases they would get the required data). Made several changes to these mappings, helping the vendors find the appropriate data in their systems.
• Reviewed sample data provided by the vendors, making sure it passed the ‘smell test’ - that it looked like appropriate data. When the sample data looked invalid, worked with the vendors to update their mappings.

Confidential, Smithfield, RI

Responsibilities:

• Worked as part of the client’s Data Engineering team on several projects to enable the business to sell new products, find new customers, and better serve existing customers.
• Received the projects’ data requirements; researched and analyzed them; and, using the relevant parts of the client’s Enterprise Data Model, transformed these requirements into a data model and database design. Encouraged project teams to model future information needs, in addition to the immediate project requirements. Reviewed these models with the Data Engineering team. Updated the client’s enterprise data model to reflect these project models.
• Explained the models to the projects’ analysts, developers and DBAs. Helped the analysts maintain their documentation.
• Presented proposed changes to the enterprise model and database to the client’s Architecture and Standards committee.
• Dealt with issues regarding data quality, performance, data loads, etc.
• Improved the documentation of large parts of the enterprise model.
• Performed the above tasks for over a dozen projects
• The Retirement Plan Pricing project, to calculate the appropriate fees the client will charge a plan sponsor for managing the sponsor’s employee retirement plan. This application takes the appropriate inputs regarding the retirement plan (the number of employees, any optional services requested, etc), and generates the appropriate one-time and ongoing fees the client will charge for being the plan’s record-keeper.
• The Retirement Compliance project, to enable the client’s Compliance group to track, and report on, the various documents required in order for the client to assume the management of a plan sponsor’s employee retirement plan.
• The Literature project to encourage/assist customers in ordering literature regarding the client’s products via the internet, by developing associations between literature items, and presenting associated items to clients who expressed interest in a particular item.
• This gives the client’s customers an “amazon.com experience”.
• The Voice Response Unit project to enable the client’s customers to get information regarding their accounts via an automated telephone system; and enables the client to log and report on these activities.
• The e-Business Security project to centralize all authorization and security regarding customers’ access to the client’s systems.
• Helped the client establish Data Management “best practices”, by producing a series of papers setting forth standards and procedures to be used in the data engineering area. These included:
• Business data modeling best practices, such as naming and description standards, and standard data models for commonly used data (such as a standard ‘contact mechanism’ model to capture addresses, phone numbers, etc)
• Technical database best practices, such as primary key standards, and standards for creating history/audit tables, etc

Confidential, Marlborough, MA

Responsibilities:

• Interviewed the project sponsors, the technical staff who built and maintain the current Data Warehouse (DW), the users of the current DW, and potential users of a new DW and Data Marts.
• Analyzed the current DW database design and documentation.
• With the information gathered from these activities, helped produce:
• The “Current State” documentation of the DW architecture, with recommendations for improvement; assessments of the DW’s physical database design, with recommendations; and a high level assessment of data gaps and data quality issues of the DW.
• The proposed “Future State” environment, including a diagram showing the various components of the future environment (the “ETL component”, the “Data Mart component”, the “Meta Data component”, etc), and the flow of data through these components; descriptions of each of these components; recommendations/best practices for the proper architecture and methodology for producing these components.

Confidential, Manchester, NH

Responsibilities:

• Met extensively with the project’s manager and business representative.
• Produced the data scope statement for the project.
• Specified the movement of data to/from the different system environments, in each case defining:
• Any new database structures needed to hold the data, documenting these structures in a business-friendly way.
• These database designs are used by the DBAs to create the required tables.
• The processes to load the various database structures, including the mappings and extract, transformation and load (ETL) specifications from the source environment to the target environment. These functional specs are used by the developers to write the programs that move the data.
• The error tables and error processing needed for each data movement.
• A set of “testing scenarios” describing data that should be tested, including the expected results of the scenarios.

Confidential, Smithfield, RI

Responsibilities:

• Developed the data requirements for three of the project’s Data Marts
• Managed the organization’s Enterprise Data Model (EDM). Enhanced the documentation of the existing EDM.
• Analyzed the data needs of several projects. Provided the projects’ data modelers with the relevant parts of the EDM to use as the basis for their project data models. Worked with the modelers to update these project models to meet the needs of their customers. Integrated these project models back into the EDM.
• Developed subject area life cycles for the main subject areas in the EDM . These documented the main activities and organizations that create and use data about the Subject Areas.
• Facilitated the client’s Corporate Information Architecture ( Confidential ) committee - the group charged with overseeing compliance to the company’s data architecture standards. Served as the liaison between the Confidential committee and the client’s technical staff.
• Organized and chaired the committee meetings and participated in the reviews. Performed any needed post meeting follow up.

Confidential, New York

Responsibilities:

• Documented the database of the corporate “system of record” for Provider data - data about doctors, hospitals, etc.
• Interviewed business and systems staff about the data in the system and how it is used; reviewed existing system documentation and database schemas.
• Produced extensive documentation for this Provider database, including a business name, business description, edit rules, legal values, and physical database properties for each field. Made this documentation useful to both business people and I.T. staff.
• Based on the above interviews, documented possible enhancements to the current system and business processes - items that would yield improvements in data quality and/or business efficiency with small (or no) changes to the system.
• With the information gained from the above interviews, developed a Logical Data Model of Provider data.
• Produced the data scope statement for this data model, specifying the data that will, and will not, be included in the model.
• Produced data model “views” for the “Provider Demographics”, “Provider Relationships”, “Practitioner Credentialing”, “Provider Practice Site”, “Practitioner Service Visit”, “Contact Mechanism”, and “Provider Network” subject areas.
• Each of these views contains one or more entity-relationship diagrams, and consists of all of the logical entities, the relationships between them, and their attributes. Ensured that all the above views are integrated into one logical model for Provider data.
• Produced formal mappings from the fields in the system of record data base to the attributes in the data model, including any required transformation logic.

Confidential

Responsibilities:

• Reviewed the project’s data architecture - the data requirements definitions, methodology and documentation; and existing data models and database designs - and made recommendations for integrating various data modeling efforts, and for having a consistent set of information captured during these efforts.
• Reviewed the data requirements section of the company’s proprietary development methodology, and recommended changes to make this “data language” more complete, consistent, robust and understandable.
• Produced a data architecture of the processing requirements part of this methodology, consisting of:
• A formal scope statement, specifying the data to be included in the model, and how that data will be documented.
• A conceptual data model, defining the major entities and the relationships between them.
• A logical data model, defining the logical entities, their attributes, and the relationships between them.

Confidential, Melville, NY

Responsibilities:

• Played several roles on a project to develop the “Vendor Management and Negotiation” data warehouse, to be used by the client to combine vendor, part, inventory, purchasing and sales information from several European subsidiaries into a complete and historical picture of the client’s relationship with those vendors.
• This holistic vendor view is used by the client to better negotiate with the vendors (eg negotiating a discount when purchasing from several subsidiaries of the same vendor).
• Assisted in the development of the dimensional data model used to capture the client’s data requirements for the warehouse.
• Assisted in keeping the warehouse logical data model in sync with this dimensional model.
• Using the above data models and extensive client input, developed the transformation specifications for the source files that populate the warehouse. These specifications detail the business requirements for mapping the data in these source files to the warehouse; and for the edits, validations, default values, data transformations and other actions that must be performed on the source data before it is loaded into the warehouse.
• Based on the above transformation specs, produced the plans to test the ETL programs. These test plans consist of business scenarios describing, in business terms, the data to be included in the test; the definition of the actual data records that correspond to these scenarios; and the expected results of the scenarios.
• Wrote documentation for the ETL programmers explaining how to read and use these transformation specs, test scenarios and data definitions; and how to review the results of tests to determine if the ETL programs perform correctly.

Confidential, Waltham, MA

Responsibilities:

• Helped lead the client’s effort to establish a company-wide Data Administration function, and to institute a data driven, and model driven, systems development process.
• Specified, extensively, the deliverables of the data modeling process, identifying these deliverables, describing their roles and purposes, and documenting the constructs that should be included in each.
• Assisted in developing the meta model of the above data model deliverables. This meta model is a core piece of the company-wide repository. Wrote the scope statement for this model. Reviewed the model as it was being designed; made several enhancements.
• Documented the process of developing good data models, including a step-by-step approach to producing data models with the constructs listed in the above data model deliverables documentation. Specified the order in which the constructs should be captured, who should be involved in which steps, “tricks of the trade” in eliciting the required information, etc.
• Updated the client’s I.T. project life cycle documentation to include data model deliverables and the data modeling process.
• Wrote the client’s data modeling naming and description standards.
• Developed a subject area data model for the new Provider database being built by the client (a Provider is a person or organization that might be reimbursed for providing health care services). This database is used by the client’s Provider Information Center to better service and monitor the providers (eg, providing faster response to questions/complaints).
• Together with the business sponsor, wrote the data scope statement specifying the data that will, and will not, be in the database.
• Organized a data modeling team of people from various provider related business units. Facilitated the modeling sessions of this team. Explained the purposes and techniques of data modeling to members of the team. Documented the results of the meetings and performed between-meetings follow up. Based on the information generated and analyzed by this team, produced:
• A conceptual data model. This model defines the major data entities and the relationships between them.
• A logical data model, consisting of all of the logical data entities, the relationships between them, and their attributes.
• A mapping of the attributes in the logical model to the business requirements specifications for the system.
• A list of future enhancements, stating ways in which the data models might be extended.
• Documented, tracked and resolved outstanding issues related to the models.
• Documented all changes to the models and supporting documentation. Kept all of the deliverables in sync.

Confidential, New Haven, CT

Responsibilities:

• Supported the effort to design a data warehouse to meet the Confidential ’s financial planning, management and reporting requirements, by developing models of the Confidential ’s core financial data, including their chart of accounts.
• Defined the deliverables of the modeling effort. Defined the naming and description standards for the models.
• Received sets of attribute definitions from business people and met with them to clarify these definitions and resolve issues. Reviewed the design of the on-line transaction database of the ERP system being implemented.
• Took this business and database information and developed a data model of the Confidential ’s general ledger function (journal entries, general ledger balances, fiscal calendar and budgetary information).
• Also developed data models for the four segments of the Confidential ’s chart of accounts: