System Transformation

Home    Site Map
About Tactical Strategy Group

Organizational Transformation    IT Architecture Transformation
Contingency Planning / Risk Management    Transformation Solutions

A grouping of work steps within an Ulrich-SRM scenario generally represented by a box within a scenario overview diagram

Activities may also contain scenario specific notes or guidelines.

See Assembler.

Data elements mapping to the same physical data with the same definition (same length, type, occurrences), but having a different data name

Aliases involve multiple definitions for the same record or element caused by poor Copy member utilization and by programmers creating hard coded record definitions. Other sources of alias creation and propagation include a lack of central or enforceable data administration standards.

A COBOL verb which changes the target of a Go To in a different paragraph

This construct complicates the ease with which the program can be maintained because the destination of an Altered Go To is difficult to see. The Alter is considered a violation of structured coding principles.

Application Programming Interface (API) is a called (or optionally in-line) routine that expands or contracts data formats during application execution to reconcile expanded or un-expanded data formats between an application and a shared data store (i.e. an on-line file or shared data base).

The way an application system is assembled

This includes how the data is stored and accessed (i.e. flat file, hierarchical, relational, etc.), how information is inputted and received by the user, how an application interfaces with other applications, the way functions are distributed or grouped across programs and a host of other issues. Three main aspects of architecture include the business or functional architecture, the data architecture and the technical architecture.

E. Ashcroft and Z. Manna demonstrated a method of converting unstructured programs to structured ones. Note: In and of itself, it is not an elegant solution due to the fact that it is a switch driven solution.

Assembler, also called assembler language code (ALC), is a low level computing language (second generation language) that is used to develop operating systems as well as application systems. IBM Assembler was widely used for these purposes.

C. Bohm and G. Jacopini defined the fundamental constructs of structured programs: sequence, selection and iteration.

The derivation of requirements, analysis and design models resulting from current systems and application area analysis through the use of automated recovery tools, techniques, interviews and humanistic interpretation of subsequent findings.

A routine that expands or contracts batch data files to reconcile data format differences between expanded and un-expanded data stores in a Year 2000 project.

An organization specific, functionally bounded segment of an organization that, in IS terms, is supported by multiple application systems.

A combination of conditional and imperative logic that changes the state of an object or data element - depending on the methodology being used.

A programming language typically used for client/server system development.

An object oriented programming language typically used for client/server system development.

Acronym for "Computer-Aided Software Engineering"

This is the process where development and modification of software is accomplished with software designed for this purpose.

Century Date Change (CDC) is the impending Year 2000 millennium change and its resultant impact and potential disruptions of business services, information databases and application systems.

An application parameter representing the 2-digit year upon which the century date will toggle in a Year 2000 procedural workaround project. Any 2-digit year higher than the century midpoint would be assumed to have a "19" in the century field, and those lower than or equal to the century midpoint would be assumed to have a "20" in the century field.

Commonly used IBM telecommunications management product.

Common Business-Oriented Language. COBOL is the leading programming language used in the business world.

See Defects

See Replication.

The process of dividing a program into two or more smaller, separately compilable, more manageable modules. Also called code "slicing".

An Ulrich-SRM major Positioning task containing the Code Flaw Analysis & Removal, Code Restructuring and Design Review & Improvement tasks

Its goal is to improve the cosmetics, packaging and design aspects of individual source programs without changing their functionality.

A category of measuring the effort required to maintain or enhance a program

This could involve the data representations or the way a program was constructed. Also implies difficulty levels in understanding and modifying applications at the system level.

A clearly delineated instance or occurrence of a physical, logical or externally defined item or work product within or associated with an application system.

For example, a source program, a function and a change request are three different types of components. These may relate directly to object types defined within a repository model (see Legacy Transition Meta-model).

The process of combining two or more procedures which are executed sequentially.

A source code instruction, or sequence of instructions, that is patterned in a known format and that executes in a predictable manner.

Instructions in a program or procedure that direct the sequence and conditions of execution of other instructions or programs.

In a computer source program, a change of control flow to a statement other than the next one, or from a calling program to an external program or subroutine.

A computer source program reserved word (verb), such as IF, Go To, Perform, Alter or Perform Thru, used in a program to transfer control explicitly.

A metric referring to the number of occurrences of a physical component, construct or combination of construct types within an application program, system, division, enterprise, etc.

An attribute of an entity that represent a quantitative value (such as an inventory item having an entity type called maximum value which is set, for example, 1000).

A term used in graph theory to describe the number of basic paths through a graph (See also McCabe Metrics and Appendix B - Procedural Metrics section.

A major Ulrich-SRM Positioning task that includes Data Name Rationalization, Field & Record Size Expansion, Literal Externalization, Data Definition Migration and Physical Data Upgrade. Data or data definition related tasks that fall into the Positioning stage will continue to be defined under this major task heading.

A diagram, typically automated using various tools, that depicts data flowing from one process to another. This model type is used within Ulrich-SRM to depict major data flows and related activities within a system or across the enterprise. These techniques are defined in the General Systems Architecture Assessment.

The process by which data element definitions are modified so that each element retains the same name and characteristics throughout an application system. This has a tendency to dramatically reduce the actual number of record groups and physical data names within a system by creating reusable Copy or Include code blocks for a given record, segment or table definition.

Portion of a program that is never executed because it cannot be reached by the static flow of control logic (syntactically dead). (Also see Unentered Procedure or Unexecutable Statement.) May also be dead based on certain data values never being true (semantically dead).

An executable program that is never executed due to system control objects (JCL, on-line control tables, Call verbs, etc.) never invoking that subroutine or load module within the production environment.

(1) Messages or warnings denoting a known condition, situation, or problem in a computer program.

(2) Defects include violations of structured source coding constructs that may, in fact, be acceptable to a given compiler, but which are unstable in nature. Defects make a program more difficult to maintain and are defined in greater detail in the Ulrich-SRM Metric Guide - Appendix B.

The output results delivered from a given step and / or task within Ulrich-SRM.

Deliverables may include models, metrics, documentation, source code, narrative summary, forms and executable systems.

The process of planning, analyzing, designing and constructing software systems to satisfy new or redefined applications requirements. This may be driven by iterative prototyping, spiral design, waterfall design or other means.

See Defects

An object, such as a data element or record, that is used within the system in which it was created and passed on or received from a related system.

A knowledge base of information, typically stored in a proprietary format, that is used by I-CASE or client/server development tools as a means of storing and linking various development models. This differs from a repository in terms of how open the meta-model may be to extensive modification and refinement.

A stage within Ulrich-SRM that is a collection of tasks for assessing enterprise wide, architecture transition requirements across business area boundaries. Basic techniques also include developing a baseline for IS asset management, auditing current project activities and segmenting the enterprise for large-scale, cross-functional projects. Main deliverable includes a cross-functional transition strategy.

Within Ulrich-SRM, identification of any recommended prerequisite external activities or Ulrich-SRM specific tasks.

A term used in graph theory which represents the count of unstructured constructs in a control flow graph. (See McCabe Metrics in Appendix B - Procedural Metrics).

A happening in the business that triggers a business rule to be invoked. Also see Event Modeling.

The amount of time that an application has left to begin a Year 2000 migration to prevent that system from failing due to misinterpretation of time dependent events.

A series of events, depicted in a diagrammatic format, that mirror real life activity cycles and can be interpreted by certain development tools in order to create operational systems.

A more detailed or specific decomposition of an event.

Key points that assist an analyst in determining when an Ulrich-SRM task has actually been completed.

1. The removal of a COPY statement from a program during restructuring process and the placement of the statements from the COPY member into the program without reference to their origin.

2. The increase in physical or logical size of a record or element definition or the corresponding physical data that is referenced by that element or record.

A file or data store received from or passed to an interface system.

Physical or logical descriptions of an application system including models, documentation, job scheduling information, a data dictionary or repository. This information is initially gathered during the environmental analysis task.

Implicit transfer of control from one paragraph to the succeeding paragraph or module in a source program.

The process of eliminating a separately named procedure by moving the code it contains into the procedures which invokes it.

The traditional process of moving high-level abstractions and logical, implementation independent design to the physical implementation of a system. Source IEEE.

A group of business activities, which together completely support one aspect of furthering the mission of the enterprise (source Information Engineering). Used within Ulrich-SRM as a first level analysis in decomposing existing systems and mapping those systems to strategic target models.

An Ulrich-SRM, Inventory/Analysis major task that evaluates current system user backlog requirements, builds and compares bottom up data and functional models with target or top down models, defines the intersection of current data and functions, re-documents existing systems and determines the role of current systems under a strategic replacement initiative.

The amount of time, or number of years, up to which an application must be able to project dates in order to process properly.

A way to represent the flow of control through computer programs. McCabe complexity metrics are computed by counting nodes and connectors within these graphs. Graphs can also be used as a basis to restructure programs through simplification of complex expressions of the control flow.

(1) A family of coding or design methodologies where program control blocks always proceed from a controlling procedure to an invoked procedure and back. Use of these methods results in systems that are easier to understand and maintain.

(2) Also refers to data structures that support a child / parent relationship between segments or record types. IMS is a hierarchical data structure.

Data elements mapping to different physical data, but with the same data name. They often will have different attributes such as length and type. Programmers can very easily make wrong assumptions about what these data elements really are.

"Integrated CASE" is a CASE tool that allows developers to share meta-data developed or modified during one phase of a development cycle with that developed or modified during another phase of a development cycle. Typically includes planning, analysis, design and construction.

Commonly used, IBM hierarchical data base product.

An interlocking set of formal techniques in which enterprise models, data models and process models are built up in a comprehensive knowledge base and are used to create and maintain software systems.

Within an Ulrich-SRM task, the system components, previous task deliverables or related inputs required to begin and complete a given task.

A file used only within the system to which it is defined.

A stage within Ulrich-SRM that is a collection of tasks for determining the state of current applications, identifying future information requirements and articulating a plan to meet interim user needs and long term strategic requirements. Also serves to re-document legacy applications.

When used within the context of a Year 2000 project, a routine that reconciles different data formats between upgrade units that are at varying stages of the conversion cycle. Also see API and Bridge.

Any system that receives data from or sends data to systems involved in an assessment - but that is not involved in the assessment itself.

A deliverable from the Inventory/Analysis, Interim Support Planning task that details how existing systems are to evolve under the current architecture. The term "interim" implies that various Positioning tasks and functional upgrades are to be applied under the current technical, functional and data architecture. Interim does not necessarily imply a brief time span.

A task within the Ulrich-SRM Inventory/Analysis stage that determines an application area support team's background and skills in process management, methodology, tools and testing techniques.

A record group (see record group) that contains at least one record definition used in an I/O (input / output) transaction.

Interface point where a system with expanded fields passes data, receives data or otherwise interacts with another system whose corresponding fields have remained unchanged.

Information repository that contains object definitions comprising a system's design representation and the relationships among objects as well as syntactic and process rules that define a correct design within the development methodology in use.

The Legacy Transition Meta-model, or LTM, is an entity relationship model representing current and target system components, and relationships between those components, that can be depicted in an open repository. It is used to cross reference, trace, track and audit physical, logical and externally defined system components before, during and after a redevelopment project.

The LTM is referenced in a large number of Ulrich-SRM tasks, requires some type of open repository facility in order to support practical use, and is almost always customized for a given organization / project. Note that multiple LTM implementations typically apply within an organization and project.

Data elements used to accomplish an intermediate task or calculation within a program and only within that program.

An attribute describing a data item defined to one or more programs that has been defined one time within the system (i.e. no redundancy). There are typically many physical element definitions to one logical data element definition.

The full aggregation of attributes with no redundancy describing an I/O record in the context of the programming language being used. There may be many physical records used to describe a single logical record.

See Defect

The sequence of coded instructions in a computer program that performs a function or task from one to many times. Logic paths lead to a termination or program exit point, back to the point of invocation (into another path) or into a loop.

See Legacy Transition Meta-model

Process of applying changes to existing systems that typically includes corrective, adaptive and perfective activities. Large scale architectural change is typically not considered as maintenance. The three common types of maintenance include the following categories.

Corrective maintenance identifies and corrects implementation flaws or design errors.

Adaptive or functional maintenance deals with changes in the data requirements or processing environment.

Perfective maintenance supports performance improvement, cost reduction efforts or required technical improvements.

A group or collection of tasks within an Ulrich-SRM stage. This is depicted by the "···" ellipse on a stage diagram box for a major task. Functional assessment, for example, is a major task within the Inventory/Analysis stage.

Metrics described by Thomas McCabe. Basic metric types include cyclomatic complexity which measures the testability of a program and essential complexity which measures the structure of a program. (Also see Cyclomatic Complexity and Essential Complexity and Appendix B - Metric Guide.)

A detailed and structured approach, containing generic and tool related step-by-step guidelines, to developing, upgrading, improving or replacing application systems. Also called a "blueprint".

A numeric count or derived score that in some way quantifies attributes of an application system, external system descriptions, support areas for a system or a relationship between two or more existing and / or planned systems.

Technology that facilitates communication between workstation and host platforms by linking graphical front-end technology to a host environment. This interface includes direct links to legacy programs, legacy data and / or other server platforms.

1. This measure is the depth within a program logic path at which references to procedures reside in a program. The first level of nesting is the initial program entry point.

2. This measure is the depth within a system logic path and is generally measured by Call structure control transfers between modules. A driver program Call to a subroutine would transfer control from level one to level two.

Branch to a sub-routine that never returns control to calling program. Example: Call Abend.

An abstraction of certain business information, within a specific problem domain, that encompasses both data and processes (behavior) associated with that information.

Design technique that incorporates concepts of object-oriented programming such as information hiding, inheritance, classes, abstract data types, and messages. It supports object oriented programming techniques that involves a reusable building block approach to development.

The execution of a business rule in event modeling.

The conversion of physical system components into data structures suited to code transformations within a software engineering tool. All tools used to document, analyze, import, improve, reverse or in any other way process existing source or executable object types of any nature require this facility. An example of a tool containing parsing technology is a source code compiler.

The object of a Perform statement in COBOL. A Perform range can be either a Section (with a reference in a statement of the form "Perform Section-name"), a single paragraph (with a reference in a statement of the form "Perform paragraph-name") or a group of paragraphs and/or Sections.

A construct in which a COBOL Go To statement within the range of the Perform branches outside the controlling Perform. A Perform range violation is considered a violation of structured coding principles.

A group of related activities within an Ulrich-SRM scenario.

A given scenario typically contains one to three phases, each of which is comprised of one to four activities.

The actual pieces that comprise an executable production system such as JCL, load modules, source code, screen maps and related items.

Representation of Physical System Components within a repository or pseudo repository storage facility.

A commonly used third generation programming language found in many IBM mainframe environments.

An Ulrich-SRM stage that is a collection of source code to source code improvement or front-ending tasks that facilitates the understanding and maintenance of programs and/or systems, while preparing systems for redesign and reuse. Positioning tasks, by definition, impact form within impacting essential function. Examples include restructuring, slicing, data name rationalization and middleware enabling.

In event modeling, a condition that must be met before an operation can occur.

Data elements necessary to send information to and receive information from a system or program. Excludes elements a program may define to accomplish some intermediate task or calculation. Primary elements are typically the basis for any redesign or integration effort.

A logic construct in which three or more procedures transfer control to each other. Often these procedures are inter-related in a complex manner, with numerous references to each other. The impact on its ability to be understood is typically negative.

(1) A paragraph or Section in the Procedure Division of a program (especially COBOL).

(2) A module, or comparable construct, in a procedural language.

(3) Design level decomposition of a Process within the Information Engineering development paradigm.

A low level activity that begins and ends.

The analysis phase decomposition of a Function within an Information Engineering development paradigm.

See Unresolved Perform.

An approach used to restructure COBOL programs, in which control flow of a program is pushed through to termination and factored to force convergence and performability.

(1) The critical evaluation of software systems and the application of standards of quality to that system. This ranges from simply monitoring code structure, to programmer training or through the implementation of a comprehensive quality program.

(2) The process applied to programs and systems during a given Positioning task to ensure that functionality had not been unintentionally altered. Process is defined in Ulrich-SRM validation task under the Positioning stage.

(3) Review of key factors required to assure that an Ulrich-SRM task was adequately performed. Factors may be found in the Quality Checks section under a given task structure breakdown.

Involves iterative, rapid refinement of software designs by quickly generating working prototypes and using feedback of prototype results to improve design specifications.

A software system that interacts closely with an external physical environment and that must respond to external physical events in the time frame dictated by the characteristics of the external system.

A group of elements (such as a COBOL 01 level) and / or I/O records that have been grouped together based on common lengths, underlying record structure and / or verb transfer usage (i.e. Move, Read Into, etc.)

Construct where a procedure invokes itself, directly or indirectly. In COBOL, depending on control branches, recursion can be either Perform-based, which involves one or more Perform statements, or Go To based, in which there is at least one Go To statement in the recursive path. At a system level, recursion may be Call based, where a module can invoke itself through a chain of called subroutines. Recursion is a violation of structured design principles that results in functional and maintenance related problems.

See Systems Redevelopment

See Software Re-engineering

A diagram which describes data elements and relationships for part of a business, or for an entire enterprise. Involves "normalizing" data to optimize the design and implementation of that model.

Process of dividing a system or program into several smaller, more manageable modules and / or recombining those programs along functionally cohesive lines. This may include reconciliation of redundant logic and functional realignment of physical systems. Also, an Ulrich-SRM Positioning major task that includes Code Slicing and Code Reconciliation & Re-aggregation tasks.

An information storage facility or central database that contains all meta-data relevant to the management, design, implementation and transition of one or more information systems and / or for the enterprise. A repository is typically the physical implementation vehicle for the Legacy Transition Meta-model (LTM). Numerous commercially available repositories meet these specifications.

(1) The ability to analyze the essence of existing systems, constructs or designs as input to the creation of new or target systems, constructs or designs.

(2) Ability to use an existing software source module, a procedure defined within a single module, a procedure defined across multiple modules or any type of existing system object to assist with satisfying the requirements of a new target system.

(3) In a new development or maintenance paradigm, the ability to design and reference generic modules that allow for a "building block" approach to fulfilling the requirements of subsequent development / maintenance efforts. This includes the concept of reusable object libraries.

(1) Technique used by legacy designers and programmers to rapidly deploy replacement systems or build new programs by copying and modifying existing programs. It differs from reusability in that functionality of the originating component is cloned and modified one or more times, forcing departure from the original baseline and replication of maintenance effort over the long term.

(2) Method used to restructure source code by creating two or more identical copies of a portion of the program to de-couple intertwined logic constructs.

To convert an unstructured source program to structured source program by reducing the essential complexity of all module sub-graphs to a one.

The retention of a Copy statement in a program during the restructuring process. (Antonym: See Expansion.)

Process of analyzing a system to identify components and interrelationships, and to create representations in another form or at a higher level of abstraction. Source: IEEE.

A logic path in which the flow of control falls past the last statement of a program. A runaway path is considered a violation of structured coding principles.

A project oriented, redevelopment assessment and implementation work plan template that references required Ulrich-SRM steps into prepackaged solutions to address legacy application improvement, migration, integration and replacement requirements. Scenarios provide a means for organizations with little or no experience in systems redevelopment to rapidly deploy Ulrich-SRM on priority systems redevelopment projects.

An algebraic combination of counts or other scores to produce a numeric descriptive value of an application or the external components supporting that organization.

The property of a Copy member which allows its associated Copy statement to be retained during the restructuring process.

One or more statements terminated by a period followed by a space in the Procedure Division of a COBOL program.

See Subject Matter Expert.

The use of tools and techniques to facilitate the analysis, improvement, redesign and reuse of existing software systems to support changing business and technical information requirements.

A severely unstructured program or Section of code. It is called ''spaghetti code" because a diagram of the logic paths in the program resembles the Italian pasta.

A syntactically valid sequence of words or symbols beginning with a COBOL verb.

A method of analyzing a program by tracking and identifying program logic paths without executing the program. Static analysis shows how the program is organized and how the control flow is directed by the use of various verbs and constructs.

A defined activity within an Ulrich-SRM task that contains guidelines directing an analyst to produce one or more deliverables in pursuit of accomplishing the overall objectives set forth within that task. Steps contain two components. The first is a set of general guidelines indicating how to execute that step. The second component is a set of tool guidelines for one or more commercially available software products to assist in producing the deliverables or performing the general guidelines define with that step.

A family of coding techniques in which a program's control logic proceeds from a controlling procedure (paragraph) to a subordinate procedure (paragraph) and back. Use of structured coding techniques results in code that is easier to trace, understand and maintain.

A locally defined data element that is set and tested in a program and that controls the branching of logic flow through that program.

A high level classification of data that defines a group of entity types directly pertaining to a major function within the enterprise. Source: Information Engineering.

A high level diagram defining subject areas for an area of the business. Source: Information Engineering.

One who is knowledgeable in the functional or technical aspects of an application system or other area of study, such as redevelopment; also called a SME.

Data elements mapping to the same physical data, but having a different definition and a different data name. These are usually redefining data elements. Synonyms are usually valid redefinitions of data elements. They are needed for various reasons such as for reporting and computations.

Specific COBOL constructs or logical relationships among symbols independent of their function. Various static analysis products measure various types of Syntactic Patterns.

The process of significantly modifying or re-building application system (s) that essentially replaces portions or all of one or more existing systems through the use of software re-engineering technology.

1. A low level activity that begins and ends.

2. A collection of related steps within an Ulrich-SRM framework stage that contains objectives, entrance criteria, rolls/skills, inputs, tools support, deliverables, quality checks, metrics, exit criteria, and generic and tool-based guidelines.

The process of executing one or more programs in a system to verify that functional capability of that system meets the user requirements specified during a prior development or maintenance modification.

In a source program, a call to an external program or routine that does not return control to the calling program. Program termination will always occur. Also called non-returning Call.

A software product that supports one or more Ulrich-SRM tasks / steps. Tools are generally off the shelve, commercially available software products that assist with the analysis, upgrade, improvement or re-architecting of legacy applications.

(1) Derivation of requirements, analysis and design models resulting from an integrated combination of strategic business planning and formal development methodologies, such as Information Engineering.

(2) A family of design and coding methodologies in which a system or program development effort proceeds from a controlling procedure or structure to a subordinate procedure or structure. Use of these methodologies results in systems that are easier to understand and maintain.

A loop caused by a Go To or a Fall Through; that is, a loop caused by a permanent transfer of control rather than a temporary transfer such as a Perform.

An Ulrich-SRM stage that is a collection of tasks that augment various phases of the development cycle, using reverse engineering tools and techniques, to increase quality, reduce risk, enhance the scope, decrease delivery time and lower the costs of delivering replacement systems. Transformation tasks are model driven and result in a change to the existing technical, data and / or functional architecture.

An interpretation of an event that activates an operation in event modeling.

A Section or paragraph which is never executed because it cannot be reached by the flow of control logic through the program regardless of data values.

A statement which is never executed because it cannot be reached by the flow of control logic through the program regardless of data values.

A coding construct where a procedure exit (end of Perform range) is not reached when the exit of an invoking procedure is reached. An Unresolved Perform is caused by a Perform range violation and is considered a major violation of structured coding principles; also called Premature Exit.

A system, or group of related systems, being treated as a single unit of work for purposes of a given redevelopment project scenario. One common application of upgrade unit segmentation is for enterprise wide century date change projects.

The process of running selected input data through an original program and then running that same data through a program that has been modified through a Positioning task to ensure that the modified program has retained functional equivalency. The output data of both validation tests should be identical, barring expected differences such as date / time stamps or field size variations. Validation is also the name of the last task within the Ulrich-SRM Positioning stage.

The person with direct supervisory control over programmers and analysts responsible for maintaining the application (s) being redeveloped.

An expert in extracting business rules from legacy applications and transforming those rules into more understandable or reusable paradigms.

The Communications Specialist is an expert in the configuration and implementation of communications protocols, hardware and software. The Communications Specialist should have a detailed understanding of the specifications, versions, and compatibility of communications products. This understanding should enable the Communications Specialist to anticipate and evaluate communications trends and products.

· Research and gain experience with a wide variety of communications hardware and software products and communications protocols

· Anticipate and recognize communications trends

· Define client/server architectures which effectively implement client/server systems

· Install and implement client/server architectures according to specifications and plans

· Detailed knowledge of industry, vendor, and installation communications standards

· Practical experience configuring and implementing client/server systems

A subject matter expert in the totality of an existing application - including the data definitions, usage and file structure, the technical structure of the code, and the business rules and requirements which govern the functionality of the system. This person is generally the most senior person who directly maintains the application.

Coordinates the development and maintenance of architectures and models resulting from multiple projects or from different persons within one project. Normally an individual is responsible for model management on a corporate or divisional level, and for each project a team member is assigned this role.

· Coordinate and control model development, maintenance and support activities

· Arbitrate resolutions to inter model conflicts

· Develop and maintain business data/process stewardship role responsibilities and assignments

· Audit models to ensure their quality and integrity

· Ensure that each project information requirements will provide optimal benefits to the organization

· Coordinate information concerning existing systems and projects that may prove beneficial to an individual project

· See that the security and privacy of data is properly maintained

· Confidence and ability to interact with high-level managers as well as technical people such as database administrators

· Thorough understanding of the organization's architectures and business systems

· Knowledge of assessing the strategic value of information systems

· A clear understanding of data modeling diagrams and techniques

· Knowledge of how business requirements are translated into an information architecture

· Awareness of the limits of data and process modeling and automated information systems

· A good grasp of what the business does

Also known as Model Administrator

The data administrator or data base administrator (DBA) is the person responsible for designing new data structures and for enforcing corporate data standards when data structures are updated. Often, the data administrator has no direct control over data structures for legacy systems, which were created before corporate data standards were designated.

For more detail see:

The Database Administrator is responsible for the performance, integrity and physical security of the organization's data.

· Back up databases periodically

· Assist in data recovery, when required

· Maintain database performance by running database utilities

· Assist with performance tuning during design

· Set up databases

· Assist in database monitoring and tuning

· Assist in the redefinition of database objects

· Test performance during Construction

· Assist in moving the system into production

· Technical expertise in the target database

· Familiarity with established database standards, procedures and policies

· Capable of interacting effectively with Construction Team members

· Thorough understanding of the project model

Analyst skilled in reviewing and interpreting various views of legacy and target data structures to assess complexity, redundancy, inconsistency or other data migration requirements. Includes ability to perform data name rationalization, field & record size expansion and literal externalization.

Expert at reviewing legacy environments, based on Ulrich-SRM guidelines, and documenting system wide data flows in a data flow diagram.

The Data Modeling Expert ensures that the underlying data model for the project meets the business requirements in a cohesive fashion. The Data Modeling Expert reconciles discrepancies and identifies loose ends in the data model to be resolve.

· Extract rules about the business from discussions with users and from existing system documentation to create a data model

· Test validity of the data model with users

 

· Review model diagrams and reports for accuracy

· Present data modeling conflicts to users and assist in their resolution

· Ability to extract information about how the business really operates from discussions with team members and assemble it into a data model

· Thorough understanding of data modeling techniques

· General understanding of business activities

· Familiarity with tools used to perform data modeling

· Understands the limits of data modeling and automated information systems

Individual with knowledge of strategic functional information requirements of the enterprise. This includes current system / function decomposition, as well as an understanding of how the organization should be aligned from an ideal standpoint.

An expert at developing event models based on diagramming skills and real world and legacy systems analysis and interpretation.

An expert at developing function and process hierarchy, dependency and action diagrams as a component of the redevelopment process.

Senior management in responsible for setting strategy, reviewing IS plans, funding development efforts and selecting various approaches as presented by redevelopment team members.

Expertise at moving an application from one language type or level to another. This may include platform migration experience if it is required by the project.

Analyst with the ability to assess technical, functional and architectural analysis findings, from an environmental, data, process perspective, and determine counts and scores as dictated by a given Ulrich-SRM task.

An expert in determining middleware requirements and implementing those requirements as defined in the Ulrich-SRM Middleware Enabling task.

Coordinates the development and maintenance of architectures and models resulting from multiple projects or from different persons within one project. Normally an individual is responsible for model management on a corporate or divisional level, and for each project a team member is assigned this role.

· Coordinate and control model development, maintenance and support activities

· Arbitrate resolutions to inter model conflicts

· Develop and maintain business data/process stewardship role responsibilities and assignments

· Audit models to ensure their quality and integrity

· Ensure that each project information requirements will provide optimal benefits to the organization

· Coordinate information concerning existing systems and projects that may prove beneficial to an individual project

· See that the security and privacy of data is properly maintained

· Confidence and ability to interact with high-level managers as well as technical people such as database administrators

· Thorough understanding of the organization's architectures and business systems

· Knowledge of assessing the strategic value of information systems

· A clear understanding of data modeling diagrams and techniques

· Knowledge of how business requirements are translated into an information architecture

· Awareness of the limits of data and process modeling and automated information systems

· A good grasp of what the business does

Ability to assess, migrate, expand and purify physical data structures, including tool expertise. Specific knowledge is typically required to deal with homegrown or other formalized data structures, as well as traditional file structures based on the systems being impacted by a given project.

The Project Manager is the person responsible for the project with regard to time, budget and quality. The Project Manager may be responsible for one or more projects. For small projects where only a small number of people are involved, the project manager might also be team leader who is directly working with the team members.

· Constant management of the project scope throughout the project

· A critical responsibility of the Project Manager is the selection, development and management of an effective team and allocating team members to the tasks

· Day to day responsibility for running the project

· Participate in project activities

· Coordinate activities of sub-teams

· Ensure that the Documentation Specialist is provided clear and correct information about the system

· Ensure the project plan is adhered to

· Report progress to management

· Smooth out problems encountered by team members and make important project decisions

· Ability to manage and coordinate the project activities

· General knowledge of the business area involved

· General knowledge of the technical issues related to the development of the system

· Ability to gain the confidence of the Executive Owner and the respect of subordinate personnel

· Overall knowledge of tasks to be done and techniques to be used

An expert with the ability to assess code improvement requirements and implement those requirements based on specific Positioning requirements. Skills include flaw analysis and removal, restructuring, program level design improvement, code slicing techniques and code reconciliation techniques.

Ability to, either manually or using interactive analysis tools, examine legacy code structures, delineate logic into invocation / condition / imperative structures, determine intent of a rule structure, extract rules for further analysis, categorize rules based on data usage, dialog flow or event relationships, and transform rules for reuse in target models.

Analyst skilled with systems redevelopment planning and implementation abilities as required by a given Ulrich-SRM scenario. The redevelopment expert must have a good working knowledge of the principals driving the overall redevelopment process and be prepared to veer from Ulrich-SRM guidelines as required by a given project, while still adhering to the underlying principals set forth within Ulrich-SRM.

Controls overall use of the repository (encyclopedia) and maintains the repository environment. The repository might be the central corporate repository or a project repository. Normally different persons are responsible for these repositories, sometimes called the Central Repository Manager and the Project Repository Manager.

· Establishes and enforces policies, procedures, and standards regarding use of the repository

· Authorizes use of the repository to the various development teams

· Makes sure that appropriate repository expertise exists within the organization

· Facilitates in the sharing of business model constructs, where appropriate

· Reviews models for compliance to policies, standards, and procedures

· Strong technical understanding of the repository's capabilities and limitations

· Strong data modeling background

· Strong organizational skills to ensure proper coordination and operation of the facility

· The ability to resolve conflicts between different groups of Repository users

An expert with the ability to assess long term information requirements and work with senior management to determine a best strategy, based on the information at hand, to redevelop one or more applications to achieve strategic information objectives.

Has the ability and security clearance to access, as needed by a given task, production source components required for that task. Also has ability and clearance to install and test software tools as required by tool section of each task.

Knowledge of functional information requirements for a target systems environment and the ability to specify those requirements in some way that allows implementors to formally depict analysis and design models for the target system.

The Telecommunications Specialist is an expert in the configuration and implementation of communications protocols, hardware and software. The Telecommunications Specialist should have a detailed understanding of the specifications, versions, and compatibility of communications products. This understanding should enable the Telecommunications Specialist to anticipate and evaluate communications trends and products.

· Research and gain experience with a wide variety of communications hardware and software products and communications protocols

· Anticipate and recognize communications trends

· Define host, client and server architectures which effectively implement client/server systems

· Install and implement host, client and server architectures according to specifications and plans

· Detailed knowledge of industry, vendor, and installation communications standards

· Practical experience configuring and implementing host, client and server systems

Analyst with knowledge of testing tools and techniques including ability to create low volume / high degree of coverage test data suites for validation and system testing.

User or user representative with ability and authority to specify, review and approve short term and long term system requirements.