A Solution: Digitized Architecture
In Part 1 of this two-part series, we explored The Next Generation of Enterprise Architecture Creation and Utilization and the challenges and opportunities associated with EA. We now look more closely at how organizations build solutions that provide incredible value and efficiency.
A Digitized Architecture (DA) is a new, service-oriented way of looking at how architecture is created and used. Many of EA’s traditional practices are antiquated and have failed to recognize the value new and more powerful technologies and analytics can provide. DA can be defined as an Enterprise Architecture that leverages analytic applications to make program, portfolio, and enterprise artifacts more transparent, interrelated, and interactive. Key aspects of a well-executed DA include:
- A common operating, EA Toolset, and analytic platform open to all stakeholders. Of course, appropriate access controls should be implemented but the focus of a DA is to make architecture and its component artifacts and data more transparent.
- Well executed governance to ensure guidelines/frameworks, approvals, processes, practices, and defined taxonomies are standardized, well understood, and adhered to throughout (across and down) the enterprise by stakeholders and architecture practitioners.
- Recognition that architectures are holistic composites as opposed to stand-alone artifact development efforts segmented from each other by functional and hierarchical divisions.
- Movement away from architecture as a “check box” exercise to an enabler of data-driven decisions down and across the enterprise.
- Movement away from strict architecture artifacts or viewpoints which are primarily used in static PowerPoint presentations to a more holistic approach focused on visualizing relevant data in manners consistent with decision-making throughout the enterprise. This includes accessing, analyzing, and usefully depicting real and near real-time data as much as possible.
- Recognizing that data sources and types not traditionally associated with architecture can and should be leveraged along with traditional architecture data sets and artifacts to support decision-making throughout the enterprise.
- Interoperability/integration with authoritative data stores not just manual uploads of point-in-time, often one-off artifacts.
- Recognition that architecture development, use, and evolution is circular in nature with each level of hierarchical architecture feeding and being fed by each other vice the linear nature of traditional architecture efforts. The diagram below shows the new DA paradigm.
Implementing a DA Solution
The major elements of a DA are:
- Common EA Tool and Repository: Too often an enterprise’s architectures are created using a variety of toolsets. Architectural data and artifacts are stored in disparate repositories and access is often restricted to architecture practitioners with limited transparency outside the silo which created the architecture. A DA requires a common toolset that is accessible to all stakeholders. However, given that organizations have existing architectures created in a variety of tools and formats, when fielding a common EA Tool/Repository, that tool must be able to ingest with minimal manual intervention disparate artifacts.
- Governance and Common Standards: A DA moves away from isolated architecture development, instead investing in a holistic approach in which all architecture efforts are coordinated. Coordination requires a common framework (practices, processes, and policies) and (often ruthless) governance. Terms must be agreed upon and baselined, which requires a common taxonomy. A widget in one functional lane needs to be recognizable in another functional lane, and this requires common guidelines. DA governance should ideally include stakeholders and leadership from throughout the enterprise.
- Integration/Interoperability with Appropriate Data Sources: Key to a successful DA is the recognition that data sources not traditionally associated with EA nonetheless contain data that can enhance the effectiveness of an architecture.
- Analytic Engine(s): Once the EA Tool has been configured and deployed and data source integration established, something needs to be done with the inrush of data. That is where the analytic engine comes in. Many EA Tools have robust analytic capabilities but there is a case to be made for layering a separate analytic application on top of an EA Tool. For example, data could be brought onto the Advana platform and data analyzed using Qlik, Databricks, or Collibra to provide more powerful and adaptable data dissection.
- Common & AD HOC Visualizations: After analyses and dissection, data needs to be visualized for decision makers.
Practical Applications of a DA
The potential of a fully realized, executed, and maintained DA within DOD writ large or within a military department or component is endless. Below are two specific use cases involving scenarios that are being undertaken more and more frequently within DOD.
Application Rationalization and IT Footprint Reduction
Increasingly, DOD components are trying to leverage architectures from all levels to support Application Rationalization (AR) and Portfolio Management (PfM) efforts. DOD IT footprints include large numbers of older or Legacy systems of widely varying levels of utility, age, maturity, cost effectiveness, and efficiency. These efforts are frustrated by the complications associated with the typical approach to DOD architecture development and use.
There are only so many Cobol-based logistics systems that a military department (MILDEP) needs. Traditional architecture does not often easily support application rationalization decision-making. However, by consolidating data from traditional architecture sources (i.e., Business Enterprise Architecture (BEA) assertions, DITPR, PfM systems (i.e., APMS, DITPR DON, ITIPS)) and non-architectural sources (i.e., eMASS, budget and executed funding systems), a DA can present a holistic view of an enterprise’s IT landscape. This view can be leveraged to identify gaps, opportunities, and risks of rationalization, sunset older systems, and subsume capabilities into new applications or services.
Imagine an architecture that includes system alignments to capability delivery that are married to financial (budgeted and actuals) and system maturity data. In a single dashboard, leaders could see how many systems they have which provide the same capability, how much they spend on each system and in total, and the age of those systems. Instead of lengthy time and labor-intensive data calls this coordinated data can be presented in near-real time for more effective data-driven decisions to reduce an enterprise’s IT footprint and technical debt.
Predictive Maintenance and Just-in-Time Logistics
MILDEPs and DOD components want to know with greater accuracy when assets (equipment, real property, vehicles, aircraft, etc.) will need to be repaired or replaced. This move to predictive maintenance will allow DOD to more efficiently field resources in support of the warfighter. Predictive maintenance requires lots of data and compilation of the analyses of that data. Traditional architecture is ill-equipped to support these real-time and near real-time exercises. Snapshot-in-time architecture is not designed to accommodate the time-sensitive nature required of just-in-time business process reengineering (BPR).
However, what if traditional event-driven process chains or proven and verified end-to-end (E2E) process models could be linked to real time performance data? Activities such as obligating funds, posting contracts, or delivering and accepting goods that are part of an E2E could, in a DA, be integrated with transactional systems to depict the actual times it takes to perform those activities. This could be seen as Process Throughputs that are calculated using actual data and performance metrics versus the best guesses of end user functionals.
Conclusion
These sorts of time-linked performance metrics would leverage existing architectures and data not traditionally considered as particularly relevant to architecture. Currently disparate data sets are out there in the DOD space. A DA allows for their alignment and presentation to stakeholders and decision makers. The above scenario is just one example of the efficiencies a well-executed DA can help create and maintain. As an innovative government consulting firm with a focus on the DoD, Significance stands ready with experts to support these efforts. For teaming opportunities or more information on our DA offerings, please contact Rick Pauly at Richard.pauly@significanceinc.com.