1. DHS OCIO/OCTO 1
Kevin A. Wince
Acting Chief Technology Officer
Executive Director for Enterprise Architecture
Office of the Chief Information Officer
Department of Homeland Security
Agile Enterprise Architecture &
Application Rationalization
Applying a business-focused, data-driven approach to
analyzing IT applications and visualizing EA data
4. DHS OCIO/OCTO 4
4
2
The Second Meaning of “Enterprise”
Enterprise
Business
Security
Data
Systems
Technology
Strategy
5. DHS OCIO/OCTO 5
5
● Model driven architecture
o Focuses on the visualization, not the data
● Create diagrams that often serve as a check in the box
o JCIDS
o FEAF
● Has value at the solution and segment level, hard to
derive value at the agency (enterprise) level
● Complex tools that few in the organization know or care
how to use
● Largely unchanged over the last 10-15 years
2
Traditional Enterprise Architecture
6. DHS OCIO/OCTO 6
6
● The primary purpose of an enterprise architecture (EA) -
support the decision making needs of the agency’s
business stakeholders
● A secondary purpose - support the decision making
needs of the technical stakeholders that directly
support the agency’s business stakeholders
● In order for any of this to be successful, accurate EA
data must be made readily available in a format which is
easily digestible and understandable by everyone
2
Why Do Enterprise Architecture?
Never identify the purpose of EA as compliance!
7. DHS OCIO/OCTO 7
7
● Agile means growth happens with small, iterative,
customer-centric steps that produce results quickly
● Agile EA is an approach to architecture development
that is focused on small EA deliverables with the needs
of the customer in mind
2
What is Agile EA?
Get visualizations/reports in front of the organization early, and
constantly ask for feedback.
9. DHS OCIO/OCTO 9
9
1. EA should be useful for everyone
2. Business stakeholders are trusted partners who ultimately own
the data
3. Focus on the data, not the diagrams
4. Visualizing the EA data is key
5. Good architecture is about design intent
6. Reduce redundant data calls by reusing EA data
7. Single EA application
8. EA does not enforce, it informs
9. EA is never complete
10.Deliver business value quickly
Top 10 Agile EA Principles
10. DHS OCIO/OCTO 10
10
● EA widely unused across the Agency
● Little value
● Minimal relationship with the business
● Mainly a compliance function
● Multiple EA databases/tools, none were considered
authoritative
● Confusing
2
EA Landscape at GSA Upon Arrival
11. DHS OCIO/OCTO 11
11
● Go on a listening tour
o Understand business and technical issues and
frustrations
o Build partnerships
● Drive towards a single source (one repository) of the
truth
● Develop a data model that will continually evolve
o What data do people care about?
o What questions need to be answered?
2
First Steps for Success
12. DHS OCIO/OCTO 12
12
● The EA team should be viewed as the brain trust of the
organization - there to help others accomplish their
mission
● As the authoritative repository of information, the EA
must become the initial reference point for the budget
team, project managers, senior decision makers and
many others to use for their research and knowledge
sharing
2
Establish a Helpful EA
13. DHS OCIO/OCTO 13
13
● EA teams should have a good understanding of key
stakeholders across the enterprise to whom they provide data
● Attention should be focused on obtaining buy-in with the
definitions that impact EA (e.g., application, system, platform,
etc.)
o Stakeholders are better able to have meaningful
modernization discussions when a fundamental
understanding of key terms is obtained in advance
● It is important to continue building rapport by communicating
successes, providing interim status updates, and demonstrating
that there is progress being made
o Sharing EA data and results from initiatives builds credibility,
fosters communication, and enables change
2
Stakeholder Buy-in
15. DHS OCIO/OCTO 15
15
● Need to have one location for all data that is recognized
as the authoritative location
● Data should be obtained from authoritative sources
where they exist
o Examples: FISMA data, CPIC data
o When authoritative data sources do not exist for
needed data, the EA repository should serve as that
location
2
A Single EA Application For Authoritative Data
17. DHS OCIO/OCTO 17
17
2
What Does the EA Homepage Look Like?
Must be simple, clear and not overwhelm users.
18. DHS OCIO/OCTO 18
18
2
What Does an Organizational Report Look Like?
Depicts major bureaus, offices, etc. within an organization.
Must drill down to appropriate level of organization.
19. DHS OCIO/OCTO 19
19
2
What Does an Application Report Look Like?
Identifies the authoritative application list for the agency along
with some other key pieces of metadata.
20. DHS OCIO/OCTO 20
20
2
What Does an Application Roadmap Report Look Like?
Provides the 3-5 year roadmap strategy for IT modernization in the agency.
21. DHS OCIO/OCTO 21
21
2
What Does an IT Investment Report Look Like?
Identifies agency IT investments along with some other key pieces of metadata.
22. DHS OCIO/OCTO 22
22
2
What Does an IT Standards Report Look Like?
Identifies the authoritative list of technologies (software) that have been
approved and denied within the agency.
23. DHS OCIO/OCTO 23
23
2
What Does a FISMA System Report Look Like?
Identifies the authoritative list of FISMA Systems, POCs,
key dates, links to artifacts.
24. DHS OCIO/OCTO 24
24
2
Data Maintenance
● The EA team manages the architecture and how the
data is displayed; it is the responsibility of the data
owners, and the business and technical stakeholders, to
ensure the data is accurate.
o Business and Technical stakeholders - should be
granted access to maintain only their area of focus
and not the entire repository of data.
o Periodic reviews should be scheduled with
stakeholders
o Utilize existing resources - i.e. for POC data utilize
the global access list (GAL)
25. DHS OCIO/OCTO 25
25
2
Marketing – Getting the Word Out!
● Once the EA application is developed, it is critical to begin to market
it in as many ways as possible
o Newsletters, magazine articles, and agency intranet articles are
a few methods available to advertise what the agency EA
solution can do
o In those articles, simple use cases can be given as examples so
that anyone can see the benefit of EA
● It is also important to track metrics on the EA application to get
informed about usage.
o Number of unique users
o Number of sessions
o Statistics on the most popular sections of the EA website
o Use these to further promote the EA application by informing
senior leadership and others of the success
27. DHS OCIO/OCTO 27
27
Application Rationalization Summary
Senior business leadership buy-in is critical!
● Application Rationalization - a methodology that provides
an organization a way to review a portfolio of applications
● Led by EA team – often no one in the owning
organization is familiar with entire portfolio of applications
● Identify applications to Tolerate, Invest in, Migrate and
Eliminate (TIME)
28. DHS OCIO/OCTO 28
28
Application Rationalization Accomplishments
Improved resource
allocation by reducing
redundancies and
inefficiencies
Engaged Business &
IT stakeholders
Defining 4-year
business-led strategic
application roadmaps
Data centralization
with fewer applications
Between Feb 2014 - June 2017, the Application Rationalization efforts have
resulted in the following:
265
Applications
Reviewed in
Portfolios
600+
Stakeholders
Engaged
Applications Eliminated
or to be eliminated in
FY16 - FY18
68 $12M+
Cost Avoidance
Identified
Increased Security by
reducing potential attack
surfaces
Increased End user
satisfaction by simplifying
the IT environment
29. DHS OCIO/OCTO 29
2
Phase Description
Phase 1 - Conduct
Baseline TIME
Analysis
Baseline application inventory
Plan sprints
Present applications and obtain governance approval for Phase 2
Phase 2 -
Conduct Detailed
Architecture
Analysis for
Selected
Applications
Conduct business and technical architecture
analysis as well as life-cycle cost analysis of
selected applications to:
● Detailed architecture analysis
● Evaluate existing technology solutions
● Data management, integration, and interoperability issues
● O&M cost reduction strategies
Present recommendation to governance
Two-Phased Approach
30. DHS OCIO/OCTO 30
30
Artifacts For Each Phase
2
Phase Artifacts
Phase 1 - Conduct
Baseline TIME Analysis
● Baselined application inventory
● Application Rationalization Project plan
including timelines and sprints
Phase 2 -
Conduct Detailed
Architecture Analysis
for Selected
Applications
● Questionnaires for each application
● Detailed brief with recommendations and
TIME data for each application within the
portfolio
● Authoritative application portfolio (displayed
on EA visualization solution) including
○ Strategic plan view
○ Business alignment view
○ Interface diagram
31. DHS OCIO/OCTO 31
31
● Baselined application inventory allows everyone to start with one common
understanding
● Sprints (e.g., ~15 apps for each 3 week sprint) provide the team the ability
to progress through the portfolio and demonstrate results
o Sprints should be grouped by common capability or enterprise
initiative, to the extent possible
● Buy-in from governance stakeholders and senior management is critical
before proceeding to Phase 2
2
Milestone Description
Baseline application
inventory
● Common understanding of applications
● Identified business and IT POCs
Sprints ● Identify sprint(s) to meet with and review
application portfolios
Phase 1 Overview
32. DHS OCIO/OCTO 32
32
Phase 1 Artifact: Baselined Application Inventory
● You may get different sources of truth (different count of apps, varying
app names, incomplete owners)
● At the end of Phase 1, there was ONE consolidated list that everyone
agreed to
● Should have application name, description, owning office, Business POC
and Technical POC.
?
33. DHS OCIO/OCTO 33
33
Acquisition Application Portfolio
...
Phase 1 Artifact: Planned Sprints
Focus of
Phase 2
Sprint 2
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name
Sprint 3
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name
Sprint 1
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name,
Application Name, Application Name, Application Name
● Sprints should be
planned to last no
longer than 3-4 weeks
● Plan to iterate through
sprints until the entire
portfolio is reviewed
● The team should plan
to provide status
updates to governance
boards and
management after
each sprint or two
34. DHS OCIO/OCTO 34
34
2
Phase 2 Overview
This is an iterative approach that is repeated for each sprint.
Milestone Description
Complete planning
activities
● Send emails
● Schedule meetings
● Distribute questionnaires
Complete meetings ● Conduct business and technical meetings
with IT & business owners
● Complete follow-up meetings (as necessary)
Complete analysis ● Assess business impact, technical
architecture, data migration plans
Brief governance
boards
● Brief observations, recommended 3-5 year
TIME strategy, opportunities for
improvement
35. DHS OCIO/OCTO 35
35
Phase 2 Artifact: Questionnaires
● General tab used to collect
general application data
● Business owner tab used to
collect Business-specific
information
● IT owner tab used to collect
IT-specific information
36. DHS OCIO/OCTO 36
36
● Below is an example snapshot of the applications
● Each application is placed in a TIME quadrant for the current 3-5 years
● Some applications may be TBD because more analysis or decisions need
to be made
2
Phase 2 Artifact: Application Roadmap Report
37. DHS OCIO/OCTO 37
37
Tolerate: There are three levels of tolerate:
• "T1" are considered in "keep the lights on” mode and only critical fixes are completed (i.e.,
resolve issues only if the application cannot be used at all or without major workarounds or for
significant security vulnerabilities). No DM&E. Only O&M
• "T2" are tolerated with enhancements. Mostly O&M with some DM&E
• "T3" are tolerated, are likely to be considered for migration in the next 1 to 3 years and a
migration plan is needed. Mostly O&M with DM&E for migration planning
Invest: Application is being developed/upgraded to provide functionality due to new business
requirement or elimination of current applications. Must have an approved EBC or 50% or more of
budget is DM&E. Applications will have implementation plans detailing the planned enhancements.
Migrate: There are two levels of migrate. Migration planning and funding to complete migration
should be approved so the migration can begin in the current fiscal year:
• "M1" are considered applications whose technology/platform/hardware are being modernized;
applications satisfy drivers to move to a new platform or technology. Technology focused.
• "M2" are considered applications whose capabilities are migrating to new solution; application
satisfy drivers including improved integration with other applications.
Technology/platform/hardware should be modernized as part of this migration. Business
focused (could include technology changes).
Eliminate: Application is no longer needed. Elimination date is known. Data migration plan is known.
TIME Definitions
38. DHS OCIO/OCTO 38
38
Phase 2 Artifact: Business Alignment View
2
● Business capabilities are used to define the services provided to the agency’s
customers
● The is an example representation of the applications aligned to the Customer
Services BRM
