Modular Design in Comprehensive Child Welfare Information Systems (CCWISs)

Modular Design in Comprehensive Child Welfare Information Systems (CCWISs)


>>Elizabeth: Welcome to the Child Welfare
Information Technology Systems Managers and Staff Webinar Series, brought to you on behalf
of the Health and Human Services Administration for Children and Family Children’s Bureau,
and presented by ICF International. Today’s Webinar is entitled CWIS and Modular Design. I’m Elizabeth Mertinko, and I’ll be your host
and your moderator for today’s Webinar. Attendees are encouraged to participate in
our Webinar with questions and comments.All of your lines are muted now, but we will open
them for Q and A at the end of the presentation. However, please be aware that you can submit
questions at any time using the GoToWebinar chat feature, and those will be addressed
during the Q and A session.If you look, you should have a small orange arrow that appears,
usually on the right-hand side of your screen. And if you open that up, you’ll see a dialogue
box and a place that you can ask questions, or put things in chat. Should we run out of time, we will respond
to your questions via email.And if you have additional questions, you can submit those
to me at the email address listed on the slide. Also if you have any topics that you’d like
to recommend as potential Webinars in the future, please contact me and let me know.The
Division of State Systems within the Children’s Bureau continue to provide a series of monthly
Webinars supporting information sharing and discussion. Understanding who is attending the Webinars
helps us to identify content that is applicable for everyone participating in an agency CCWIS
effort.So I’m going to go ahead and open up a poll. And if you could just please quickly self-identify
which of the following groups you’re a member of, so that we can get an idea of who our
audience is. If you’re participating in a group that’s
together in a room, just select the category that best represents the largest number of
people in your group.And I’ll just give people a few minutes to answer. Just slightly over half of you have responded,
so if the rest of you can just go ahead and tell us who you are. If we could just get about the last 10% of
you all to identify who you are for us, that’d be great.Okay, and it looks like we have 21%
state child welfare information systems project managers. The biggest percentage is 66%, and that’s
state child welfare information system program, policy or technical staff. And we also have a handful of ACF Children’s
Bureau personnel or contractors with us today.And at this time I’m going to go ahead and turn
things over to today’s presenter, Dan Hon. Dan is a technology consultant to ACF.>>Dan: Hi.Good morning or good afternoon,
everyone. My name is Dan Hon. As former editorial director at Code for America,
last year I worked to help the State of California transition from a large, monolithic RFP to
a modular, user-centered and iterative procurement for a new CCWIS child welfare service.And
as a technology consultant to the ACF, I’m helping states learn and apply the principles
of modular design, user-centered design, iterative and agile development, and modular procurement.So
if we move on to the next slide, I’ll talk about what today’s presentation is going to
cover. So we’ve got six main topics today.I’m going
to go through the CCWIS requirement for modular design. Then why modular design is being required. An explanation of what modular design is. An explanation and some discussion about how
and why modular design is better than the historical alternative. How states and tribes might get ready for
modular design. And how you might move from a monolithic design
or a monolithic procurement to a modular design. And then after that, hopefully we’ll have
time for questions.So moving on to the CCWIS requirement for modular design, the requirement
is laid out in Section 1355.53(a), and roughly stated it says that except as exempted in
paragraph (b), automated functions contained in a CCWIS must follow a modular design that
includes the separation of business rules from core programming. And what we’ll do today is that we’ll talk
a little bit about what that means, and the implications for the design of CCWIS systems.On
the next slide you’ve basically got two types of exemption in 1355.53(b). So the first type of exemption is if you’re
in a transition period. So for the period where you’re moving from
an S/TACWIS system or a non-S/TACWIS system to a new CCWIS system, then that transition
period is exempt.Or on a case-by-case basis, if your proposal is more efficient, economical
or effective, if you can show that your proposed design or your proposed implementation is
going to be more efficient, more economical or more effective than an industry standard
modular design approach.So let’s go into Section 2. Why is modular design being required? So there are three main points to why, I think,
ACF is making the move to modular design, and the first one is that modular design makes
it a lot easier for automated child welfare information systems to meet user needs.And
I think the reason why this is, is because when you have a modular system, you have much
more – in principle you have a lot more flexibility to make sure that each part of that overall
automated system is able to precisely meet the needs of the users of that particular
part.So for example, it means that because you’re not bundling everything together into
one big recipe or one big monolith, you’re able to say, well these are the exact things
that I need for, say, my caseworkers who manage intake. And these are the exact things that my users
need for case management.If you are taking a modular design, that means that you’re able
to separate those parts of functionality out so that you’re able, on one hand, to concentrate
on, okay, well these are the features, this is the functionality, this is what I exactly
need for my users for intake. This is what I need for case management. This is what I need for resource management.So
there is the potential, with modular design, that because you have separated out the different
types of functions, and you grouped them together according to your different users and what
your different users need, there’s the potential for less need for compromise, for saying that,
okay, well if I need a system that does everything, then maybe I only get 60% of everything and
it’s spread across all of the different functionality.But with modular design there is greater possibility
that you’ll be able to meet those requirements in each area.Moving on to the second point,
modular design makes it easier for systems to be continuously improved, rather than the
usual model of procurement and then maintenance and operation.So whilst I don’t have a long
background in government technology, I think what I have seen over the past nine months
— and especially what I’ve seen in terms of child welfare systems — is that the traditional
or historical model of government technology procurement over the past 20 years has tended
towards that of treating technology a bit like plant and machinery.So we go out, we
gather our requirements, and then we put them together into an RFP. And then we procure that system. And then in some cases, that system then sits
around for about 20 years. And we ensure the maintenance of that system,
and we ensure the operation of that system. But what that means is that we miss out on
all of the benefits that accrue as technology improves.So, for example, the systems that
were procured and built in the late ’80s and early to mid-’90s were most certainly state-of-the-art
at the time. And some of them even now include very, very
solid and dependable technology. But the model that we have used with those,
where they are one big system that is treated as a whole, means that we can’t – or it’s
more difficult for us to upgrade and continuously improve parts of those systems.So the intent
with modular design is, how do we move from this kind of big bang of procuring a system,
you know, every 10 to 15 years, and then having to more or less throw it out, and then get
a brand new one? How can we move to a system of continuous
improvement to make sure that, from a child welfare delivery point of view, we’re able
to take advantage of technology improvements as and when they happen?Because if there’s
one thing that we do know, it’s that technology will keep changing. Technology hopefully will also keep improving. And we want to be able to take advantage of
those benefits as they become available, rather than in a big bang every 10 to 15 years.And
the third point about why, I think, ACF is requiring modular design – this one appears
to be exactly the same bullet point. So let me just check if I have another copy
here, and then I can see what that third point was going to be, if you’ll excuse me. So the third reason why, I believe, ACF is
moving with the modular design requirement is that ultimately it’s going to help states
and tribes deliver technology faster, more cheaply, and technology that’s going to be
more reliable.So to the faster point, I think what we’re seeing is that it’s incredibly
important to be able to get technology that meets the needs of our users, of our caseworkers,
of everyone involved in delivering child welfare, that takes advantage of the improvements,
and takes advantage of contemporary technology.We want to be able to get the systems out there,
and I think it’s very difficult right now when we enter, say, something like a, you
know, two- to five-year procurement cycle, when by the time we’ve actually delivered
on the procurement, then technology has moved along.We obviously always want to make sure
that we’re getting the best value for money. So we think that modular design is going to
enable us to deliver better technology more cheaply. And the third part is that the intent is that
modular design is going to help all of the technology that’s used in automated child
welfare systems become more reliable. So how do we deliver faster, cheaper and more
reliable software that’s involved in the delivery of child welfare? So I’ll move on to the third topic now. Just what is modular design anyway? So we’ll cover kind of three topics here. The first one is an introduction to monoliths
that some of you may or may not be familiar with. And then we’ll compare modular design to monolithic
design. And then we’ll talk about how modular design
might be applied to child welfare.So first an introduction to monolith. So traditional software development over the
last few decades is normally known as monolithic software. We’re on the next slide at the moment.And
if we go to Slide 14 – sorry, the next slide. So roughly speaking, all of the software that
gets developed, all the code that gets written, all the code that comprises a system, more
or less gets turned into one big artifact that is run on a server or a mainframe.And
this means that conceptually the developers and the vendors and the designers of the system
think of the system as one big entity. And there’s not really as much decomposition. There’s not really as much splitting up as
all of the functions.So one way of thinking about a monolith might be that, you know,
when you have all of the components of spaghetti bolognese together and you mix them all together,
then it’s very, very hard to deconstruct them. It’s very, very hard to pick them back into
their constituents and then change them.So if we go to the next slide, sometimes that
code might also get compiled into some client artifacts as well, like a Visual Basic application. And this is a model that I’ve seen in a number
of states through my work with ACF.So, traditionally the type of legacy child welfare information
systems that I’ve seen will have quite a lot of monolithic database and server code, and
then there’ll be a similar big client application that is treated as one single client application,
like a Visual Basic application. And that application runs on the client side. It runs on caseworker laptops and PCs, for
example.So if we move to the next slide, so the problem here is that software that’s designed
to solve a single problem is treated as a whole single piece. So conceptually and literally you have one
piece of software that addresses a large problem.And as I talked about this before just now, when
we’re talking about this one piece of software, it’s very, very hard – or it’s harder to tease
apart the individual parts of functionality. So you have a lot of interrelated functions.And
what this means – and one practical example of this might mean that if you have, for example,
a single client application, so one Visual Basic application, that your caseworkers use
on their laptops, on their computers, it is somewhat harder for you to update or upgrade
parts of the functionality of that application than it would be to – well it’s harder for
you to update part of the functionality of the application.Because ultimately you end
up having to recompile that entire application, and then deploy that entire application, when
really all you might need to do, for example, might be to update the workflow for intake. Or you might want to add a new option for
attaching documents in the case management section.So moving on to the next slide, in
this way with that type of approach, with that monolithic approach, when essentially
you’re saying, I have the entirety of all of the problems of child welfare delivery
to solve, and I need one piece of software that will solve all of that. I want a one-size-fits-all solution. And in this way you end up with a single piece
of software that addresses all of child welfare.And what we’ve seen are the attendant problems
with that, are that it makes it significantly harder. Or what we’ve seen definitely in the commercial
sector is that when we treat software like this, it is hard for us to move quickly. It’s hard for us to develop and deploy lots
of small upgrades over time. So it’s harder for us to do continuous improvement
of a particular piece of software or a service, when we’re dealing with this large monolith,
because there are so many interdependencies.So moving on to our next topic, modular design
compared to monolith. So on the next slide, in modular design, instead
of designing one piece of software that addresses the problem as a whole, broadly speaking we
break up the problem and the software into smaller pieces. So I’ve got a couple examples for you on the
next slides.So the first example would be instead of trying to design and build a car
all at once; and from a conceptual view and from a practical view having to keep in your
head or having to keep in a vendor team’s head everything that the car has to do; instead
of trying to design the entire car at once, and keeping track of all of those interdependencies,
we would design each of the components of the car one by one, and then we would have
an eye on how all of those components, all of those modules would fit together.So we
would spend some time designing the doors, designing the engine, designing the gas tanks
and so on. So we would take this large problem of figuring
out how to design a car, and then we would decompose it into, well what are the different
components that we need for this car?How do we make sure that we address each of them
in a way that best suits the needs of their users? How can we write that code? How can we develop that code that addresses
those problems in a way that we know will be reliable, so that we can then replace those?The
second example — and this might be a more accessible one — is that, you know, I think
we can all imagine that trying to solve a 256-piece puzzle in one attempt might be really
difficult. You’ve got all of these bits and pieces to
take care of.You’ve got all of these bits and pieces, and you’re trying to figure out
how they fit together. An easier way might be to break it up into
16 smaller puzzles, each of 16 pieces each, so you can work on each kind of individual
subset.And I think some people — or at least I’ve seen this with my 3-year-old — instead
of trying to solve the entire problem at a time, he might look at his jigsaw puzzle and
he’ll say, okay, well I can fit together all the pieces that make up the picture of the
sun. And then he can put those together. And then he can work out how that fits together
in relation to the rest of the jigsaw puzzle.So the big thing here, when we’re talking about
modular design compared to monolith, is the decomposition — so the breaking up of a very
big problem or a piece of software that might try to do everything, into smaller pieces
of software that each do individual jobs.And then our work then is defining the way that
each of those modules communicate with each other. And the benefit that that gives us is that
we can then replace each of these modules. Because what becomes more important is the
contract or the API or the agreement of what each piece of software, what each module,
does for each other module.So if we move on to the next slide, 3.3, Modular Design Applied
to Child Welfare. So a modern automated child welfare information
system should meet all the needs of children, families, caseworkers and managers to ensure
the safety and well-being of at-risk children.Modern modular software would meet those needs through
a set of separate, reusable modules that communicate with each other. So I can take you through three example CCWIS
modules next.So the first one might be an intake module. And I’ve described the intake module here
using a form of description called a user story. And this is how we describe kind of high level
functionality when we’re using iterative or agile development.So an intake module might
need to do this. As a caseworker, I need to record incoming
information about clients and search existing information, so that I can make a determination
like opening a case and assigning it to a caseworker.Our next example is a case management
module. So as a caseworker, I need to record information
and share information about my client. I need to keep track of tasks and dates, so
that I can manage care and services throughout the lifetime of the case.And then finally,
a resource management module. So as a caseworker, I need to quickly find
an order and book appropriate services for my client, so that I can ensure my client’s
safety.And then on the next one, a similar story for some other tasks that a resource
management module might do. So, for example, as a licensor, I need to
investigate license applications and complaints, so that I can issue, amend or revoke licenses.And
then finally, a data exchange module. So as a caseworker, I need access to data
to be able to easily access court information and submit information to the courts, so that
I can spend more time with my client instead of doing admin.Now each of those example CCWIS
modules, I would say, are an example of if you did a breakdown or if you did an analysis
of all the different types of work that caseworkers need to do, or all the work that’s involved
in delivering child welfare, I think what you’ll end up coming up with are common areas.So,
for example, in the work that I did with California, we started identifying high level kind of
groups of tasks. And those high level groups of tasks were
what informed – what became RFPs and RFOs and requirements for modules that we wanted
to develop or that we wanted to procure in California.So moving on the next section,
I’ll talk a little bit about why and how modular design will be better, and why and how this
approach should be better for how you procure and how you develop, and also continue to
improve your automated systems.So I talked a little bit about this already. Modular design makes it easier for your software
to meet your users’ needs. So one thing to focus on is that well-designed
modules focus on doing one thing, not many things.So a system is then made up of independent
modules, and that means that you should be able to choose the right module that meets
the needs for specific users and specific tasks, without affecting the rest of the system. There’s less need for you to have to compromise.In
principle, child welfare services that use modular design, or that are intended to have
modular design at the outset, should be able to mix and match commercial off-the-shelf
software, open source software, and software-as-a-service as needed, so that the best tools can be used
for the job. The next point is that modular design makes
it easier for your service to be continually improved.So when you have deconstructed, or
when you think about all of the sets of tasks and all of the services that your automated
child welfare system needs to do, and you’ve started organizing them into larger scale
modules, then what you have the potential for is, for example, to say, you know, there
are lots of improvements, or there are a number of improvements that we would like to make
to intake, or there are improvements that we would like to make to resource management,
or to data exchange.Because we have separated out the functionality of our software, and
because we’ve separated out the implementation of our software, that makes it a lot easier
for us to update just one module without affecting the rest of the system adversely.It also means
that in some cases where we improve one module, then all of the other modules in the system
are able to take advantage of those improvements as well, because there is a lot more scope
for shared services when we think about and when we apply modular design.The last point
is that modular design has the potential for you to deliver more reliable software more
quickly, and for less cost. So on this first point about more reliable
software, designing a modular system means that you can test and ensure the functionality
and reliability of individual modules as you go.So one of the issues that we’ve had with
traditional waterfall and monolithic software procurement and technology procurement is
that we build all of this functionality, and then only at the end do we get the first real
chance to test how all of that software works. Only at the end do we start integrating it
all, and only at the end do we start being able to test how all of that integration works.If
we’re dealing with a modular system, that means that we can test and ensure the functionality
and reliability of individual modules as we go. And that effectively means that we’re able
to take the big problem of doing all of our testing at the end of a traditional waterfall
and monolithic system, and we can test earlier rather than later, so that we can find out
sooner about any potential problems or any potential risks.The second point is that we’re
able to deliver software more quickly. So again, if I can go back to the jigsaw puzzle
analogy, it’s going to take us a lot longer to finish and complete a 256-piece jigsaw
puzzle than it is going to take us to finish, say, the first set of 16 pieces of that jigsaw
puzzle.So again, this is a benefit that we’re seeing in California, where California had
taken their monolithic procurement, and they’ve broken it up into a number of modules.So the
principle here is that when we take a big problem and we decompose it, we break it up
into smaller problems, then we can solve those smaller problems more quickly. And that means that the entire system – we
can deliver functionality for the entire system in a phased way, or in a gradual way, rather
than waiting, waiting, waiting, and then getting all of the functionality at once in five years’
time, for example.So there may be off-the-shelf software, or there may be software-as-a-service
that you can use for modules that already exist. And in other cases there may be software that
you want to develop yourselves. But again, the big principle here is that
when you think about – is that employing a modular design makes it easier for you to
prioritize.It will make it easier for you to figure out, well if we’re doing a transition
from a legacy system to a new CCWIS system, or if we’re starting from scratch and we’re
delivering a brand new CCWIS system, then it allows you the flexibility to talk to your
users and figure out, well what problem do we need to solve first? If we figure out what problem we need to solve
first, then that helps us prioritize which modules we work on first.That helps you put
together a plan of prioritization. And what that will mean is that instead of
waiting until the entire system is finished, you’re able to start delivering software that
works for your users better. And the last point, everyone always wishes
that they could get technology delivered less expensively. And in modular design, the potential is that
you’re able to mix and match existing services.So for example, what we’re seeing in the child
welfare space is that there are starting to emerge software-as-a-service modules, software-as-a-service
or subscription services or off-the-shelf commercial software that might be very good
at doing a specific job, and that can potentially be cheaper than you developing your own.So
moving on to Section 5, Getting Ready for Modular Design. So I’m going to cover three topics in this
section. I’m going to cover connecting modules together;
building and updating shared infrastructure; and then lastly, maintaining a common data
structure.For the first point, connecting modules together, the big point – one big
thing about modular design is that you’re going to instantly lose the benefits of modular
design if your modules communicate directly with each other. And this was a concept that I spent some time
on with the management team in California, helping them to understand. If we design a system of different modules
that each do their own job, and then they communicate directly to each other, then that
is going to lead, again, to a more or less monolithic design where everything is connected
to everything else. You’re going to still end up with the same
tangle.So moving on to the next slide, instead it’s better for you to have an API or data
module. So an API is an application programming interface. So this API or data module would be one module
that all of your user-facing modules talk to. So for example, any module that needs access
to data – what we don’t want to do is we don’t want every module to be accessing data on
its own.Ideally what we want to do is that each module — the intake module, the resource
management module, case management module, for example — they all talk to one piece
of software that handles all of those data requests. And that data module, for example, can also
do the job of being an abstraction layer for your underlying server or your underlying
database.So on the next slide, as a bit of explanation, APIs are ways for pieces of software
to make their information and abilities available for other pieces of software to use. So again in modular software, modules would
use APIs to communicate with each other.So what we’re doing with modular design is – what
becomes important is defining what each module does, and defining how each module communicates
with each other.And that definition, that API interface, that governs – that is kind
of our contract between what Module A provides to Module B, and what Module B expects from
Module A to work, for example.That’s what enables us, and that’s what delivers us the
benefit of being able to switch modules out and improve modules later, because what we
can do is we can – provided we fulfill, provided the modules fulfill the terms of those contracts,
those APIs between modules, they’re essentially black boxes, which means that we can go in
and we can upgrade the functionality, and we can improve the performance of each of
those modules, provided that we keep to the contract, provided we keep to the API agreement
between each of those modules.And then there’s a further part to that where we’re able to
version and increment and improve the APIs that the modules use to talk to each other.So
on the next slide, I talked about this previously. So all of the modules should communicate with
the API or data module. And ideally they should use industry standards
like JSON, REST and XML, which will make it easier for you to replace or upgrade individual
modules later.So there are lots of industry standards in terms of the type of data exchange
and the type of application programming interface that each of these modules can implement to
talk to each other.And ideally what you want to do is you want to make sure that each of
those APIs are documented. And what that will mean is that provided you
have the API documentation, provided you have the understanding or your vendor has the understanding
this is what Module A provides, this is what Module A needs, then any other vendor or any
other developer can work to that specification, can work to that API specification, and either
provide improvements to a module, or provide a drop-in replacement.So moving on to the
second point, building and updating shared infrastructure. So one principle of modular design is called
separation of concerns. It means that each module or piece of software
should focus on doing just one job.Where possible, whenever you find common functionality across
modules, that means that there’s potential for that functionality to be its own module
that other modules can use. So I can give you two examples here.If we
had, for example, our three example modules of intake, case management and resource management,
we know that each of those three modules need to access our database on our mainframe or
on our server.Ideally what we want to do is we want to make sure that we reduce the amount
of duplication across all of our software. We just want to write that piece of code once. So that’s where we come up with the concept
of having a data access module, or our API module.That means that we write the code that
accesses the database and makes sure that what’s going into the database is the right
kind of data that helps ensure data cleanliness. We write that module once, so that instead
of keeping three different ways of updating and retrieving information from our database
across our intake, case management and resource management modules, we only write that once.Another
example might be our data exchange module. So we could conceive of a requirement where
we know that intake and case management, for example, might have data exchange requirements
with the court system.So again, instead of writing, instead of including data exchange
in the intake module and the case management module, we would then take that out and put
it in its own module, so that every other module can also use that data exchange.And
then the architecture – in the conceptual architecture that we’re talking about, then
that may well live alongside or as part of the data access module or the API module.One
other example on the next slide. So for example, if you’re developing a custom
system, all of your user-facing modules might use the same user interface module. And this might not necessarily be a module,
but this is sometimes called a pattern library or a style library, or even just a JavaScript
library. But the intention here is the same.If we’re
developing custom software that will provide, say, a Web interface to a number of different
pieces of functionality, ideally what we want to do is we want to use the same user interface
library for all of these modules. That way if we find an improvement, then we
can deploy that improvement. We can apply that improvement once to that
user interface module, and then it can become available to all of our software.And then
moving on to the last point, maintaining a common data structure. So again, the simplest way to maintain and
enforce a common data structure is for all of your modules to access your data in the
same way. And this is, I think, emphasizing the point
that I’ve already made. So California’s new system is doing this by
implementing an API and data access module.So on the next slide, there shouldn’t be and
there will be no way for modules to access data directly. So the API or the data module acts, in a way,
as our gatekeeper. It means that we have the ability – from a
conceptual point of view, from an architectural point of view, we define our data structure
once in the API and data module. And then that API and data module provides
access to clean, sanitized, checked data to each of our user-facing modules.Moving on
to Section 6, I’ll talk a little bit about how to move from a legacy monolithic child
welfare system to a modular CCWIS system. And I’ll use California, my work with California
state, as an example here.So there are three parts to this section. There is the unhelpfully named strangler pattern,
which comes from an industry term. I’ll talk a little bit about legacy environments. And then finally I’ll talk about where you
might decide to start, or how you might decide where to start if you’re embarking on moving
from a monolithic legacy system to a modular CCWIS system.So the first part, the unhelpfully
named strangler pattern. So the strangler pattern is an established
industry method of completely replacing a legacy system with a new one. And as I mentioned, California is using this
method to move from their legacy system to a new CCWIS system. So the reason why this is called the strangler
pattern is because it gradually replaces pieces of functionality of the legacy system — that
is strangling it — until all of the functionality of the legacy system has been replaced and
improved. And then and only then, when all of that functionality
has been replaced, the old system is turned off.So what that means is that caseworkers
and users will be using both systems — both the new system and the old system — at the
same time. And over time, their usage will switch completely
to the new system, as the new system has replaced all of the functionality of the old system.Now
the chief advantage of the strangler pattern is that it means that you’re able to move
from a legacy system to a new system more quickly than you might otherwise, because
your alternative is we just go off and then we have two parallel tracks. We have the legacy system, and then we develop
the new system.We might develop the new system under a traditional waterfall method. So, say, after two or three years, or after
all of our development and all of our integration and all of our user acceptance testing is
done, then we turn on the new system in one big bang, and then we decommission the old
system. So the alternative to the strangler pattern
is kind of that big bang. We try to replace everything at once.And what
we found in the private sector is that the strangler pattern helps us deliver value to
customers and users more quickly, and it also turns out to be more reliable, because we’re
able to test that system as we’re going along.We don’t have to wait, for example, for two to
three years for all the development and integration and testing to be done, and then see how that
system works. It means that we’re able to see how the new
replacement system works in gradual stages, until we’ve finally completely replaced the
legacy system.The second point that I was going to talk about was about legacy environments. So my experience has been that most legacy
child welfare systems are monolithic client and service systems. So mostly the child welfare systems that I’ve
seen are using databases like DB2 or ADABAS, but are running on solid, reliable mainframes.And
what I’ve typically seen is that for the size of database, and for the number of transactions
that the database needs to support, typically the hardware is overprovisioned, so that there
aren’t really any performance concerns purely from the point of the database running on
the hardware. I’m not talking about network connectivity
or anything like that.On the next slide, though, we see that the client situation is more complicated. So caseworkers typically use monolithic Visual
Basic applications that were developed in the 1990s. And those Visual Basic applications talk directly
to the server, and talk directly to the database. In some cases, they may not even talk over
modern protocols like TCP/IP. They may talk just directly over protocols
like SNA directly to the database, or they may use transaction gateways that are particular
to the database environment or to the mainframe environment.And on the next slide, what we
normally see or what I’ve normally seen is that these legacy Visual Basic clients, they’ve
become very hard to update. They’ve become very had to support. Some of them may have reached end-of-life
in terms of support or their programming environment, or their runtime environment. And we also see that they don’t support the
mobile needs of caseworkers very well.But what we’ve also seen is that because these
Visual Basic clients are monolithic — because they are all of our functionality, everything
that the caseworker needs to do rolled into one application, and they don’t take this
more modern approach of saying, okay, well here are different modules that deliver different
services, and all of these modules work together and are able to communicate with each other
through an API layer — we’re left with a problem where we have one big ball of code.We
have one monolithic ball of code that does everything. And that becomes harder and harder for us
to support.So given all of that, where might you decide to start? So the exercise that we went through in California
was taking a look at the documentation and the work that the team there had already done
in terms of understanding their user needs, and understanding what their pain points were.So
and this can sometimes be a difficult exercise, but it does mean that you need to think about
everything that you’re doing, and it means ultimately that you need to prioritize. Because unfortunately, we can’t ask for everything
at once, and we won’t be able to get everything at once. We can get things in order, and we need to
decide what we want to spend our time on first.So one way to decide where to start is to take
a look at what your system does; what your caseworker needs, or what the particular needs
are of your system; and then what might provide a definite and quick win for your users.Some
other questions, on the next slide, might be taking a look at what your server or mainframe
environment looks like. How stable is your server? And how stable is your mainframe or database?And
if you’re running on a state mainframe, if you’re running something like DB2 on an IBM
mainframe, or if you’re running ADABAS, then chances are that your database is probably
pretty stable. If instead you’re running on a system like
IBM Notes or IBM Domino, then you might – I’ve seen states where they’re kind of hitting
the limits of those systems, and that database or that environment is significantly less
stable.But one thing that you’ll probably want to do is to find out how easy it would
be to take a look at that server environment, and find out how easy it would be to provide
a modern RESTful Web API.So again, this would involve taking a look at your mainframe, your
database environment, and saying, if we want to build new services, if we want to build
this data module or an API module that will allow us to deploy, to buy or build new modules
that work on top of that, then one of the first things you’re going to need to do is
provide a way for your legacy database to communicate with these new systems.Next you’ll
want to take a look at what your client environment is like. So again, are all of your services provided
through one application, like a Visual Basic application? How easy might it be for your caseworkers
to move from one application to another?One piece of information that I’ve always encountered
with every single state that I’ve worked with, from California onwards, has been a concern
that caseworkers won’t be able to – or will be reluctant to work with two different systems,
so for example, with their legacy system and the new system, and that conceptually it will
be difficult to deal with both types of systems, having to switch backwards and forwards, forwards
and backwards, between them.And what I can say is that in practice, that doesn’t normally
seem to be a problem. What really matters is making sure that there
is a clear, kind of logical delineation, there’s a clear separation between I know what I’m
using the new system for, and I know what I’m using the old system for.On the next slide,
for a typical child welfare system, a quick win might be to deliver new and better functionality
in a specific area to caseworkers. So for example, in California one of the things
that we found that would be most useful to caseworkers who perform intake functions would
be better search.So even as they are using their legacy system to do the bulk of work
of recording information about potential new clients, a better search mechanism for existing
information, we found out from them, would make their jobs a lot easier.So following
from that, one of your questions might be, well how does our server communicate with
our existing clients? Does it only talk to existing clients? Is there a way for it to talk to, for example,
different types of Web services?So on the next slide, in that situation, to deliver
any new functionality to your caseworkers you then might need to deliver, or you might
need to build or procure an API or data module, so that new services can access your existing
data.So in that way, you would build potentially two modules, or you would procure two modules
— one, this API or data module that would act as a foundation upon which you can build
other services and other modules. And the second one might be search functionality,
that is your first step in a new intake module.On the next slide, if you do go down the route
of building that API and data module, as we’ve talked before, that module should handle requests
to your existing database. As a first step, it’s a good idea to make
sure that that API module is read-only, so it only provides read access to your legacy
database. We want to make sure that we incur as little
risk as possible as you start building functionality.And then long term, that API module should be
built or should be procured with the goal of providing a modern and standard interface
for all of your other modules to exchange data.And again, so based on California and
lastly, here are the example user-facing modules that we found in California. So intake, case management, licensing — California
has actually decided to roll licensing in along with resource management — eligibility,
financial management, reporting, and also data exchange.So that wraps up my prepared
remarks and my prepared slides, so I think we’re able to open it up for discussion now.>>Elizabeth: Perfect. Dan, thank you so much. That’s a lot of great information. So, operator, could you remind us again how
people can line up on the phone to ask questions?>>Coordinator: Thank you. Yes. We’re ready to begin the question and answer
session. If you would like to ask a question, please
press Star followed by 1, and record your name clearly. Again, that is Star followed by 1. And one moment, please, for our first question.>>Elizabeth: All right. I’d also like to remind folks that they can
submit questions via the question box, which is in the GoToWebinar control panel. If you don’t see that panel, you should see
a small orange arrow, usually on the right side of your computer unless you’ve moved
it elsewhere. And if you click on that, that will open up
the control panel for questions.>>Coordinator: At this time I’m showing no
questions on the phone line. So again if you’d like to ask a question,
just press Star followed by 1.>>Elizabeth: Okay. And we do have some online. So, Dan, I’ll go ahead and start with the
first one. Is there ever a chance or a risk that as you
move from module to module, that when you finish the first or second module, it just
won’t fit with sort of the final evolved product, and you just have to go back and redo the
first few pieces?>>Dan: So the question there was as you’re
moving, as you’re – and I assume the question is more along the lines of as you are procuring
and building or delivering a modular system, that there’s a risk that the modules just
don’t work together.And I think that question kind of underscores the importance of the
API module, or of the data module. Because remember, each module has one job,
which essentially is to talk to that API module, and talk to that data module. They won’t talk to each other. Now in terms of the modules not working together,
or the modules not fitting with each other, that risk should be minimized if you always
think of, well each module only ever talks to one module, which is the API and data module. So there’s less chance of the modules not
fitting together side by side, if you will.I think the question may also be around the
risk that there might be some missing functionality, for example. And I think there, that risk can be mitigated
by making sure that you understand the domain, and you understand the area and the type of
problem that each module is supposed to address. It may well be, for example, that in your
case management module you find that — and I’m just speaking off the top of my head — you
find that your case management module, ideally you would like access to information that
might not have been gathered during the intake phase, during the intake stage, of a case;
in which case what you might want to do or what you might need to do is you go back to
the intake module and you say, okay, well there’s additional information that we might
want to gather.But in principle, for a situation where you say, okay, well it feels like there’s
a mismatch between what’s being gathered at the intake stage and what’s available at the
case management stage, if you are using an architecture, if you are using a design, where
each module just talks to the API or data module, then it’s a question of saying, is
the intake module providing all the information that it’s captured to the data module, so
that it can be stored in your database?And then it’s a question for the case management
module. Is this pulling all the information that it
needs?>>Elizabeth: Perfect. Thank you. At this time I also wanted to remind our audience,
if you have CCWIS-specific questions, please email those to the Division of State Systems
mailbox. It is C-C-W-I-S questions, all one word, at
A-C-F dot H-H-S dot gov. And DSS staff will then address those questions,
and then they may be incorporated into ongoing guidance for the larger discussion.Again that
mailbox is C-C-W-I-S questions, all one word, at A-C-F dot H-H-S dot gov. Do we have questions on the phone?>>Coordinator: We do have questions. We have one. The first one’s from Mark. Your line is open. Go ahead with your question.>>Mark: Hi. The module of design, do you mean that by
having the first module design, we still use the legacy database? Or you have a separate database for that to
capture information?>>Dan: So the question was, if you have your
first module designed, then are you still using a legacy database? Or are you using a new database? And I would say that it depends on which module
you’re implementing first. And it depends on – right. So it depends on which module you’re implementing
first, and it depends what kind of features you’re implementing first.One of the things
that we looked at in detail with California, in terms of determining which module to implement
first, was also the impact on the database.So in California, because we are doing intake
first, and because case management won’t become fully online for at least, say, six to nine
months after intake, what that means is from a process point of view, although someone
might use a new intake service to record a new client, that information has to go into
the legacy database so that it can be accessed by people who are still using the legacy case
management system. So what the data and API module needs to do
is it needs to understand and it needs to decide, okay, well from a data management
point of view, what data needs to go into a legacy database, and where can you keep
the schema the same? And ideally if you’re using the strangler
pattern, then you need to keep the schema the same in the database to preserve compatibility
until you’re able to switch all of your services over.So the answer is a bit of a – it depends. But what we’re seeing in California as they
– now that they’ve moved into implementation with that API module, is that a lot of the
early data just goes into the legacy database, and they will figure out at what point it
makes sense to start writing data into a new database, and then start doing that data migration.>>Mark: I do see a problem here. If I’m on my new module, and I’m adding more
data fields, I’m adding more features, so that means I have to, in a way, expand my
legacy database.>>Dan: Yeah, well so I know that we’re getting
into specifics here, so what we did with California is that we set out a number of principles
of – we set out some data standard principles that we did in a working group down in California.So
what we decided was that any data that can be written into the existing – so for starters,
there are no changes to the legacy database schema. If new functionality can only be supported
by new fields in the database, then those new fields are written into a new database
with a linking record to the legacy database.But the expectation is that any of those new fields
then will not be available, or cannot be available, inside any of the legacy systems. So the design of a particular module there,
when they’re migrating from legacy, when they’re transitioning from legacy to a new system,
is that new functionality, to a certain degree – or the default principle is the new functionality
is only ever available in a new system, and the legacy system only has access to legacy
data.>>Mark: Yeah, I do see some problems. That means you are growing your new database
per module, and to build up a new database structure.>>Dan: We don’t necessarily – and I have
to say that from the California point of view, we don’t necessarily see that as a problem,
because even given the size of California’s database, compared to what the private sector
has to do these days, it is more on the trivial end of database design.>>Mark: Okay. And another thing, if you have a dual module
approach, you try to switch out of the legacy system, but you have to remember that legacy
systems are not modulized. How do you handle that?>>Dan: So I think the question there is,
how do we – I think what you’re potentially getting at is that the legacy client application
might not be modularized.>>Mark: That’s correct.>>Dan: Right. So how do we switch off? Or how do we prevent access to what would
be a new module in the legacy client application? Is that right?>>Mark: That’s correct.>>Dan: All right. So that becomes part of the work of the M&O
contract with the existing vendor – and that is work that we did in California – we did
some exploratory work in California to say in principle, is it possible for us to either
turn off or prevent access to certain features in the legacy client application because we
need that in order to help people switch over to the equipment new module. So, you’re right that, that is an issue
that needs investigation when you are using this approach.>>Mark: Yes, that means you’re to work
out the new module, in the meantime you have to work on the legacy system as well to turn
off.>>Dan: Well, we’re attempting to minimize
the work on the legacy system. So, for example, one option for the legacy
system may well be – and you need to take a look at the – as to whether this might be
acceptable risk to you. But one option may be to do minimal work on
the legacy client application to say – from a user interface point of view – can we remove
access to some of these functions but we still lead them live as it were on the server.>>Mark: Okay, just my comments on the 256
pieces of jigsaw puzzle, you try to divide them up into 16 piles then you might have
a problem because they are all in the mix. How do you know that the 16 piles — the pieces
— will be able to assemble?>>Dan: That’s just my…>>Mark: Oh, I…
>>Dan: Yes, all right, okay, yes. I think the analogy there was – is that you
work on pieces of the puzzle where you work on parts the puzzle rather than trying to
do the entire puzzle at the same time but you find pieces that stick together.>>Mark: Yes, that’s my question. If you mix them up ahead of time, you won’t
be able to find that which pieces belong to which part. That’s all. I’m just – you know.>>Dan: Right, right. Thanks.>>Elizabeth: So, I’m sorry to cut this off
with you.>>Dan:I’m good. Elizabeth: We have some other people with
questions online. And before I go online, operator, do we have
other people on the phone?>>Coordinator: We do have a question from
Andrew Vick. Your line is open. Go ahead with your question.>>Andrew: Hello. I’m a developer with the state of Maine who’s
currently working on a monolithic system. And I’m having trouble understanding how validation
handled in the modular application – modular design between a data module and a UI interface
module. For example, if you have a placement screen
that you have to validate, that the start date is not known, I have to check for overlapping
placements, then I have to check with – whether the resource – is licensed. How is that distributed among the different
modules?>>Dan: So, off the top of my head, I would
say that you should perform simple data validation. So, things like, is this a valid date? But you can perform them at the client level. So, at least in the way that I think about
it in my head that you would provide them – you would do them at the user-facing module
level potentially in the browser. If you are talking about specific perks of
validation like, is this resource licensed and this is available, then that would be
a query to either if that information is in your database back through the data access
module or back to the data API module to query the status of the resource.>>Andrew: All right.>>Dan:So, I think – and again, I’m just thinking
off the top of my head. I think your question depends on are you querying
or for example, are you trying to validate persistent data that has been stored in the
database — in which case, you go through the data, you go through the API module — or
are you calling an API or you’re trying to perform a function that would be in the resource
management that needs to be – or you’re calling a particular kind of resource management-specific
function. In which case, I think you would still go
through or you still would mediate through the data API. So, the data API would, for example, present
a resource object and then you would call the API on the data module that would then
call the resource management module.>>Elizabeth: Okay, does that answer the question?>>Andrew: Yes, thank you.>>Elizabeth: Okay, perfect. Do we have anyone else on the phone?>>Coordinator: We do have another question
that comes from Farshan PJ. Your line is open. Go ahead with your question.>>PJ:This is PJ from Kentucky. We’re wondering if — through a modular
design — you also recommend a single integrated user interface solution to users who use multiple
modules or are you thinking of separate modules that are not integrated into a single UI?>>Dan: Ideally, you will use a single UI. But obviously, if you are a mixing-matching
especially with commercial off-the-shelf software as a service, then your opportunity to do
so will be limited. I’d say that if the intent – if you are
using commercial off-the-shelves or if you are using software as a service that you are
able to assess — as part of your procurement process — the suitability and the accessibility
of the user interface of those respective services. But I would definitely say that for custom-developed
modules and custom-developed user-facing modules, that you always track consistent user interface
across services.>>PJ: Okay, I just have a – if we do end
up procuring certain modules from vendors, is there a recommendation on how you apply
security on that — people who have access to that and stuff like that?>>Dan: Not – I have to admit not off the
top of my head. It is something that I know is being worked
on at California. For example, I don’t know if – or for example
I know in California that they are moving from a security module that was completely
handled on the server on the main frame using a piece of software called Raka. And in California, there is an agency move
to an agency-wide identity and access management service. So, what would they would be looking for — if
you’re going to implement an IdAM service — is which of your and how do your third
party modules work with your IdAM service and how might you handle things like Single
Sign On?>>PJ: Thank you.>>Elizabeth: Do we have other questions on
the phone?>>Coordinator: At this time, I’m showing
no further questions.>>Elizabeth: Okay. Well, we have quite a few that have come in
the other chat box. So, Dan, I have one for you that has five
different parts. So, I’ll try to cover them up.>>Dan: Okay.>>Elizabeth: Besides California, are there
any other states that have adopted a modular approach and if so, which state?>>Dan: I know that there are states that
are currently investigating on modular parts. So, as part of my consultancy with ACF, I
have been working with Mississippi, with Arizona, Connecticut and New Mexico, I think.>>Elizabeth: Okay, this is like a pop quiz
for you. I’m not sure you know this necessarily off
the top of your head. But which modules did they work on or are
they considering working on?>>Dan: Which modules are they considering?>>Elizabeth: Yes, or have they worked on.>>Dan: I think everyone – I think all states
are pretty much behind California in terms of procurement process. So, I think outside of California, every state
is still in the RFP – in the preparation for an RFP or RFO process or are still going through,
I think, the ADP with ACF.>>Elizabeth: Okay, and that’s actually
a really nice lead, Dan, because you’ll be talking about Agile procurement and development
for us in September, correct?>>Dan: That’s right.>>Elizabeth: Okay. So, I’ll talk about that a little bit at the
end but we’ll be giving more information on that in September.>>Dan: And Maryland, sorry. I was just reminded by one of my colleagues
at 18F that Maryland is also investigating and is also attempting to adopt the modular
approach.>>Elizabeth: Oh, fantastic, my home state,
you can’t leave them out.>>Dan: Yes.>>Elizabeth: What specific technology has
been used with API interfaces?>>Dan: So, and I think I’m able to talk about
this because California’s procurement for API has been awarded. So, specifically with California, they are
running DB2 — their legacy environment at DB2 on an IBM mainframe — they are including,
I think, or they are upgrading to the TCP/IP and sequel connector in the IBM CICS Transaction
Gateway. They will be routing the API services in Java. And then, I think, they’re also running NGINX
to provide the API and RESTful web services. So, globally speaking, the software development
environment for California’s API module is Java running on AWS.>>Elizabeth: Okay, and the last part of this
particular question, can customized COTS systems be used as modular components?>>Dan: And the answer to that is always it
depends on how much they’re customized and what the COTS components are. I would – yes, I don’t see any reason
why not. And again, it will always depend on the type
of COTS component. Again, from my point of view, the degree of
success that a COTS component might have will be dependent upon on its adherence to open
standards and open data formats. If a component does not or is not able to
adhere to open standards and open data formats, then you are not going to reap the benefits
of modularity because modularity also does imply that whether you want to or not or whether
you want to change or not, it’s likely that technology will improve and then they will
be a better option for that particular module that may not come from the best vendor — from
the best contemporary vendor. So, one of the things – one of the reasons
why I think ACF are excited about modularity is that it helps states keeps options open
and helps reduce vendor lock in. It means that if we use modular design, if
we make sure that those modules adhere to open standards and open data formats, then
we stand a greater chance of being able to switch to better solutions, go better services,
better products when they become available. The second part will be it will always depend
on the degree of customization that you need. So, if a piece of COTS software has been intended
– is intended to work alongside other software then that may be a good indicator that you
may have to do minimal customization versus if it is, say for example, a large legacy
enterprise product where a vendor is able to say, “Well, in theory this supports a
degree of customization or configuration that will allow it to work with other services.” Then I would be more nervous about that. And I think it’s a – I think there’s a recent
truism that was coined by one of my colleagues. He said that there’s no such thing as COTS
or there’s no such thing as customized for COTS. There’s only incredibly, unrecognizably modified
commercial off-the-shelf software. So, again, that is a big consideration when
looking at COTS – is what is the realistic customization that is practicable and was
the software designed to be customized in that way and used alongside of the modules
in that way.>>Elizabeth: Okay, perfect. Do we have other questions on the phone or
should I keep moving through with our online questions?>>Coordinator: Again, just press star 1 to
ask a question on the phone line. And we do have one question that’s from Mark. The line is open.>>Mark: I’m sorry. Hello?
>>Elizabeth: Hello.>>Mark: Just want to clarify one thing. You’re kind of designing your new CCWIS
data structure along with the new module implemented. Is that a correct statement? I have a legacy database structure on schema
setup. And so, when you develop a new module, then
you start to design – the data – back in database structure, say in the Oracle Environment,
based on the new module. You cannot set…>>((Crosstalk))
>>Mark: …them up piece by piece together and that will be your entire new CCWIS systems,
data schema.>>Dan: I would say it depends if you are
working on – if you’re working in an intuitive basis, then yes, you are going to extend that
schema as in when your requirements show that you need to extend it. But I think there is a great – there’s a
very, very big area in which you are kind of — obviously, I don’t think that you
should be changing your data schema every few days as you’re developing and designing
a new system. But at the same time with an intuitive and
agile development methodology then you’re going to recognize that at some point you
will probably come up with information. That means that it might make sense for you
to change your data schema and it might make sense for you to extend it.I think, again,
in comparison to the technology and the capability that were available about 15 to 20 years ago,
when we were first implementing these legacy systems there is significantly less overhead
to having multiple databases and to having multiple data stores especially compared to
the way that the private sector has moved ahead with the size and complexity of their
databases.So, even with big systems like California, I think that the type of – I think that the
load, the transaction environment and the amount of data that is required for a large
state system still pales in comparison to what the private sector now has to deal with.>>Mark: Okay, thank you.>>Dan: Sure.>>Elizabeth: Okay. Do we have anyone else on the line?>>Coordinator: This time I’m showing no
further questions.>>Elizabeth: Okay. So, going back to questions that people have
submitted via chat, in using modules particularly the idea of a purchase module, how do you
achieve a common consistent visual interface across modules for the user?>>Dan: So, I think we may have covered some
of this question already. I think someone may have come in with a question
about how you or can you implement a consistent user interface across different modules. And again, the answer there is going to be
you will be somewhat constrained if you are using a mixture of off-the-shelf or existing
software as a service where you are developing your own software or where you’re commissioning
the development of your own custom software. And I absolutely recommend you using standards
like the US Web Design Standards which is available at playbook.cio.gov as well as following
US Digital Service Playbook.And as it extends to the customizability of software as a service,
so for example if you’re using something like Salesforce or if you’re using other types
of off-the-shelf services then do take a look at things like how customizable the user interface
there is because while you may not be able to do things like necessarily change form
layout, you will want to make sure to see if even simple things like the copy that is
used in the interface and the words that are used in the interface are able to reflect
the interface standards that you build up across the rest of your complete set of software.>>Elizabeth: Okay, great. Thank you. And I think you also touched on this a little
bit with the earlier question about security but I’ll go ahead and put it out there in
case there’s a little more to add to it. As modules communicate with each other, what
design considerations need to be taken into account in order to ensure the protection
of sensitive data?>>Dan Hon: I’m sorry, could you repeat
that question again?>>Elizabeth: Sure. As modules communicate with each other, what
design considerations need to be taken into account in order to ensure the protection
of sensitive data?>>Dan: Okay. So, the question there, how do you protect
sensitive data and what kind of design considerations are there for sensitive data? And again, I think what you have here is with
a data an API module. You have the ability for that module to act
as the gatekeeper for PII or for sensitive information.So, I think what you’re able
to do is you’re able to make sure that at that data an API module — only modules that
are, for example, allowed to access that data or should be able to have access to that data
— are able to access that and that only authenticated users who also have authorization to access
that data are able to access it.So, again the principle here is that no software should
be directly accessing your database that has your sensitive data in it. All of the access is mediated through this
API all data module. And that from a design point of view, that
data, an API module is your kind of one point where you decide this is how we authenticate
and this how we authorize access to that type of PII information. What that means is that you have – you’re
essentially trying to centralizing, you’re trying to say, okay well, if any module wants
to access PII then there is one place where you go to access it. So, we make sure that we only need to write
that code once and that makes it easier for us to maintain that code and that makes it
easier for us to make any changes to that code.>>Elizabeth: Okay, perfect. Just a reminder too to our audience when you’re
thinking about COTS products you should be in touch with your federal analyst about the
use of COTS products for specific solutions or to get specific answers to your questions. And also remember for specific questions about
CCWIS please talk to your federal analyst or send your CCWIS questions to [email protected] I’ll remind you all again at the end that
you to put into – to put that out there right now. Another question we have is how important
is it to have the same vendor or developer build individual modules?>>Dan: So, the question there is that what
kind of benefit is there to have the same vendor build or develop each individual module. And I would set the question around in some
ways and say, “It depends on how suitable the vendor and whether the vendor has expertise
in each of those modules.”One thing that we have seen — and I’ve kind of eluded
to this in our conversation so far today — is that a big role will, for example, lies in
this data an API module because it’s that module that effectively manages all of the
communication amongst different modules and make sure that each module or each piece of
your software gets the data that it needs. And that’s where a lot of design considerations
need to go in.In terms of whether it makes sense for a vendor to work on multiple modules,
there can be some instances where you already have a vendor who’s familiar or there are
our adjacent domains. So, for example, in intake in case management,
it may be appropriate or then there will benefits for a vendor to work across both in those.There
can also be a case where it makes sense for the vendor who provides or develops the data
access module or the API module to also work on one of the first user facing modules because
that will essentially be your first test of, “Okay well, how is our data being provided? How well are communications being mediated
between modules so that they can work together that way?”>>Elizabeth: Okay. Great. Thank you.>>Dan: But again, I would say one of the
advantages, a big advantage of modular design is that you’re able to pick the right module,
you’re able to pick the right software that does the right job and does it well for each
particular group of tasks. So, while in theory there may be some contractual
benefits or vendor management benefits to having the same vendor work on multiple modules.From
my point of view — the intended — how do we make sure that we get the best possible
software to the people who need to use it and that we get that software from the most
qualified vendor.>>Elizabeth: Okay. We just have a couple of minutes left. Do we have any other questions on the telephone?>>Coordinator: At this time, I’m showing
no questions.>>Elizabeth: Okay. I will go ahead and ask one more. And then we do have a few more online and
so what I would ask Dan is can I send them to you and we can maybe send out responses
via email to the group that’s participating?>>Dan: Yes. Absolutely.>>Elizabeth: Okay. So, the last question we have time for is
if a legacy database design is suboptimal and needs a new design, how would you implement
then a strangler pattern? Yes, so I’d close with an easy one.>>Elizabeth: The question was if the legacy
database design is sub optimal, how would you implement a new one?>>Elizabeth: Yes.>>Dan: And I think I can honestly say that
at that point you talk to a database architect and you figure out what your needs are for
a new database system. And I’d also say that it’s difficult for
me to answer that question without understanding in what way your legacy database design is
suboptimal.So, for example, is it too slow to access? Are you having problems with transaction processing? Do you have, for example, a weird design where
you are storing – like in California’s – you’re storing – you’re effectively using your
DB2 database as a document, management database and you’re storing all your documents in
there as blogs and you need to get them out.So, I’d say that that is a very, very wide question. I would be happy to – pending the okay from
my managers at ACF, I’d be happy to have a separate discussion if I have the time for
that to be able to get into specifics.>>Elizabeth: Okay. So, again I think that would be a good time
for our asker to reach out to the federal analyst and see if there’s more that can
be done around that question.I’ll also take this opportunity to remind folks again about
the CCWIS mailbox — [email protected] — to direct any CCWIS specific questions
and a reminder to reach out to your federal analyst regarding COTS products and solutions.Dan,
I want to thank you so much. You have – you had to really work pretty much
nonstop for the last 90 minutes to share us some really wonderful information with our
group. So, I really do appreciate it and I think
this was just an incredibly valuable session. Also I would like to thank our audience who’s
been really engaged and asked some really fantastic questions. But Dan, thank you so much for your time this
afternoon.>>Dan: Right. Thanks very much.>>Elizabeth: All right. And for everybody, we will have Dan back with
us to talk about Agile procurement and development on September the 7th from 1:30 to 3 o’clock. That webinar invitation went out yesterday. So, please block your calendars September
7, 1:30 to 3:00 and plan to join us for a follow up discussion on procurement and development.With
that I’ll let everybody go and wish all a happy Tuesday afternoon.>>Elizabeth: Thank you.>>Dan: Great. Thank you very much.>>Coordinator: This concludes today’s conference. We thank you for your participation. At the tone, you may disconnect your line.

Daniel Yohans

1 thought on “Modular Design in Comprehensive Child Welfare Information Systems (CCWISs)

  1. Naga says:

    Thanks for sharing. Do you have any CCWIS compliance API related specification which is standardized by ACF?

Leave a Reply

Your email address will not be published. Required fields are marked *