Introduction
Deleting information from any document is something to think about twice may be thrice. But deleting a requirement from a specification is not as simple as deleting a sentence. A requirement is an object which holds not only the specification sentence but other information like name-value pair attributes, history, link information etc.
In this document we will try to explain possible ways to approach how to delete requirements
Challenges
Sometimes it is required to discard some information from the project for various reasons. But even in such cases, when specification information is discarded, there are still some risks as follows:
- It may break the integrity of the overall information map.
- The information piece to be discarded may not be needed in one configuration but may still be critical in others.
- The information piece to be discarded now, may still be an important component of an audit trail
- The information itself may have no value anymore, but the links it bears, my still constitute some value
So when we decide to delete any information from the requirements base, we should be considering several cases. Or somebody has to pre-consider for us.
How to delete requirements from DOORS Next Generation
How can we delete any requirement from DNG? Or what is the best approach to delete requirements from the requirements database?
For the reasons mentioned above, deleting requirements from GUI doesn’t exactly remove the data from the database. It just gets unaccessible. But to keep the integrity intact, any deleted requirement, still occupies a placeholder in the database.
Soft Delete of Artifacts
Since any “delete” operation via the GUI doesn’t cause the physical deletion of the data from the database, and in spite of this result, the data is still permanently unreachable when deleted, may be we can consider a “soft” delete operation.
It is a widely accepted approach to organize requirements in modules within DNG. Like we create/edit requirements within module, we also tend to execute the delete command in modules. This command is called as “Remove Artifact”:
What we are doing with this command is not actually deleting the requirement, but removing it from the module. So it will remain accessible in the base artifacts and folders.
Also, by design, there is a concept of requirement reusability. This means this requirement may coexist in other modules.
This is why, when removing a requirement from a module it is not “deleted” by default. However if the artifact is present only in one module, then there is an option to delete it via “remove” comment as follows:
If the artifact to be removed doesn’t exist in any other module, this option permanently deletes it.
The permanent deletion of the artifact will still leave the artifact on the database for the integrity of the data. But it will not be possible to retrieve this artifact any more.
So we can recommend not to permanently delete any artifact but remove. However there might still be some issues with removing the artifact from the module:
When an artifact is removed from the module, the specification text, its key-value pair attributes, history, all information will remain. Only its link to the module it belongs to will be broken. But there is one important piece of information else which gets broken. The link to other artifacts! In this example we see that the requirement is linked to another requirement in another module. When the artifact is removed from the module, we use that link as well. So when we retrieve it back to the module, it won’t have the link information anymore:
Sometimes our clients may prefer this behavior, sometimes not. For those, of which this is not preferable, we generally consult a “softer” delete operation. We advise to define a boolean attribute called “Deleted” with default value “false”. This attribute is assigned to all artifact types and instead of deleting the artifact, simply change the boolean value from “false” to “true”.
Of course it is not enough to do this. Also we need to define a filter for every view which filters out the “Delete” attribute “true” valued requirements.
Hard Delete of Artifacts
Hard delete of artifacts can be considered as deleting the artifacts with the option “If the artifact is not in other modules, permanently delete it.” selected.
But this will still not be sufficient if the artifact is being used in more than one module. To make sure a hard delete, first remove it from the modules it is being used in.
You can used the information “in modules”
Then, just simply locate the base artifact in the folder structure and select “Delete Artifact” from the context menu.
Upon confirming the deletion it will be permanently deleted:
This operation will still not delete the artifact from other configurations if there are more than one stream and the artifact appears in those streams.
How to clean up requirements
As mentioned above, the requirements even deleted from GUI are not deleted from the database for various reasons. Most of which is to maintain the data integrity and database indices. Theoretically, after every physical deletion of the artifacts a reindexing and database maintenance scripts should be run. This would not make sense for a daily operation done by an end user.
For those artifacts which are permanently deleted from the GUI, there is a repotools command which helps to remove from database as well. This is deleteJFSResources command. However, use it with extra precaution and please review the information in the link below:
https://www.ibm.com/support/pages/deleting-data-permanently-doors-next-generation-project
Summary:
Making use of configurations, streams and modules complicates the deletion concept. We may loose information where we don’t expect. Also we may get results even after properly deleting artifacts. Since they will still be available in other configurations. That is why we generally advise to use the “Deleted” attribute approach and implement the filtering of non-deleted artifacts.
Installation of IBM (Engineering Lifecycle Management) ELM
This article describes our experience in implementing the ELM (Engineering Lifecycle Management) product from IBM.
Introduction
IBM ELM applications are the leading platform for complex product and software development. ELM extends the standard functionality of ALM products. It provides an integrated end-to-end solution that offers complete transparency and tracking of all technical data, through requirements, testing and deployment. ELM optimizes collaboration and communication between all stakeholders, improving decision-making, productivity, and overall product quality. This product has undergone a significant update and has also changed its name from CLM (Collaborative Lifecycle Management) to ELM (Engineering Lifecycle Management).
The main differences between CLM and ELM relate to the change in product names:
- Rational DOORS – in ELM it is called IBM Engineering Requirements Management DOORS Family (DOORS)
- Rational DOORS Next Generation (DNG) – in ELM it is called IBM Engineering Requirements Management DOORS Next (DOORS Next)
- Rational Team Concert (RTC) – in ELM it is called IBM Engineering Workflow Management (EWM)
- Rational Quality Manager (RQM) – in ELM it is called IBM Engineering Test Management (ETM)
- And many more...
Since version 6.0.6.1, the user interface has already changed. However, some applications have not had their names changed, such as Report Builder, Global Configuration Management, Quality Management, etc.
Other differences between CLM and ELM include the fact, that ELM supports different web application servers, operating systems, and databases. For maximum flexibility in adopting new advanced features and to simplify potential future migration to or from:
- IBM ELM on Cloud SaaS
- IBM ELM as a Managed Service
- IBM ELM containerized on RedHat OpenShift, which is currently under development
The current version that we are installing is 7.0.2 SR1 (ifix15). This product is primarily aimed at customers in the fields of healthcare, military, transportation and many other critical areas of industry and manufacturing. Among the main common requirements in these areas of the industry is speed, reliability, flexibility, and security. For the effective and reliable functioning of the ELM solution, initial analysis of requirements and planning is important.
Challenges
After defining the client's requirements (required applications, architecture), the actual deployment of the ELM product is approached. During the design, we consider the client's requirements, adapt the architecture to the already existing infrastructure with the technical requirements of the ELM product. The ELM product supports implementation on Linux (RedHat), Windows and IBM AIX operating systems.
IBM ELM offers several applications, some of which are listed below:
- JTS (Jazz Team Server)
- CCM (Change and Configuration Management)
- RM (Requirements Management)
- QM (Quality Management)
- ENI/RELM (IBM Engineering Lifecycle Optimization - Engineering Insights)
- AM (IBM Engineering Systems Design Rhapsody – Model Management)
- GC (Global Configuration Management)
- LDX (Link Index Provider)
- Jazz Reporting Service, which includes more applications:
- RS (Report Builder)
- DCC (Data Collection Component)
- LQE (Lifecycle Query Engine)
- JAS (Jazz Authorization Server)
- RPENG (Document Builder) – which is implemented as a separate application/system
For large infrastructures, we recommend implementing each application on a separate server. That, however, significantly increases the financial requirements. For fewer lower requirements on ELM, we look for the best possible balance between performance and reliability, taking into consideration their possible financial constraints to achieve the best results. The optimization of the IBM ELM solution can also consist of the fact, that several applications will be deployed on one server at the same time. The implementation of multiple applications on one server is used for less frequently used applications. Based on our experience, we have verified the following logical arrangement of applications on servers (ASX):
- AS1: JTS, LDX, GC
- AS2: QM, CCM
- AS3: DCC, RPENG
- AS4: LQE, RS, RELM
- AS5: RM
For a better understanding of the architecture, the following figure shows a proposal for a possible logical topology:
Preferred Solutions
The recommendation for large customers is to install each application on a separate server, if the technical and financial limitations of the customer's environment allow it. However, this results in increased costs for the server, which consist of installations, licenses, upgrades, and "resources" necessary for the operation of the given solution.
For small and medium-sized customers, based on an initial analysis, we recommend installing less-used applications on a shared server. However, over time, problems with memory and system resource utilization may occur. With a properly designed architecture, these applications can be partitioned without data loss. For detection, prevention of problems and future planning, the deployment of a monitoring system is reccomended.
From the result of the initial analysis, it is determined which application will be installed separately on the server. It is also advisable to install applications on separate servers that the customer uses regularly and contain thousands to millions of requests. Other, less computing and memory-intensive applications can be redistributed so that they can share computing and memory performance.
An essential part of every ELM deployment is the JTS application, which ensures the connection of individual applications. The recommended deployment of ELM packages in the infrastructure is to use IHS (IBM HTTP Server), which is configured as Reverse Proxy.
A necessary part of the solution is the implementation of the database server. The database server stores most of the data, so it is vital to pay extra attention to it when deploying and choosing a suitable product. The basic databases included in the installation include Apache Derby, which is intended primarily for testing purposes with a maximum of 10 users. This database is not intended for production environments and therefore we do not recommend it. Databases suitable for both production and testing include:
- IBM DB2
- Oracle
- Microsoft SQL Server
If the installation is carried out on the cloud, it is preferred to use the DB2 database. In the case of large companies, the Oracle database is more suitable. The use of these databases directly depends on the number of users and the amount of user data.
The use of these databases directly depends on the number of users and the amount of user data.
After the product is installed, we address the implementation of user authentication and security. For basic security, the WebSphere Liberty basic registry is used, which is available immediately after installation, but this option is recommended for testing purposes only. Other authorization options are, for example, the use of the LDAP protocol, which can be supplemented by the installation of JAS (Jazz Authorization Server). With the LDAPS authorization option, users are authorized using a hierarchical user structure. JAS extends the solution with the OAuth2.0 protocol. This solution also offers to authorize third-party applications.
Specialized solutions, approached and tips
From Softacus' point of view, we try to adapt to customers and carry out installations according to their usual standards. Based on the client's requirements, Softacus can work remotely, in the case of customers from critical infrastructure, we can also work on-site. VPN (Virtual Private Network) technologies are used for safe use.
During installations, it is necessary to ensure that installed IBM ELM applications do not have access to environments they are not authorized for. Attention should also be paid to the installation of applications that are listed as "package" (an application with a set of sub-applications to choose from - the client chooses which sub-applications he needs). After installation and subsequent setting of the environment, it is necessary to verify the functionality of the system, which is assisted by the testing team (Softacus).
One of the last steps after performing the installation and securing the server communication is to think about data backup. With customers, it is necessary to think about a "disaster recovery" plan, and it is also necessary to plan regular data backups to secure data against loss or system failure. Monitoring is an essential part of every infrastructure nowadays. Monitoring helps with prediction and improves response to adverse events on servers and applications.
Conclusion
ELM product implementation includes analysis, planning, deployment, and continuous monitoring. At Softacus, we work on improvement and efficiency during the entire course of the solution. It is a continuous and complicated process, during which it is possible to implement new functionalities and extensions into the customers' environment.
DOORS Next provides great functionalities for managing requirements within your team, but as your project grows sooner or later you need to export and import the data using external formats.
For DOORS Next data the first format to think of is project template (or component template, in case if configuration management feature is enabled in RM). Content of template can be set up to include different types of data but all items of included types will be included to a template (e.g. you can include artifacts to a template - and it means that all folders will be added to a template).
Another option is the ReqIF package - it allows interchange requirements between requirements management platforms which are compatible with ReqIF, with more data selection options (e.g. you can include only certain artifacts or modules).
Excel/CSV format is also an option to export and import data to DOORS Next, and this article provides some details on these functions.
The purpose of this article is to describe several cases of Excel/CSV import and export, prerequisites and limitations.
The very first thing you need to know - which fields are mandatory for importing the data to DOORS Next via spreadsheets and their meaning. The best way to get these fields is exporting the data from DOORS Next, and here is some explanation for them. For the basic case (extended case is explained below) you need to have following attributes as columns of a spreadsheet:
- Artifact type - must be existing type of an artifact
- Name or Primary Text - either name or Primary Text must be included to the spreadsheet. If you include Primary Text - the value of Name attribute will be updated automatically (this is basically how DOORS Next works)
If you want to update existing requirements via Excel/CSV file - you need to include an ID attribute column. In this case you can use an ‘update’ option and values in the ‘ID’ column will be checked against IDs of existing artifacts.
If you want to update module content - e.g. module structure (insert new artifacts to a module and or change order of artifacts) - you need to include module specific attributes to a spreadsheet. They are:
- isHeading - boolean value, related to module specific option of an artifact, regardless of artifact type
- parentBinding - ID of parent artifact for the current. The value is empty if an artifact is on the top of module hierarchy or contains ID of ‘parent’ for the current artifact (e.g. Heading of a chapter to which current artifact is related)
- Module - ID of a module, which will be the same for all rows in a spreadsheet because import to a module is pointed to a certain module
You can use Excel/CSV import for links creation, and here there are options. The very straightforward option is to literally insert links directly. In this case you can use a spreadsheet column to build a link to another item (either another artifact in DOORS Next or workitem in EWM application or test artifact in ETM). For EWM and ETM this is the main option, you can better understand the format of a spreadsheet after exporting some samples. It can help you to build your spreadsheet for importing links either for base artifacts or for artifacts in a module - depending on the import option you use.
For links to other DOORS Next artifacts you can use Excel/CSV to prepare your requirements for linking via ‘Link by Attribute’ feature. In this case you need to have a special attribute which is supposed to hold IDs of artifacts to be linked. And you can fill values of this attribute via spreadsheet.
Depending on your linking policy and needs (linking to base artifacts or linking to artifacts in certain modules) you will use either IDs of artifacts you need to link to (e.g. 12345 is an ID of artifact you want to build a link to) or pairs of module ID and artifact ID (e.g. 23456.34567 - where 23456 is ID of a module and 34567 is ID of an artifact in this module when you want to create a link to a modular artifact). After successful import of these values you can proceed with using the ‘Link by Attribute’ feature.
You can use Excel also to import primary text with complex formatting (fonts, colors or even tables) but the source must be also DOORS Next. Formatting in this case is handled via cell note. Another case is embedded artifacts import - in this case spreadsheet includes a link to an embedded artifact which must be already existing on the server.
A few general tips which could help you when working with Excel/CSV import and export:
- Use column names from exported spreadsheets to be sure they are right
- If you are importing values of modular artifacts (pairs of IDs separated with dots) - check format of cells, by default they might be decided by Excel as numbers with decimals and therefore cut
- If you are sure you are doing everything right but import fails - try switching to English locale
- If you need to exclude some artifacts from a module - be sure to keep the ‘METADATA’ section from the initial state of a module (it includes list of IDs of artifacts), otherwise ‘delete artifacts from the module’ option won’t work
Excel/CSV import and export feature can help you in various cases, both as a standalone option or combined with other functions of DOORS Next. Reach us to know more and get support with your special case.
Introduction
Configuration Management has always been a difficult problem to solve, and it tended to get more and more difficult as the complexity of the products increased. As end-user expectations evolve, development organizations require more custom and tailored solutions. This introduces a necessity of effective management of versions and variants, which introduces more sophistication to the problem. The solution to being able to manage a complex product development lifecycle in this sense also requires a solution in a similar sophistication level.
The complexity of the end-products and being able to be tailored for the end user are not the only concerns for system developers. What about increasing competitive pressures, efficiency, etc.? These also have increasing importance when considering developing a system.
Challenges in Product Development
Of course, when we talk about developing a system, we should think about how companies will be able to develop multiple products, share common components, and manage variants, product lines, and even product families, especially if this system needs to be able to answer many different types of user profiles, expectations, needs, and so on.
One main concern for such companies is how to optimize the reuse of assets across such product lines or product families for effective and efficient development processes. Such reusability may introduce new risks without being governed by effective tools and technologies. For instance, a change to a component in one variant or one release cycle, may not be propagated correctly, completely, and efficiently to all other recipient versions and variants.
This may result in redundancy, error-prone manual work, and conflicts. We do not want to end up in this situation while seeking solutions for managing product lines, families, versions, and variants. In this article, we would like to provide a brief explanation of how IBM Engineering Lifecycle (ELM) Solution tackles such challenges by enabling a cross domain configuration management solution across requirements, system design, verification and validation, and all the way down to software source code management.
This solution, Global Configuration Management (GCM), is an optional application to the ELM Solution, which integrates several products to provide a complete set of applications for software or systems development.
The Solution
Global Configuration Management (GCM) offers the ability to reuse engineering artifacts from different system components with different lifecycle statuses across multiple parts of the system. Stakeholder, system, sub-system, safety, software, hardware requirements, verification and validation scenarios, test cases, test plans, system architectural design, simulation models, etc. can be reused as well as configured from a single source of truth for different versions and variants. Each of these information sources above has their own configuration identification as per their domain and lifecycle. One main challenge is to combine all these islands of information into one big configuration.
Fig1
In the example above, there are 3 global configurations:
- A configuration which was sent to manufacturing, the initial phase of the ACC (Adaptive Cruise Control)
- A configuration where the identified issues are being addressed (mainly to fix some software bugs)
- And a configuration on which engineering teams are currently working on to release the next functionally enriched revision.
All these configurations include a certain set of requirements; test cases relevant to those requirements which will be used to verify the requirements; a system architecture parts which satisfies the requirements and will be used during the verification process; and if the system also includes any software the relevant source code to be implemented.
Of course, the sketch above can be extended to a full configuration of an end product, for instance a complete stand alone system like an automobile. In this case, we define a component hierarchy to represent the car. For a reference on component structures for global configurations the article from IBM here can be used.
In such applications of GCM a combination of components of the system and streams can be used to as follows to define the whole system:
Fig 2: Image from article: "CLM configuration management: Defining your component strategy" - https://jazz.net/library/article/90573
In such examples, the streams represented as right arrows on an orange background (global stream: 
) correspond to a body part of the system and is constituted by several configurations of relevant domains. For instance, an “air pressure sensor” is defined by a set of requirements for this part, as well as a system design for the sensor and its test cases to verify the requirements. All these domain level, local configurations correspond to different information assets. The global configuration can be defined in such a way that if a different configuration is defined for Ignition System ECU (different baseline is selected for Ignition System ECU Requirements, Test Plans and Cases and Firmware) we end up with a different variant of the system. This effect is illustrated in the figure below:
Fig 3: Developing 3 different variants at the same time, facilitating reusability.
We may have a base product and different variants being developed to this base product. The variants may share considerable commonality, and they are based on a common platform. This platform is considered as a collection of engineering assets like requirements, designs, embedded software, test plans and test cases etc.
Effective reuse of the platform engineering assets is achieved through the Global Configuration Management application. Via GCM, ELM can efficiently manage sharing of engineering artifacts and facilitate effective variant management. While a standard variant (or we can call it also as Core Platform) is being developed (see Fig 3), some artifacts constituting specifications, test cases, system models and source code for sub systems, components or sub-components can be directly shared and reused, while others may undergo small changes to make a big difference. Sometimes there might be a fix that surfaces in one variant and should be propagated through other variants as well because we may not know if that variant is affected by this issue or not. Such fixes can easily and effectively be propagated through all variants making sure that the issue is addressed on those variants as well. This is because all artifacts regardless of being reused or changed, are based on one single source of truth and share the same basis. This makes comparison of configurations (variants) very easy and just one click away.
ELM with GCM manages strategic reusability by facilitating parallel development of the “Standard Variant” (Core Platform) and allows easy and effective configuration comparison and change propagation across variants.
Tips and Best Practices for GCM
The technology and implementation behind GCM are very enchanting. Talking about developing systems, especially for safety-critical systems, a two-way linking of information is required. Information here is any engineering artifact, from requirements to tests, reviews, work items, system architecture, and code changes.
So one should maintain a link from source to target and also the backward traceability should be satisfied from target to source. How is this possible with variants? There must be an issue here, especially when talking about traceability between different domains, say between requirements and tests.
To be more specific, let's look at a simple example:
In this example, we have two variants. The initial variant is made of one requirement and a test case linked to that requirement. Namely, "The system shall do this," and the test case is specifying how to verify this. The link between the requirement and the test case is valid (green connection). Now, in the second variant, we have to update the requirement. Because the system shall do this under a certain condition. Both requirements have the same id. They are two different versions of the same artifact. We can compare these configurations and see how the specification has changed from version 1 to version 2. But now, what will happen to the link? Is it still valid? Is the test case really testing the second version of the requirement? We have to check. That is why the link is not valid anymore in the second variant.
The team working on the first variant sees that the test case exactly verifies version 1 of the requirement. But the team working on the second variant is not sure. There is a suspect between the requirement and the test case because the requirement has changed. How is this possible with bidirectional links? Actually, it is not. Because it is supposed to be the same link as well, like it is the same version of the requirement. So we also kind of version control the links. However, if we anchor both sides of the links to the different artifacts on different domains, creating two instances for the same link is not possible. ELM enables this by deleting the reverse direction of links when Global Configuration is enabled and maintains the backward links via indices. This is the beauty of this design. Cause links from source to target exist but, looking backwards, are maintained by link indices, which makes the solution very flexible for defining variants and having different instances of links between artifacts among different variants.
There are some considerations to make when enabling Global Configurations in projects. The main question I ask to decide whether to enable it or not is, do I need to manage variants? How many variants? Is reusability required? Answers to these questions will shed light on the topic without any second thoughts.
Then what is a component, how granular should it be, how to decide on streams and configurations. What domains should be included in GC, when to baseline, definition of a taxonomy for system components. Would also be typical questions on designating the global configuration environment. The discussion of this topic requires a separate article to focus on. Let's leave that for next time, then.
Conclusion
IBM ELM’s Global Configuration Management (GCM) is a very specific solution for Version and Variant Management and is designed to enable Product Line Engineering, by facilitating effective and strategic reuse.
With GCM implemented, the difficulties around sharing changes among different variants disappear, and every change can be easily and effectively propagated among different product variants.
GCM mainly helps organizations reduce time to market and cost by reducing error prone manual and redundant activities.
It also improves product quality by automating the change management process which can be used by multiple product development teams and multiple product variants.
References
In IBM DOORS Next, there is a special artifact format called "file", in this article you can learn what it is and how to work with it
Learn about the predefined and custom OSLC Links, Link Types and Hyperlinks in IBM DOORS Next.
Learn about the possibilities of creating Terms, Abbreviations, Acronyms and Definitions in IBM DOORS Next
Aeronautics & Space Innovative Technology Summit (AITS), Bremen
AITS Bremen will gather industry suppliers and OEMs, R&D centers, associations and clusters, academia, and public and private organizations to identify further business opportunities and develop partnerships.
More information at https://bremen.bciaerospace.com/
Maximo Wednesday Webinar | Making the Business Case for Maintenance Technology
With emerging technologies in Edge, Digital Twin, Asset Performance Management (APM) and AI/ML, how can your organization justify their business value and make the case for investment? What are the new measures and KPIs your organization should be tracking to reinforce the justification of these emerging technologies?
Join us to learn how we can help you make the business case for 21st Century maintenance and reliability.
Tom Woginrich is a Principal Value Consultant in the IBM Sustainability Software division. He is a subject matter expert in Asset Management best practices and has worked with many companies to transform business processes and implement technology improvements. Mr. Woginrich has over 30 years of Asset Management experience leading and working in large enterprises. He has a broad range of industry experience that includes Pulp & Paper, Energy & Utilities, Chemicals & Petroleum, Automotive, Oil & Gas, Life Sciences/Pharmaceuticals, Facilities, and Semiconductor Manufacturing.
His working experience and knowledge in operations, field services and maintenance give him a very broad comprehension of the total asset management lifecycle and the value opportunities contained within. It is this background, together with his experience managing and deploying technology, that helps him facilitate the business value case conversation that should accompany technology implementations.
Location
More...
IBM Instana with Cloud Pak for Integration 2022.4.1
Leif Davidsen - Program Director, Product Management, Cloud Pak for Integration
Leif Davidsen is the Product Management Program Director for IBM Cloud Pak for Integration. Leif has worked at IBM's Hursley Lab since 1989, having joined with a degree in Computer Science from the University of London.
Andy Garratt - Technical Product Manager, IBM Cloud Pak for Integration
Andy Garratt is an Offering Manager for IBM’s Cloud Pak for Integration, based in IBM’s Hursley labs in the UK. He has over 25 years’ experience in architecting, designing, buildingand implementing integration solutions for customers around Europe and around the world and loves to meet users, IBMers, partners and customers to find out about all the great things they’re doing with IBM integration products.
Webinar: Lass uns über Application Performance reden!
In diesem Event erfahren Sie wie Instana die Überwachung und Verwaltung von Microservices in Ihrem gesamten Tech-Stack vereinfacht. Wir zeigen Ihnen wie Sie App-Ausfälle, langsame Anwendungen sowie Webseiten minimieren und Probleme beheben – ideal für agile DevOps-Teams.
Machine-Learning generierte Echtzeitanalysen, Visualisierungen und automatische Benachrichtigungen über die Leistung Ihrer Anwendungen und Webseiten helfen Ihnen stets informiert zu bleiben.
Das Fazit von Instana:
• Alles automatisieren – von der Erkennung bis zur Fehlerbehebung
• Modellieren der gesamten Stack-Umgebung und Erkennen von Änderungen in Echtzeit
• Sofortiges Feedback und Lieferung aller relevanten Daten für schnelle und intelligente Maßnahmen
Überwachung von Cloud-nativen Anwendungen in jeder Cloud-Infrastruktur, Testen und Verifizieren von Apps-Rollouts, reibungslose Migration zwischen unterschiedlichen Umgebungen ob Private, Public, Hybrid oder Multi Cloud... oder ganz einfach: IBM Instana Observability.
Sprecher:
Dr. Henning Sternkicker ist seit über 20 Jahren innerhalb der IBM als Technical Representative für Themen im Bereich Software-Entwicklungswerkzeuge zuständig. Angefangen bei Software Configuration und Change Management, über Continuous Deployment und DevOps Tools. Seit 2021 beschäftigt er sich speziell mit dem Thema Observability bzw. Application Performance Management und allen Themen rund um das IBM AIOps Portfolio.
Jan Jancar ist Geschäftsführer der Softacus AG. Jan und sein Team bei Softacus sind seit Jahren ein bedeutender Geschäftspartner in den Bereichen Systems Engineering, Jazz Platform und Automation. Jan ist seit vielen Jahren ein vertrauenswürdiger Berater in diesem Bereich und ein Vordenker und Redner zu diesem Thema. Jan hat mit anderen Partnern auf internationaler Ebene zusammengearbeitet, auf IBM-Veranstaltungen gesprochen und sich für die Lösungen von IBM eingesetzt.
Melden Sie sich unter diesem Link an:
On-demand Webinar: How AI is helping organizations emerge stronger from COVID-19
Over the last few months, we’ve seen the role of AI grow from an important technology tool to truly a force for good. From automating answers to symptom and other citizens questions to finding insights in public data, AI has helped people deal with an unprecedented challenge at a scale never before seen.
But as organizations and individuals emerge from this pandemic, we see the role of AI continuing to be critical – not only to respond to what’s happening today, but to plan for an uncertain future.
Join our panel of AI experts and business leaders as they share key learnings from the past few months and what organizations can do to prepare for and manage future changes with AI.
More information here
SRP: The Data Difference – How Maximo Mobile and QR Code Labels Save Time and Transform Outcome
