An enterprise architecture repository as a basis for cross-silo management systems
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.
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.
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.
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.
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.
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.”
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.