News

08.04.2021

An enterprise architecture repository as a basis for cross-silo management systems

Different management systems operating alongside one another make coordinated company-wide architectural work difficult. A more effective exchange of data between previous silo structures also offers advantages for individual business and IT domains, such as security and software asset management organizations, for example. The Cross-Business-Architecture Lab conducted a study to determine where the introduction of a data synchronization system makes the most sense – and how such a system can be implemented across various silos.

Silos and the silo mentality are the enemies of modern business and IT management organizations. The insularity they create and foster disrupts the development of new digital business models, makes business processes less efficient, blocks data flows, and prevents effective data analysis. This is a recognized fact – which is why everyone is now talking about the need for interdisciplinary work across silos.

If you examine things in more detail, however, you’ll quickly notice that many management systems are also still trapped in a silo mentality. This can be the case if, for example, such systems were designed for only one business unit or specific business units, or if they’ve been optimized to perform a certain set of tasks and do not share or exchange data with other management systems. This in turn makes interdisciplinary work and interaction between multiple management systems very difficult.

Working together – not in parallel

“Room for improvement” – is what the experts at the Cross-Business-Architecture Lab thought here. They therefore set up a working group that developed concepts for enabling various management systems at a company to work together effectively, rather than working separately alongside one another. On the one hand, these concepts explain how software asset management, information security management, business process management, and project portfolio management can benefit from data collected and stored in an EA repository, while on the other hand they describe how enterprise architecture management (EAM) can make use of data from other management systems at a company.

Thomas Schreiner, who served as the coordinator of the associated workstream and is also Head of Enterprise Architecture Management at Fresenius Netcare, offers an example of how useful the exchange of data between different management systems can be: “A risk management unit, for example, can use data from an EA repository that shows how old specific applications are. This enables a more precise determination of risks that take the form of missing security updates, expiring manufacturer support agreements, or insufficient compliance with legal provisions, for example.” This type of data exchange also offers benefits in the areas of cybersecurity and portfolio management. “A company has to know which capabilities it needs in order to be able to implement certain business ideas and models,” Schreiner explains, “and “nobody has to reinvent the wheel if an EA repository’s capability map can be used for this.”

A company has to know which capabilities it needs in order to be able to implement certain business ideas and models. Nobody has to reinvent the wheel if an EA repository’s capability map can be used for this.
Thomas Schreiner
Workstream Coordinator

User stories highlight the benefits

Such approaches should actually be a given – the problem is that IT, organizational, and business silos often prevent integration, even if such integration only involves making lists or data visible. For example, it’s very unlikely that the data protection tool used by a data protection officer will contain an up-to-date list of all IT systems, thereby enabling him or her to identify which data was processed by which system. If such a list could be seen, the data protection officer would not only be able to provide information on IT system responsibility in each case and also know where all different types of data can be found; he or she would also be able to show which systems have processed which data for which department, unit, business line, etc.

It’s also unlikely at the moment that someone responsible for applications can see at just the push of a button which IT components his or her application depends on.

IT security departments could also benefit from more simplified integration of management systems – for example they would then be able to see which applications run on servers that are also used to run operating system versions that a manufacturer no longer supports. In such a situation, those responsible for the applications in question could be automatically notified that adjustments need to be made.

Ten domains identified for integration

Another user story would involve integration of project planning software with an EA repository. It would be helpful in a project if all project participants could see exactly what effect the project will have on IT systems in terms of the strain placed on them, their performance, and additional requirements that might have to be introduced. This would benefit both project managers and architects.

Integration with an EA repository offers advantages for other domains as well. CBA Lab has produced a white paper that identifies ten domains and assesses them in terms of their relevance for EA integration analyses. The white paper determined that risk management, data management, data privacy management, and software asset management can benefit the most from integration with an EA repository. Config/ITIL management and organization management were also identified as being very relevant in this regard. The benefits for IT cost management, business process management, information security management, and project portfolio management would be less extensive, but since such operations are closely related to the business side of the equation and are part of the digital value chain, greater transparency would take on greater meaning here as well.

CBA Lab has collected information on stakeholders, data contexts, expected value contributions, data that is relevant from an EAM point of view and needs to be made available, and data that needs to be consumed by EAM in each domain. The resulting detailed overview of this information for all ten identified domains is presented in a white paper that will soon be published.

Integration of an SAM system and an EA repository offers an ideal example of the benefits that can be achieved

The example of domain software asset management (SAM) clearly shows the advantages offered by integration with an EA repository.

Integrating software asset management systems such as Snow, Matrix42, etc. into a central EA repository enables the identification of a large number of application scenarios that offer benefits for both EAM and SAM. Because SAM tools generally include automated inventory solutions that continuously take inventories of the system landscape, information on the “actual state” is usually always available. If the information on the actual state were to be automatically synchronized with the EA repository, the very latest data would always be available for analysis – with no need to perform manual updates. As a result, SAM data could be used to determine the technology risks associated with applications, for example, or to assess the business criticality of IT components on the basis of the application criticality. “If I know how old my infrastructure for business-critical applications is, I can estimate the risk of a legacy trap or higher support costs much more precisely,” Schreiner explains.

However, it wouldn’t advisable to import all the data from the SAM tool, as most of this data is not relevant for the EA repository. Instead, the data that’s relevant to the planned integration should be defined in advance. Relevant data could include data on the operating systems and databases used, as well as data on application runtimes or aggregated figures such as the number of installations. Less relevant data could include client applications such as VLC, Firefox, or installed smartphone apps, for example, which from the EA point of view generally have little or no relevance.

Some SAM tools are especially designed to read cloud environments such as Azure, AWS, and GCP. Combining such data with an EA repository creates additional governance and control options for the utilization of cloud environments.

Easy integration with PowerShell script and REST API

Automated scans ensure that the actual state is always recorded and that SaaS or cloud applications are recognized in some cases, which means that EA integration can also be used as a powerful tool to gain an insight into shadow IT and to uncover maverick buying as well. 

The procedure for importing data from the SAM tool Snow to the EAM tool LeanIX offers an example of practical implementation. The data here is for recognized servers, their respective operating systems, lifecycles, virtualization platforms, and other automatically recorded data. Integration is achieved via a PowerShell script that retrieves the data from Snow by means of REST API. Data from the active directory is then added to this information in order to depict the lifecycle of the server. All the collected information is then converted to LDIF format (LeanIX Data Interchange Format) and transferred to the integration API. The data is read with the help of the processors stored there and then shown on fact sheets. “The procedure isn’t very complex at all,” says Schreiner. “However, the bridge built between the SAM tool and the EA repository results in a wide range of benefits. In terms of procurement, the response capability increases at the end of the lifecycle. The automatic expansion of applications for the underlying software products also increases the degree of automation.”

The working group has come up with various criteria to help companies select the right technical integration tools and methods. The rule of thumb here is that the more frequently data is to be exchanged, and the greater the volume of such data, the greater will be the need to achieve technical integration with the help of scripts, ESBs, middleware, or APIs. However, the cost and complexity of implementation are much higher here, and the skill sets needed are much greater, than is the case with manual integration or when RPA bots are used to manage the data exchange.

Data quality and other requirements

In order to prevent discrepancies and asynchrony when several systems are to be synchronized with one another, it’s helpful to identify the lead system in each case.

One of the major benefits offered by an enterprise architecture management function is the creation of a binding company-wide language that establishes a common understanding and prevents misunderstandings. Nevertheless, integration with third systems can lead to conflicts due to the fact that the way terms are used in the business domain of the target system differs from the way they’re used in the source system (e.g. “application” = “installed program” as opposed to “business application”). Data scope and granularity are also often unclear. The term “process” could, for example, mean either all business processes at a company or the number of all processing activities documented in the process directory of the data protection organization. In many cases, two different terms might also be used to describe the same attribute, e.g. “criticality” and “risk” – and the same is true of roles and responsibilities. All of these potential conflicts must be resolved before synchronization in order to ensure that the expectations of both parties with regard to the exchange of data are met.

Regardless of what type of technical setup is used for synchronization, it is advisable that both participating business domains conduct a dialog in order to define the processes within which the data sets involved can be created, utilized, modified, deleted, and possibly also linked to other elements. The use of an end-to-end point of view for the entire lifecycle of an element makes it possible to identify consistency problems and previously undetected dependencies.

“It has become clear that EAM performs even better if it’s implemented across silos,” says Dr. Karsten Schweichhart, Member of the Board of CBA Lab. “The repository integration for ten different domains that we proposed shows how this can work in a real setting. We have demonstrated that IT and business domains that opt for integration can obtain clear benefits for their own operations.”

Detailed work results are available exclusively to CBA Lab members.

This article appeared in a similar form in ITmanagement and manageIT.