# TOP-LEVEL DESIGN PROCESSES

A top-level design is one of the outcomes of analyzing your state's
existing systems, CVISN project objectives, guiding principles, existing
and planned business processes, and intended operational changes.
Typically, by the time a top-level design is completed, you should have
captured these components:

-   User requirements

-   System requirements

-   Allocation of requirements to major system elements

-   High-level interface specification

Starting before the CVISN Scope Workshop, states are encouraged to use a
particular process for starting with the CVISN Architecture and
tailoring it to produce a top-level design. The process is based on
defining operational scenarios that improve business processes. States
overlay their business processes with the objectives, operational
concepts, and requirements for the use of open standards specified in
the CVISN Architecture. The results reflect a re-engineering of the
business processes that improve the existing system.

![](media/image3.wmf)

Figure 5‑1. Top-Level Design Steps

Even though the steps are shown as sequential, the process actually
involves a great deal of feedback and iteration. Throughout the process,
participants should identify issues, actions and decisions. Each state
will publish the final results as a State CVISN Design Description.
Appendix B presents a candidate format for such a document.

The process of defining operational scenarios involves thinking about
what you do today, and how you want to improve those processes. In this
you are either reflecting the results of your completed business process
reengineering, or are accomplishing that reengineering. Typically, the
steps in business process reengineering include:

-   The organization asks itself:

> What do we do
>
> Why do we do what we do
>
> Why do we do it the way we do

-   The organization determines how to improve the basic business
    processes

-   The organization evaluates how technologies can be applied to help

The goal of reengineering is to improve the existing processes. The
improvement may be targeted towards such goals as reducing manual tasks,
focusing resources on problem areas, simplifying information flow,
reducing transaction cycle time, improving system response time,
improving the quality of information generated and received, removing
distance as a barrier to interaction, and others. Building on the
reengineering efforts that have already been accomplished in the CVISN
Model Deployment states, new states can benefit from lessons learned.

Before attending the Scope workshop, states should attempt to complete
steps 1 through 3 shown in Figure 5-1. There will be time in the
workshop to refine the initial drafts, but the workshop process will be
more valuable if preliminary versions of the state's templates are
completed as part of the pre-work.

The remainder of this chapter explains the process.

## Characterize Current System Design (Step 1)

In this step, you characterize your current system design. Chances are
that the CVISN project will involve some modifications to existing
(legacy) systems. Before you make decisions about what and how to change
anything, it is a good idea to be clear about how the existing systems
work.

Inventory each system that you imagine will be involved in CVISN Level 1
capabilities (see the Introductory Guide to CVISN, Reference 8 for a
reminder). By "inventory" we mean collect information to help you
understand what the system already does, who is responsible for it, what
it connects to, and how easy/hard it will be to modify it. The pre-work
for the Scope Workshop contains an inventory form that should be useful.
If you already have the inventory information summarized in some other
format, it is not necessary to transpose it onto the workshop pre-work
forms.

The systems about which information should be collected include at least
the products that handle IRP, IFTA Registration, IFTA Tax Processing,
Roadside Operations, Inspections, and other safety systems that connect
to MCMIS.

It may also be useful to illustrate the current design using the system
design template style explained in step 3. You can illustrate which
functions exchange information today by drawing lines to connect the
boxes. You will also illustrate some of the inventory information on the
network and computer template in step 3 (section 5.3).

## Identify New Operational Concepts (Step 2)

Before beginning this step, we recommend that you brainstorm the
top-level objectives for your CVISN project. Review your ITS/CVO
Business Plan. Review the definition of CVISN Level 1. Involve all
members of the project team and motor carrier representatives, and
construct a list of your project's objectives. If the list doesn't
include all the CVISN Level 1 capabilities, note a brief explanation.

In this step, identify where your current and planned operational
concepts and design are and are not compatible with CVISN. In this step,
you begin to make choices about what you are and are not going to do in
your CVISN project. If you have already evaluated your existing business
processes and made choices about re-engineering them, this step should
be fairly straightforward. If not, this step will help you start that
process.

![](media/image5.wmf)The tool for this step is the COACH Part 1. By
completing the "Commit Level" column in the tables in the COACH Part 1,
you will face the operational concepts and top-level design guidelines
for CVISN. Pay special attention to the items in the COACH Part 1,
Chapter 2, Guiding Principles, and the items in subsequent chapters that
are associated with CVISN Level 1. Disagreeing with those items may
indicate a fundamental disagreement with CVISN concepts.

Figure 5‑2. COACH Part 1

If you have a serious disagreement with CVISN concepts, then consult
your FMCSA Division Office or Service Center.

The entire CVISN project team should be involved in this step. Different
functional areas may have different reactions to some of the operational
concepts and top-level design guidance. During the process, the team
should air those differences, and work towards some sort of consensus.

The combination of your project objectives and the completed COACH Part
1 tables form an initial set of requirements for the project.

## Make Master Templates (Step 3)

In this step, you make two templates: a master state system design
template, and a network template. These templates reflect your initial
top-level design decisions. The templates show the major functions, how
those functions are allocated to computers, and what network
connectivity is envisioned to support system interactions. As you use
the templates in the succeeding steps, you will probably change them.
It's a good idea to keep one master copy of each template, so that you
don't lose any revisions. Early on, assign an "owner" for each template,
the person who will be responsible for maintaining the master. You might
want to do a "current systems" view and a "proposed systems" view of
each template, to show what you are planning to add.

### State System Design Template

The state system design template will be used to illustrate operational
scenarios. This diagram is the one that the CVISN Model Deployment
states found most useful for team communications. Everyone can see his
or her own functional area on this diagram. The template can be used in
many different ways, as you learned in the Understanding ITS/CVO
Technology Applications course (Reference 29). In the Scope workshop,
you'll use this template for illustrating both operational scenarios and
system interfaces.

Include all the major functions in your state that support CVO. There
should be exactly one box representing each major function. Start by
reviewing the generic template (Figure 5-3), and then tailor it to your
state. Recall your project objectives and the answers you gave when
completing the COACH Part 1 tables. Remove functions that don't relate
to your CVISN project. Add a box for each major function that is
missing.

The generic state system design template reflects the generic CVISN
state design. The CVISN System Design Description (Reference 7) explains
more about the generic design. The small LSI and LM boxes on the generic
state system design template refer to Legacy System Interfaces and
Legacy Modifications. The state chooses whether to modify the legacy
system (LM - legacy modification) to support EDI (and other new
functions and interfaces), or to create a Legacy System Interface (LSI)
to deal with the EDI-to-native form interface. Many CVISN Model
Deployment states are implementing a mix of LSIs and LMs.

In this template, it is not important to group the functions that are
handled within the same computer, nor to show how systems are connected
through networks. Those aspects of design will be illustrated on the
second template.

![](media/image1.wmf)

Figure 5‑3. Generic State System Design Template

### Network Template

The network template shows how your state allocates the major functions
to computers, and how those computers are connected using various kinds
of network technologies.

To make your master network template, review the generic network
template (Figure 5-4). Tailor the generic network template to your
state. Start by including all the computers and networks that support
the systems you included in your current systems inventory. Next, be
sure that the existing major functions on your system design template
are allocated to some computer on the network and design template. As
necessary, add computers and network components. If you don't know what
kind of computer or what networking technology you'll use, put in a
placeholder and note it as an open issue. The drawing will mature as you
work through the design process.

![](media/image2.wmf)

Figure 5‑4. Generic Network Template

This template is used to show network connections, as well as the
allocation of software products to computers. Proposed new computers and
network connections can be added. As you make decisions, show which
network protocols you've selected for each segment. The diagram can be
used to verify how two or more systems are connected physically, and
where network "translations" are needed. It can also show where
potential bottlenecks exist.

On the network template, each small box represents a computer system.
The state should show all the computer systems that support (or will
support) the CVISN project functions. List the major functions (software
applications) handled by that computer inside the box. Group the small
boxes into large boxes according to the state agency or facility that is
responsible for the computers. Show LANs and WANs as lines connecting
the computers.

We recommend that you adopt some convention for distinguishing between
existing and proposed computers and connections. For instance, you could
make existing computers white, and new ones shaded. You could show
existing connections as solid lines and new ones as dashed. Different
dashed line types could indicate different network protocols.

Every function box on your state system design template should be
allocated to some computer on this template. This includes each of the
individual LSI boxes. Often for credentials-related products, the LSIs
are small applications running on the same computer as the Credentialing
Interface. LMs are modifications to existing systems, and usually are
not shown as separately allocated functions on the network template.

## Define Key Level 1 Scenarios (Step 4)

When we say that the next step is to define key operational scenarios,
we mean that the state should describe how they intend that their
customers and the state, or the state and core infrastructure systems
should interact to accomplish key CVISN Level 1 functions. This is the
most difficult and time-consuming part of the top-level system design
process. **The following list represents key scenarios that are
representative of the major CVISN Level 1 capabilities.** A more
complete list of scenarios can be found in the CVISN Interoperability
Test Suite Package, Part 1, Test Specifications (Reference 37). If you
are implementing the complete set of CVISN Level 1 capabilities, then
you should define each of these scenarios.

-   Record inspections electronically and report them to SAFER and MCMIS

-   Query for a past inspection report

-   Maintain carrier and vehicle snapshots for intrastate operators

-   Query for a snapshot

-   Screen vehicles electronically at at least one weigh
    station/inspection site, using snapshots

-   Enroll carrier and vehicles for electronic screening

-   Accept and process electronic IRP credential applications for
    supplements (e.g., adding a vehicle to an existing account)
    (person-to-computer and computer-to-computer scenarios)

-   Accept and process electronic IRP renewal applications
    (person-to-computer and computer-to-computer scenarios)

-   Accept and process electronic IFTA credential applications for
    supplements (e.g., additional decals) (person-to-computer and
    computer-to-computer scenarios)

-   Accept and process electronic IFTA renewal applications
    (person-to-computer and computer-to-computer scenarios)

-   Accept and process electronic filing of and payment for IFTA
    quarterly tax returns (person-to-computer and computer-to-computer
    scenarios)

By the time a state is ready to define new operational scenarios, the
project team has already characterized their existing systems,
established project objectives, defined operational concepts and design
guidelines, and taken first cuts at the state system design template and
network template.

![](media/image1.wmf)In the workshop methodology, operational scenarios
are illustrated by overlaying information onto the state system design
template. The resulting diagram (Figure 5-5) is sometimes called a
"functional thread diagram." The diagram is augmented by text describing
the operational process.

Use the project objectives and COACH Part 1 checklists as reminders of
what your state intends to do. Assess options for implementing each
scenario. Begin to identify where you need to use open standards (e.g.,
for interactions with carriers). The COACH Part 4 (Reference 5) provides
a good overview of the CVISN interface specifications. For each legacy
system involved in a particular scenario, decide whether you will modify
the legacy product (LM) or construct a legacy system interface (LSI), or
both. Consider what customer base are you most interested in supporting
first for each scenario, and which option might be best for them. Assess
the difficulty of implementing various design options. Recall the
different approaches for evaluating alternatives (literature search,
seek expert judgment, trade study, simulation, competition, prototyping)
outlined in Module 2 of the Understanding ITS/CVO Technology
Applications course Reference 29). While it isn't necessary to complete
the process of evaluating alternatives at this stage, it must be done
sometime to reach a final top-level design.

The mechanics of defining key operational scenarios involve a methodical
step-by-step process. Work on one scenario at a time. For each scenario,
list the steps in the scenario, keeping in mind the operational and
design choices you've made. Use a copy of your state's CVISN system
design template to show what functions will interact to support the
operational scenario. Do this by drawing lines between boxes to show how
your state's systems, the carriers' systems, and the CVISN core
infrastructure will interact to support the operational scenario. Be
sure to connect the right segments of each box. For instance, if you are
going to construct an LSI, then connect to the LSI. Label the lines with
the steps in the operational scenario. Use arrowheads to indicate flow
direction. We call this drawing a "functional thread diagram."

Review the network template to see what new or enhanced processing power
or connectivity is needed to support the interactions. As needed, add
computers or connections to the network diagram. If a new process is
being added to an existing computer, list the software application in
that computer's box. Repeat the process until you have worked out each
scenario. Always start with a clean, updated copy of each template.

The CVISN Level 1 scenarios listed earlier focus on successful
interactions. As part of the process of defining how you want your
revised systems to work, you must also consider error conditions and
exceptions. One approach is to look at the basic scenario and ask "what
if" questions (e.g., what if the connection between the carrier's system
and the state's system drops out in the middle of a transmission?). You
need to capture the reactions you want the system to make to error
conditions and exceptions. The method you use may be to document more
scenarios, or to describe in words how the system should handle errors
and exceptions.

As you work on the scenarios, you may need to update the preliminary
templates, by adding, removing, or renaming boxes on the templates, by
moving applications from one computer to another, and/or by changing the
network connections. Update the master and use the revised templates for
subsequent scenarios. Revisit the scenarios you have already completed,
and see if updates are needed. As you work on each scenario, you should
identify issues that must be addressed to implement the scenario, or to
complete the scenario definition. Keep track of decisions you still need
to make, and which ones you have already made. The process of defining
operational scenarios is iterative; don't expect to get any of them
exactly right the first time. After you have completed all the
functional thread diagrams, review them as a group, and make changes as
needed to make the operational processes consistent. By using a
systematic approach you will be testing the top-level design.

The Understanding ITS/CVO Technology Applications course (Reference 29)
introduced the use of functional thread diagrams, and contains several
examples. Several other examples are also shown in the Scope workshop
workbook (Reference 34), and the CVISN Guides to Safety Information
Exchange, Credentials Administration, and Electronic Screening
(References 9-11).

## Summarize System Interfaces (Step 5)

After completing the functional thread diagrams, it is possible to
summarize system interfaces. This is illustrated in two ways. First,
make three copies of the state CVISN system design template, one for
"Carrier-Related Interfaces", another "Interfaces within the State", and
a third "State Interfaces with CVISN Core Infrastructure." See Figure
5-6.

![](media/image1.wmf)

Figure 5‑6 Summarize Interfaces Using the State System Design Template

Review the comparable figures for the generic state design in the *CVISN
System Design Description*, Chapter 4, Putting It All Together
(Reference 7). Next, review each of your state's functional thread
diagrams from step 4 of this top-level design process and draw lines
connecting boxes on the appropriate interface diagram. Once you have
connected two boxes because of one functional flow, you don't have to
add another line to the interface diagram. Instead, label the line with
the interface standard(s) you intend to use between those two boxes. For
instance, the X12 TS 286 is the interface standard for credentials
exchanges between the carrier and the state. As with the functional
thread diagrams, on each of these system design interface summary
drawings, indicate whether legacy system interfaces (LSIs) or legacy
modifications (LMs), or both, will be required for the functions being
supported. The filled-in state system design templates are your
top-level interface diagrams.

Then, reflect the operational scenarios in your network diagram. Show
which computers will connect, and what networks and protocols will
support those connections. The filled-in network template is your
top-level physical system design. See Figure 5-7.

![](media/image2.wmf)

Figure 5‑7. Physical System Design

## Summarize System Changes (Step 6)

The final step of the top-level design process is to summarize the
changes you expect to make to existing products and to describe new
products required. In this step you should re-evaluate all that you have
done so far and make sure that it is technically sensible. As part of
that process, ask yourself these kinds of questions:

-   Is it clear which design element is responsible for each aspect of
    each operational scenario? If not, are all open questions captured
    on the action list?

-   Is the system partitioned into manageable elements? (Reference 35)

```{=html}
<!-- -->
```
-   Are the elements as independent as possible? (low coupling)

```{=html}
<!-- -->
```
-   Are there any unnecessary relationships?

-   Is the number of necessary relationships as small as possible?

```{=html}
<!-- -->
```
-   Does each element carry out a single function? (high cohesion)

```{=html}
<!-- -->
```
-   Is any computer likely to be overloaded?

-   Are there any communications bottlenecks?

-   Should there be any redundant elements to assure that the system
    will be available to users as needed?

-   If new requirements or new technologies emerge, will it be possible
    to modify the design without starting over?

-   Are proprietary components used where standard components would
    suffice?

-   Is the cost associated with this design within your available
    resources?

-   Is the system testable?

In this step, you should identify the scope of the system
changes/additions needed to become (more) compatible with CVISN to
support the operational scenarios. As you assess the scope of the
changes or additions, consider issues such as connectivity, interfaces,
system capacity, data compatibility, process/policy changes,
institutional barriers, cost, etc. Consider how to test the scenarios
and the system, and how you will transition from the current design to
the final design.

There are three primary aspects of the technical changes:

-   Software products and interfaces between them

-   Computers

-   Networks

For roadside electronic screening, other site improvements that don't
fall into these categories may also be required.

One way to summarize the changes is to make a descriptive list. The
now-familiar templates and various uses of them also show summaries.
Another way is to make a simple list and estimate whether the
change/addition is Small, Medium, or Large.

Regardless of how the summary is shown, it is the beginning of a task
list that can be used to generate a Work Breakdown Structure. Refer to
the CVISN Guide to Program and Project Planning (Reference 43) and the
materials for the ITS/CVO Technical Project Management for Non-Technical
Managers training course (Reference 44) for further information about
Work Breakdown Structures.

The process of summarizing changes should include these steps:

-   Identify which software products will be changed and what new ones
    will be added to support the operational scenarios.

-   Identify which computers will be upgraded and what new computers
    will be added to support the new or changed products.

-   Identify which networks will be upgraded and what new connectivity
    is required to support the operational scenarios.

-   Identify system test requirements.

## Summary

The process described in this chapter was used by the CVISN Model
Deployment states. It is the process we will use at the CVISN Scope
Workshop. The workshop is intended to be both a process learning
experience and a productive series of sessions that help you start
defining your top-level design. When the project team returns home, the
process should continue until the design is complete.

The development process should also include a review of the top-level
design. Reviewers should include the conformance assessment team (COAT),
the project team, state information technology experts, and system
users. The COAT should check that the design conforms with the CVISN
architecture and standards. The project team should check that the
design fulfills the project requirements. The state information
technology (IT) experts should check that the design meets IT guidelines
for the state and is consistent with related projects. The users should
verify that the design will improve their work environment and support
operational requirements.

This Page Intentionally Blank