Good morning. 
I'm Jim Travis;
I'm the Division Director
for the Operational Support System
or NETOPS division.
I use the term
"operational support systems"
because as we move forward
in figuring out the best way
to manage and operate
our capabilities,
we ought to use
industry standard terms,
which is an operational
support system.
And I represent the kind of the
cutting edge of where [indistinct]
and other the senior leaders
within DISA try to figure out
how do we actually bring together
the various components
of the old transport
and compute world
into one integrated system.
Those were great solutions
in their time
but as the industry
has moved forward,
DISA has found it important
to begin blurring the lines
between the compute and the transport
and where that comes into effect
is in the 
operations support system
and I'll be talking about that
a little bit later in the presentation.
So first of all,
what's my mission?
My mission is to provide
operation support system solutions
for DISA's command and control
information sharing capabilities.
So what does that help us do?
It helps us to find ways to provide
the capabilities we need
better, cheaper, faster.
Now, we're a disbursed division.
We were put together out
of the components of the old
Program Executive Office
Of Mission Assurance,
Enterprise Services Directorate
and Network Services.
And as such, you can see
I have folks here at Fort Meade,
we have a whole team of people
down in Montgomery, Alabama
at Günter Annex
and a small team of people
that we are growing out
at the Denver location,
and together we provide a significant
footprint that helps us blur those lines.
The drivers that we have --
we have two sets of drivers.
The first set
is acquisition drivers.
First of all, we have
to make sure that the stuff
we already have
continues to work.
There are too many customers
that are dependent upon us
for us to abandon
those kind of things.
It's a significant component of work
that supports the sustainment
of the existing transport computer
and application infrastructure
in the operational support
system component.
I don't provide
the apps themselves;
I provide the operations support
systems that enables us to manage,
sustain and engineer them.
The next thing is, we start
looking at how do we provide
the same operative support
system capabilities for new stuff?
So, for instance, within mobility,
within Cloud,
within the other gaps
or inter-user experience,
how do we provide better capabilities
to ensure that when
DISA deploys a capability,
it also deploys
an appropriate capability that could
be used to operate and sustain it.
If you don't plan it ahead of time,
you'll find your grafting on
and operating in a management
capability after it's deployed
or you've deployed it
in a way that creates new tools,
new solutions which requires
more people to provide work.
We'd like to be able to,
for instance, save money,
we define ways that the
existing things we already own,
reuse them or take advantage
of capacities and capabilities
we already have, and extending them
to the new things we're adding.
And that way we can help--
I accomplish all of the objectives
that all of us are trying to accomplish.
We're also trying
to do the JIE JRSS convergence.
If we're not careful,
we will deploy
a whole new operational
support system
that duplicates the ones
we already have.
If we have to do that because
the programs have already begun,
yes, we'll do that, but we'll do it
with what I call deliberate haste.
A hasty aspect, sometimes
you have to keep going with
what you're doing because you don't
want to break existing programs.
We ought to do that
deliberately.
With a deliberate plan to at some
point bring those convergent--
those capabilities back
and converge into a unified system.
And finally, we want
to sync the DOD DCO
defense cyber ops
tools and processes.
The reason why I mention that,
is because I think as we go forward,
more and more of the things
we do at the very simple level
will be automated.
And the stuff that will be hard
will be the cyber ops,
the analytics and that's where
we're going to have to find a way
to make sure that as we do those
things, we synchronize those,
because remember, just
deploying a tool isn't enough.
If you don't deploy it
with the change processes
or if you created something new,
it will be unfamiliar to the people
who are going to receive it and they
may reject it because it's new.
So we have to work
not just with tools,
but with processes
that are employed in deploying them.
Now, for those of you
who don't know
what an operational support system
is, because it's bit esoteric,
I have got this graphic
here that shows it
and in the bottom right-hand corner
of your screen,
you will see the stack
of an operational support system.
It begins with
element management.
Element management sounds like
a fancy engineering term --
it just means you have to first of all
talk to all the boxes within DISA;
every service, every software,
every piece of deployment,
for it to be managed,
has to be communicated with.
And so it's an element of expertise
that is involved in communicating.
So in that sense, my particular
division and the tools we deploy
for the people of this agency talk
to everything that DISA owns.
The next level is
infrastructure management.
Infrastructure management takes
that information that's flowing in
through the various
telemetry fabrics we deploy
and provides useful information
about the operating status
of that particular infrastructure.
Elements make up
an infrastructure.
But an infrastructure
does not exist for the fact
that we like networks
and they're cool
to look at and talk about.
Infrastructures exist to
provide services of some kind.
In this case, we have to provide
those services like ITSM ticketing,
the whole global
information management,
the network visualization,
the performance monitoring.
There's a level of effort required
to be able to pull that off.
Obviously, sitting on top of it
is another layer of things
on decision support
that enables us to figure out
what we should be doing next,
are there--
kind of customers,
in business support,
business support management
is how we provision.
How do we do service
quality management?
Service level management?
All those types of things,
and finally, policy management.
There are many aspects of policy
that can and should be automated
and the operations support
system provides the vehicle
where we can put
those things in place.
So as you can see,
an operational support system
while sounding like
a very narrow term,
actually has a very wide scope
and explains why we would have
software-defined networking
that talked about
as part of this presentation,
which we'll make
more clear later.
Obviously the operating support system
operates on top of the equipment
that is deployed by the Information--
Implementation and Sustainment Center
that Mr. Bennett spoke about
earlier.
Both the Infrastructure Executive
and the Services Directorate,
both of them operate
the wide area networks,
the commercial services,
the virtual storage
and the virtual servers
and other capabilities.
So that becomes a layer
that we kind of sit on top of
that helps make it provide
the useful information.
Obviously on top, we have
the DISA operations directorate
and the various local
and disbursed headquarters.
So in that case we kind of
are sandwiched between
the operators 
and the sustainers.
We obviously receive requirements
from DISA directors,
but more importantly,
we receive requirements
for these capabilities from
organizations outside of DISA
through our mission partner
engagement and our--
and the group that Terry Carpenter
runs on requirements.
So that we make sure that
as DISA deploys new capabilities,
we make sure they have
the operational support systems
that are necessary
to make those work
and that the provision
of those OSS solutions
are built into the pricing
of that service.
In that way we have a
synergistic effect that enables us
to accomplish the things
that need to be accomplished.
As you can see, our division,
we design it, we deploy it,
we sustain it and provide the
tier three or expert service desk
for those of you who are
familiar with that term
and finally when it's finished
we'll decommission or sunset it.
But collectively the team
of people that we have
works to accomplish all this.
Now, what's important
to remember is that
given where we fit
into the overall architecture here,
we are a very 
collaborative division.
We have to reach out and
communicate with lots of people,
because everybody at DISA is--
that's involved in the compute,
transport, and applications
directorate has to work with us,
so we have an awful lot of work
that requires cooperation
and collaboration to pull off
what we need to provide.
Just as I talked about
acquisition drivers two slides ago,
I also have some technology
drivers that are in the industry
that we are desperately
trying to take advantage of.
I'll start with the
upper right-hand corner
and the term "convergence."
What do I mean by convergence?
First of all, those of you
who build equipment,
the network elements, you're building
more and more intelligence
into those devices,
and they can operate and sustain
and often maybe
even repair themselves
when they're operating
part a system together.
So we need to be sure that when we
acquire the next generations of equipment,
we carefully consider
how the manufacturers
have already created
within those devices
the ability to manage themselves,
to operate themselves,
to pull out some of the--
the unique labor that maybe DISA
used to provide in managing it.
The second thing we're seeing
in convergence is the old solution
was to go out for DISA to go out
and purchase best of breed
and all the various
tools that we have.
And that was a good model.
But what's happened is we notice
that many of these were provided
by very innovative small businesses
and they were at some point
bought out by the larger businesses
who have integrated those things
into a unified 
suite of equipment.
We have several of those
that we have purchased,
and as each company
has purchased those capabilities,
they've provided integration between
those modules that we used to do
in the old network
services directorate
where many of my workers
came from.
And as a result,
we have smarter stuff
than we used to have
with integration built in.
So we have to figure out a way to
take advantage of these good things
that industry is doing,
and it continues to do,
because I hear great new stories
from you all the time,
we're looking forward to taking
advantage of many those solutions.
The next one is enterprise,
and by enterprise,
what I'm referring to, is that there
is a desire within the department
to save money, which means
efficiencies or be more effective
for the capabilities
that we have.
And also means that we maybe
don't need to keep buying
the same thing 
over and over again.
Maybe the solution
that I deploy for ticketing
might be sufficient 
for the department.
Maybe the performance monitoring
that the Army would use,
we can bring that in and
incorporate it into a unified solution.
The point is that we don't
necessarily need to have
multiple instantiations of
essentially the similar capability.
From my perspective what it means
is that when I acquire a tool,
I acquire a tool first of all making sure
it can meet DISA's requirement,
but can it also scale
to be something I can offer
as an operational support
systems solution
in service where
I would provide the service
and some other military department
would consume it.
We already have several cases
where we're in fact doing that,
where we provide
visualization tools,
the compute group does an awful lot
of work for defense health activity
on solutions that we have
created that they consume.
In other cases we should
be able to scale potentially
to the entire department
and there are some efforts
that Mr. Halverson
and General Lynn are leading
that may cause those things
to come into effect some day.
Bottom line is, I've got to make
sure that when we buy something,
it can scale ultimately
to the entire department
or if we don't, we should know
that so leadership can make
a good decision about a tool,
because sometimes the ability
to scale to the full DOD
might come at an expense
that was not a good value
as we consider value-based
propositions in acquiring.
The next point that we want to
include of, is what I call DEV ops.
Now, what is DEV ops?
It means a lot of things
to a lot of people.
What it means to me
is that the operator,
the engineer
who engineers new solutions,
the cyber team who will
make sure that it's assured
and the development team,
works as a group,
on what I would call smaller scale
that would continue to grow
with more and more
capability over time.
Too often we get
to the end of the line
and find out we
have to STIG something --
I want to build it STIG’ed.
When I deploy a solution
to operations,
there's a new process required and
nobody thought about ahead of time
or didn't adequately think
or didn't own the tool.
We need to find a way to grow
those capabilities over time,
in conjunction with our users
and our operators
so that in the end, consumers--
people who consume
the services that I deliver
are ready for it
and are able to use it
without extra effort.
So DEV ops 
integrates that thing.
So those of you who have
those kind of solutions,
we'd be interested in hearing from you
on how I might incorporate them
into my existing processes.
Now, mobility.
Now, when I mean mobility,
I don't mean,
I have anything to do
with Miss Rice's solutions
on providing you phones.
What I'm talking about is the appification
of everything that we do.
We recently deployed a new tool,
and it really provides a great job.
But the-- one of the executives
who saw it said:
I was writing that kind of code
when I was in college 20 years ago.
And his point was: We should have
looked for ways to make it simpler.
If you think about it,
when you take an app,
you don't go to classes
on apps, normally.
You just take it out of the box,
you start using it.
So when I talk about appification,
that's what I'm talking to.
Take an example
out of my own life.
I referee soccer and I
was doing a regional final.
We looked in our weather apps
and saw there was
a big nasty storm coming,
so we were in a rush
to get the game going.
Sure enough we got it off
and about five minutes in,
boom, lightning hit and we all
went to our safe places.
But we looked at the map and said,
hmm, where these storms are moving
there's about a 40 or 50 minute gap
going to open, we can play again.
So we stayed.
Sure enough, right on time,
the storm cleared out,
we started playing, 
got through half time,
got most of the game finished.
Sure enough, 
lightning happened again.
The principal team
was down four to nothing
said, hmm, we're not going
to get this game in tonight.
I think it's time for us,
we were beat,
they passed out trophies 
and went home.
Where were the weather
persons in that conversation?
There weren't any.
So how about appification?
I talk about taking the
capabilities we have
and finding ways to eliminate
some of the middle persons
who provide useful data today,
but in an appified world
aren't as needed in that world
and become freed up
to do other
high value added solutions,
We're not talking about
getting rid of people.
We are talking about
finding ways to automate
everything but leadership.
And if we automate everything
but leadership we free up people
to do more higher
value added things,
those who have invested
in themselves
and so we as an agency
have to invest in our people
to make sure that we continue
as we automate stuff
that it is currently done by humans,
that we have places for everybody.
So part of us is concerned
with human capital relations.
Now, last--
and here is Cloud.
Obviously I'm deploying stuff in the
Cloud solutions that DISA provides.
Because of the unbelievably high
availability requirements we have,
it's very imprudent
for us to deploy
the operational support system,
most of it, into a commercial Cloud.
But part of what I'm doing
is taking a longer term look
at how I would use Cloud,
because frankly
when it comes to the
operational support systems,
especially for privileged management
and those kind of solutions,
I need to design stuff
that never fails.
I'm gonna borrow a term from
the Department of Interior --
we should be designing some parts
of the operational support system
against a hundred year outage.
This stuff should never fail.
If it comes to access management,
we have to look at high availability
in ways we've not normally
thought about availability.
Because there are some things
that can just never not work.
And when I--
times we've had things fail,
those critical things,
it really negatively affects
and fortunately disasters didn't happen
but we have to look at --
with our mission partners
have to look for unbelievably high,
reliable solutions --
not for everything,
but for the critical components,
we need to think about it again.
So those are my
technology drivers.
I mentioned earlier that we have a lot
of stuff we have to keep track of.
I have five lines of effort.
The first one, I show this slide
with lots of small words on it.
Only to point out, we are
responsible for lots of things.
There's 40 or 45 different solutions
depending how you count them.
The bottom line is, I have
to sustain the current ones;
I cannot let them drop.
At the same time, I have my information
technology services management,
which is a really cool initiative
with some great mission partners
we have now, but we don't want
to deploy too many ticketing solutions.
I've got several and if I'm
not careful we'll have more.
I think the technology
has gotten to the point
where with smart requirements
and smart industry partnerships,
we might be able to do it
with fewer.
The next one is the
joint operating environment.
You may remember me
mention a few moments ago
about the desire to scale.
At some point the question
is going to be asked:
Why do we need so many different
parts of the Defense Department
developing operational
support systems and solutions
and operating all of these things?
You look at what industry done,
the continual consolidation
of data centers, of transport,
of networks 
into single organizations.
I believe frankly that DISA
has some roles in helping make
that happen because in the end
we need to make sure we have
plenty of people to--
remember, when I was a cadet
at West Point, talking about close
with and destroy the enemy
by fire and maneuver.
Frankly, we need to make sure we have
as many people that we have engaged
and be able to apply force
against our enemies
and let people like us here in DISA
to help do a better job
of freeing up labor to go do
those kind of things.
Obviously we have things
to deal with in some areas
of the national senior leadership
and to transform the DODIN OSS.
I have to do all these things
at the same time,
which makes for a very complicated
operating environment
for those within the division.
So, how am I going
to get there?
What we are doing is,
we have taken,
have created an operational
to be [indistinct].
It's a design, excuse me,
of which the green Cloud represents
and Mr. Jake Marcellus
who's upstairs with me
is helping me design that.
Trying to figure out
what should the future look like.
But in the bottom right-hand corner--
bottom left hand corner,
the black box,
is the add as inventory.
We've got to find a way
to take that future vision,
the current system --
so what we have done
is we have created a series
of integrated process teams
that are analyzing
those various components.
They are trying to figure out
how to do this,
because we're creating operating
relationships that don't exist.
Obviously the outcome of that
is going to be a baseline
which consists of gaps
and duplications.
What we are going to do,
there is an Executive Council
that we've reformed,
which includes all the key directorates
who will then help me create an
operational solutions evolution plan.
This takes some time.
But that council will
help us figure that out.
So, let's get to the
acquisition opportunities
that we're going to talk about
here now.
Now, you look at the dates,
I asked you to be aware
that what we are doing,
is that we are proceeding
with a very deliberate effort
to determine
where those
points of consolidation are.
But, we are also looking
for quick wins,
and so in the places--
so just because I show a date,
that's the date that I will have
something on the street.
But where we can find
opportunities sooner,
we intend to take care
of them immediately.
And the-- my big challenge
obviously is that
because we're bringing
to the compute and transport,
they exist with different
funding streams,
different acquisition teams.
And so just bringing those
together is not just a case
of writing a bigger check
for a solution.
It requires serious thought
by the department
on how it wants to pay
for these solutions in the future.
The first one, we have some
great partners helping us out
with our ITSM solutions,
but we also want to take a chance
to let other-- because other new
solutions are being developed
in that space
and we want to make sure
that those vendors
have an opportunity
in a competitive-based acquisition
to do so.
What we're talking about here is
replacing the current ITSM solutions,
we look at a full
and open competition,
we expect this to be
a single award contract
where we would have
some innovative ideas here,
which would include that we would
only pay for the delivered capability
when it's delivered
and it's passed the test
and has proven to be better
than what we're deploying now.
We need to do a better job of
making sure we create something
that is there is incentive
for vendors to be efficient
with their pricing,
to be effective with the solutions
as measured by the people
who actually consume them.
So that represents what
our ITSM one would be.
The next one is the
transport compute convergence.
Now, this particular case,
we are working to make sure
we've got the right set
of capabilities in place,
and we don't know at this point
exactly how those
are going to be allocated.
Now I can show you
a chart upstairs
which shows you
the 47 different tools we have
and how they're allocated
against various sectors.
Frankly, we should
have fewer of them.
And so as we analyze that market
and figure out what’s the best way,
we also have to determine what is
the right grouping of performance.
Do I define it very narrowly
or do I define it very broadly?
So, for instance, if I put all the
performance monitoring tools together,
do I put all the visualization
requirements together,
or would I make visualization
part of the ITSM,
or do I say, no,
I'm going to give that all
to Chris Paskowski 
over in the Analytics Division
to create an integrated solution
for all of us.
The bottom line is, we are looking--
if we have two tools
to do the exact same function,
the question is why.
And we would expect them
to figure that out competitively
with people to be able
to once again, fixed price,
single award for the individual
service that we're buying.
It would be installed and run on
the DISA particular environment,
because I mentioned earlier
these things must be protected.
The implications of a successful
attack are pretty severe.
So we would expect to see
that happening in that way.
Finally, our engineering
and installation services,
we have to plan a long time in advance
for how we acquire the labor
that does the particular work.
I'm happy to announce that
one of the previous opportunities
was won over the weekend Friday
by a company called FASA,
$100,000,000 award.
They'll help me with taking
the engineered solutions
and deploying them
into the infrastructure,
as well as keeping track
of vendors' patches,
releases and deploying them
into the service.
So that particular contract
has provided great value,
and we have a new vendor
who was just taken onboard
to help us with that.
At this particular point,
I'd like to bring Angelo Curcio up,
and he'll talk about
software-defined networking.
The question is, why would
software-defined networking
be part of a conversation
on the operating support system?
And the answer is, because for a
software-defined network to work
it's got to use, and right on top
of the operational support system
and frankly to integrate in
with the tools we already have,
otherwise we'll simply create
another OSS layer
that will create interoperability
gaps and challenges.
And with that I'll introduce
Angelo Curcio,
the Division Chief
for the Net Services Division.
( applause )
- Good morning, everybody.
Just have a few quick minutes here to
talk about software-defined networking,
and where DISA has been
and where we're planning to go.
As many of you know,
software-defined networking
is one of the latest hot topics,
the latest buzzword.
One of the challenges we have
from a DISA perspective
is to find the points of SDN
that will work for us
in our DODIN environment
and the OSS environment
that make perfect sense for us
and meet our stringent requirements.
So with that said,
to level set with everybody,
SDN in a general sense,
is where we move the intelligence
of the networking elements
up into a central control.
Basically the control plane
of all the network elements
moving up to a central controller
and this central controller
will have a view
of the whole network.
It gets into a vision sort of
like what Jim Travis was talking --
we can see everything
on the network.
Now, what you do there then
is you have a central place
where you have a new
attack vector, so to say.
So we have to work with security concerns
with software-defined networking,
as well as incorporate
the efficiencies it provides.
With that being said, DISA
has been doing some work
over the last year and a half or so
and we've done some
proof of concepts
in our lab environment
which showed
very good promising results,
and we're planning on leveraging
on those results with an acquisition.
And what you see
here on the slides,
looking at the FY ‘17 time frame in
the summertime, to put out an RFP.
And what we're probably
going to look at
and I can't commit to anything now
because we're still doing the engineering
and the understanding
of the requirements,
is probably to do an automatic provisioning
of services over our network,
where you'd have
no operators involved,
the SDN controller does it all,
talks to different vendor equipment
and makes the services
activated on the network.
And also, inter-data center
communications,
where we can dynamically provision
flows between data centers
and also move VM instances
from one data center
to another automatically.
You heard earlier from our
Director and Vice Director
about the need to be agile
and set up new networks on the dime,
take them down
and respond to cyber attacks.
SDN has a great amount
of potential to do that
for the Department of Defense,
and that is our big burden.
We're going to be doing this
in a collaborative environment.
Obviously we're going
to be integrating
with the 
operational support system.
We're going to be working with
our DOD network engineers,
we're going to be building
upon our current MPLS core
and our optical network,
so we're not going to break anything,
but we are going to slowly
integrate SDN into our network
and make sure it works well.
It's hardened, it also has
to be a scaleable solution,
has to be able to, you know,
move with the speed of customers.
And also be very
secure and hardened.
So that's the big burden.
Again, this is just
a very sneak peek
on where DISA is moving
with SDN.
Obviously it will be, like I said,
very closely connected
to what Jim is doing
on his OSS evolution,
it's going to be closely connected
with the DODIN network evolution
and closely connected with where
the data centers move
as they move towards virtualization
and network function virtualization
which I also should mention.
SDN is not network function
virtualization, NFV, per se
but it will be a very complementary
technology to work with NFV.
So both of those in unison,
as we move to the virtualized environment,
SDN gives us the opportunity
to have an unprecedented view
of our whole entire network,
the whole DODIN
and to be able to make changes
on the dime real quick,
to respond to adversary problems,
and respond to new services
that our customers require.
So with that being said, a lot of
exciting things going on with SDN,
but be on the lookout
for an RFP starting next year.
We may put out an RFI;
we're still working out
the acquisition strategy.
Not quite sure
how we're going to do that,
but we do want this to be an
industry collaborative environment.
So we'll be collaborating
with you guys as well,
as well as our mission partners,
as well as academia.
This is so fast moving, SDN,
that we want to do a collaborative.
We at DISA
don't have all the answers
so we will depend on you guys
quite a bit.
