I was the IBM® DOORS® Product Manager for nearly 20 years and the roller coaster journey was fun. I started by managing the creation of an integration between DOORS and Mercury TestDirector and eventually picked up the DOORS family, working with Telelogic and then on to the acquisition by IBM.
How did DOORS become a market leader?
“If Bill Gates can have Windows, I want to have DOORS. Now tell me, what does DOORS mean?”
Initially created by QSS and then Telelogic, DOORS was the market leading requirements tool in the 1990s and into the 2000s. Industry analysts moved focus to application lifecycle management (ALM) solutions in the 2010s and it was difficult for any vendor to claim a defined market share, let alone market leadership.
Three decades ago, it was possible to persuade prime contractors to mandate use of a single tool across their entire supply chain. With early success in the UK defense industry, DOORS became the market leading requirements tool; in the early 90s there was only two tools to choose between. Rational® entered the requirements business in 1998 and held 2nd place in the market.
The acquisition of Rational and then Telelogic into IBM saturated the requirements market from a single vendor, spread over four different requirements solutions: DOORS, Requirements Composer, Requisite Pro, and Rational® DOORS® Next Generation. Only two now survive to make up the DOORS family.
Where are we today with requirements management solutions?
Working styles have changed dramatically since the 90’s and teams are being asked to move fast and work collaboratively with teams across the organization. In order to satisfy this new way of working, requirements management vendors needed to adapt and invest in the interface and useability of their products.
Users are demanding ease of use so more people can enter information directly into a tool rather than sending Word or Excel documents to a tool user for import.
The industry has changed. It’s no longer possible for an OEM (Original Equipment Manufacturer) to mandate a single product or vendor across supply chains and in fact, standards such as ReqIF (exchange) and OSLC (integration) have come about to help products work better together. Again, this requires investment from the vendors so that interoperation does not sit just within a single tool chain.
What’s next after DOORS?
Requirements management has been accepted by the engineering industry as an essential discipline, no matter which process is used, or which type of system is being produced. What changes is the level of formality adopted (process), or regulation needed to be complied with (industry standard).
Best practices for systems engineering have been prescribed in many industries. It’s not just about DO178 or ISO 9001, we now see engineering regulation or compliance needs in automotive, medical, finance, and many other industries.
It is no longer possible for a single product or vendor to drown a marketplace. We have different users wishing to make their own decisions about which best of breed solutions are right for their organization. One tool will not fit all user’s needs. An organizations investment in their data is far more than the investment they make in tools, and the focus now comes down to availability of data and how that flows across an engineering community (integration) and the value chain (exchange). Don’t forget, it’s your data – not the vendor’s!
In summary
I have seen that there is life after being the Product Manager for DOORS and have chosen to work with a vendor (Jama Software) that has a single focus on engineering, reinvesting revenues into their products and therefore, investing in their users. Let’s see where this next roller coaster takes me. One thing I know for certain, there’s more fun ahead!
https://www.jamasoftware.com/media/2021/05/2021-05-24_life-after-doors-1024x512-1.jpg5121024Richard Watson/media/jama-logo-primary.svgRichard Watson2021-05-24 03:00:232023-01-12 16:49:10Is There Life After DOORS®?
Now that we’ve covered some of the reasons to make the switch, how do you go about migrating to a modern requirements management solution while minimizing business disruption? The process of migration does not have to be daunting.
Jama Software offers four key migration solutions to support companies in their migration from a legacy requirements management solution like IBM® DOORS® (IBM Engineering Requirements Management – DOORS Family) to Jama Connect. These flexible solution components allow customers to replace legacy solutions, co-exist with these legacy systems, or simply use Jama Connect and connect to the customers and suppliers using legacy requirements management tools.
Customers leveraging our migration solutions will work with Jama Software consultants to adapt Jama Connect to fit their individual product delivery process, identify and migrate required data, and train teams to quickly achieve sustainable results.
Let’s review each of the migration solution options:
Jama Connect Import
Our most-used method of importing requirements data from DOORS into Jama Connect directly is the Jama Connect Import Tool. This solution can be easily accessed through the Import Directory which allows data to be pulled directly into Jama Connect, downloading an HTML set of images. There is no additional fee and this option is included in the standard purchase of Jama Connect. Instructions for using the Jama Connect Import Tool are covered during the services onboarding phase of the implementation. When data is simple and the volume of data is moderate, this is a good migration option.
Data Exchange Services allow you to manage requirements across suppliers and customers without necessitating online data integration, which in turn reduces data duplication by leveraging round trip exchange. This service allows customers to operate within a legacy ecosystem while adopting a modern requirements management tool within select departments and across organizations where legacy requirements management (like IBM DOORS) is the standard.
Data Exchange for Jama Connect allows the import of modules or sets of modules in the industry standard ReqIF format directly into Jama Connect from legacy RM tools. This solution takes a level of permissions to export the data from DOORS into a ReqIF file. In order to import data into Jama Connect, it is possible for this tool to be extended and customized to meet specific client needs.
DOORS Migration Engine
Powered by Sodius, the DOORS Migration Engine was created to help support customers with more complex requirements data, or those who have large volumes of data, as they migrate from a legacy solution to Jama Connect.
The DOORS Migration Engine extracts directly from the old data in legacy RM tools and imports it into Jama Connect. This scales to manage large loads of data migrated from solutions like DOORS 9.X to Jama Connect. Customization is possible with this migration solution to support any unique data requirements for customers.
REST API
Customers can also perform the data migration on their own using the Jama Connect REST API. This option scales from small to enterprise customers. For those who choose this option, it’s important to mention that even though you are handling the data migration on your own, Jama Software’s Professional Services team is available to assist customers through this process.
Whichever path you choose, switching to Jama Connect requires a migration approach that scales to your people, process, and data. It’s not just about migrating the data from one database to another; onboarding and training teams on the new solution is also a critical component to long-term success.
Migrating off of a legacy RM tool takes planning. And regardless of which migration solution you choose, we’re here to support you throughout your transition and help you figure out the best way to use Jama Connect, and not just recreate the clutter of your existing legacy tool.
IBM® Rational DOORS® has been around since the early ‘90s and has served many teams well in the past. But in today’s web-based, interconnected world, if you’re still using DOORS, your requirements are likely stuck in a siloed Windows application. It’s time to retire DOORS and move to a modern requirements management solution. Here is a hands-on guide for a painless data migration from a legacy requirements management solution like DOORS to Jama Connect®.
Software Migration Prep Work: Start by Taking Inventory
Before you begin your software migration, start by screening your DOORS data to get a rough overview of the work ahead of you. Collect key metrics of your current system:
How many DOORS modules do you have?
How many objects (items) reside in each module? Average? Maximum? Minimum?
How many attributes do your modules have, and how complex are they? Again, look at average, maximum, minimum, and also whether you use DXL attributes.
How many DOORS projects and folders?
How consistent is your data? Do all modules of a certain type (e.g. “User Needs”) have the same attributes?
Do you use any special DOORS features, like DOORS Tables, DXL scripts, or OLE objects?
Decide What to Migrate Where
It is rarely necessary to migrate all your data to Jama Connect. Your data migration typically only needs to include active data, not completed projects. It’s usually not necessary to migrate the history of your data, only the latest version.
Of course, completed projects and version history must not simply be discarded. Rather, you want to keep this information accessible somewhere, at least as long as legally required – this needs to be part of your software migration strategy.
You have the following options for your data migration, and you can mix and match them as you see fit:
You should always make a regular DOORS backup and properly archive it. This data is inaccessible, unless you reactivate DOORS
Active data should migrate to Jama Connect
Completed data should be exported in a format that can be processed without DOORS. This could be a simple PDF (or Office) export
Alternatively, you can export the data using the Requirements Interchange Format (ReqIF). ReqIF is an open standard for exchanging requirements. As Jama Connect supports ReqIF, you could always import that data if needed at a later time
Lastly, you can decide to keep DOORS around on a single license, and ensure all data is accessible
There is always the temptation in a software migration to simply move what you have from point A to point B; from DOORS to Jama Connect.
However, migrating to a new solution is a great opportunity for optimizing your processes and taking advantage of the capabilities of the new solution. This does not mean that you should throw everything out that you built so far. It simply means that you should revisit what you have, remove what did not stand the test of time, and reflect on the underlying use cases to ensure that the underlying problem is solved instead of blindly copying a mediocre solution.
In Jama Connect, this means that you should carefully analyze your existing data to configure frameworks for the various types of projects that you have. For instance, you may have a framework for complex, safety-critical development that follows the V-Model, and another lightweight Agile framework for app development.
A framework in Jama Connect is a configuration consisting of project structure, trace rules, workflow, and permissions that can be used as a template for new projects, as shown in the figure below. You should have frameworks that fit the data you intend to import. After the migration, all projects in DOORS that were “similar” will then follow the framework in Jama Connect, creating improved alignment and consistency.
Data is Easy, Customization is Hard
There is also a good chance that your DOORS system was customized significantly over the years. This is mainly due to the fact that DOORS can be programmed with a scripting language called DXL. While it is tempting to quickly solve a software migration problem by writing a little script, this can create long-term liabilities and maintenance nightmares.
It’s important to understand that no other requirements management tool supports DXL. Therefore, if you migrate to another solution (Jama Connect or otherwise), you will leave DXL behind.
So, rather than providing a scripting language, Jama Software provides an open Application Programming Interface (API). This allows you to perform customizations if necessary, without the liabilities that comes with scripting.
Now that the Jama Connect frameworks are configured and the data identified, it’s time to migrate. We would not recommend your data migration happens all at once, but instead unfolds in three phases:
Phase One: In the preparation phase, you’ll perform a few test imports to ensure the data migrates across correctly.
Phase Two: When ready, you can migrate one pilot project. After evaluating the results (or even better, working for a few weeks in production), you can fine-tune and optimize the import process for subsequent projects.
Phase Three: At this point, you’re ready to migrate the remaining data. It is generally a good idea to keep the overlap — with both DOORS and Jama Connect in production — as small as possible.
The Software Migration Process
Jama Software provides four different facilities for data migration. Whichever one you use depends on your specific situation and the amount of data you need to migrate. All data migration options will maintain formatting and traceability:
Jama Connect ships with a built-in DOORS importer. To use it, you export views in DOORS to HTML, which are then imported. Every module has to be processed by hand, so this path is useful for test imports and small quantities of data (a few dozen DOORS modules).
You can also use Jama Software’s Data Exchange, which works with ReqIF, the Requirements Interchange Format. You can export data in DOORS and subsequently import it into Jama Connect. This scales better as you can process whole projects at a time.
You can also use Jama Software’s DOORS Migration Engine, a set of configurable tools that we tailor to your specific situation, which makes bulk migration possible.
If none of these options works for whatever reason, you can build your own scripts that import data into Jama Connect using our REST API.
DOORS has been a faithful requirements management tool that has served the product development community well for almost 30 years. But in order to stay competitive, it’s necessary to switch to a modern requirements management solution like Jama Connect.
Software migrations are rarely fun. However, when you migrate from DOORS to Jama Connect, it is a rewarding experience, as you end with an intuitive, user-friendly, and team-friendly environment. Plus, as your data gets aligned to the Jama Connect framework during the software migration process, your requirements data will be consistent and synchronized to your team’s processes.
For decades, companies building highly regulated, technically complex products and systems have relied on legacy tools like IBM® DOORS® or even Microsoft® Office® for requirements management (RM).
As software becomes more prevalent in physical products and development methodologies evolve, legacy RM tools like these have struggled to keep up with the modern speed of capturing, sharing, and managing requirements.
See how Jama Connect stacks up to legacy software tools like IBM® DOORS® in our whitepaper.
Legacy tools are powerful, but even with their complex capabilities and reputation for stability, they don’t always match the goals of teams who need to adapt, innovate, and grow.
Noticing this misalignment can surface as painful moments — like when your team struggles to get work done. Sometimes those issues are process or market related, but in some cases they are actually because of the exact software tools you’re using to make your life easier with requirements management.Here are some critical signals that your team is no longer aligned with your legacy solution for requirements management, and how you might consider a change going forward.
Painful Moment 1: You value the input of multiple roles and skillsets, but you realize only a handful of people know how to use your RM tool (or worse, they’re not allowed into it).
Why It Matters: This is a signal that the RM tool was not set up with the whole team in mind. For companies innovating quickly, this lack of visibility into what you’re working on and why is a major risk. If it were possible for only a handful of people to build complex products, teams and companies wouldn’t have the diversity of skills and thought processes they do today.
What to Do: Consider a system that supports the workflow of multiple roles with advanced, user-friendly tools for different data types and views that still all roll up to the same goals. User-friendly traceability is essential.
Painful Moment 2: You miss the deadline for feedback on a requirement because the notification was unclear. Now you have to go outside the normal channels to have your input seen.
Why It Matters: This is an instance not always appreciated by those who wrote the processes. However, with legacy software that doesn’t make the intentions of users clear (such as wanting input by a specific date), it’s hard to avoid miscommunication and lost time.
What to Do: Look for RM tools that make the next action required of you clear and sends timely notifications with clear instructions.
Painful Moment 3: You try to enter data into the system, but it’s locked, archived, or somehow just not visible.
Your decision is blocked. The person you know who provides access and training is unavailable (for example, on vacation… or no longer at the company).
Why It Matters: Having company-mission critical software that only a handful of people understand and have access to is a huge risk for many reasons – some not as obvious. On the lower end of severity, you lose a few hours trying to access the right data. However, if the trend is that fewer people have permissions and training to use your RM tool, then you’re at risk of data being lost or your system eventually needing to be replaced entirely.
What to Do: Data can get richer over time; it doesn’t have to go stale. Invest in requirements management tools that support your team’s continuous growth and capture continuous input and collaboration.
Painful Moment 4: Your team wants to upgrade its legacy software to fix issues, improve security, and access the latest features. Unfortunately, it’s so customized and patched together that you can’t update without major consequences.
Why It Matters: The products you’re building change and improve over time. The software tools you use to get your work done every day need to keep up with you, at a pace that balances change with allowing users time to learn.
What to Do: Consider the risk and costs associated with stale software, and look for options that avoid getting you locked in to unsupported versions and brittle customizations.
There’s a lot of requirements management solutions on the market. Cut through the clutter with our buyer’s guide.
Painful Moment 5: You want to change the way your team uses the legacy software to match a new process, but there are no configuration experts available.
What if you break something? You hope you can create an experiment project on the side that will ultimately integrate back into the big picture, but it’s not clear how to create this outcome.
Why It Matters: If teams are struggling to get on the same page with their requirements management process, it’s a signal that whatever your building may have misalignments as well.
What to Do: Consider RM solutions that balance each team’s need for autonomy with the need for alignment. This can be supported by software that have services experts available to adapt the tools to your needs as you change, rather than one big rollout that attempts to predict the future.
It’s tough to have to work around legacy software to get your job done. It’s also expensive. Maybe you can’t change the RM tools you use on demand, but if you start to notice these painful patterns it becomes easier to build a business case for making a change that supports the whole company’s vision.
https://www.jamasoftware.com/media/2019/09/Blog-Legacy-Part-2.png5121024Robin Calhoun/media/jama-logo-primary.svgRobin Calhoun2019-09-11 04:30:172023-01-12 16:51:26Legacy Sunset: How to Stop These Five Legacy Software Pains in Requirements Management
At Jama, we work with the world’s most innovative companies and government agencies to manage the entire lifecycle of product delivery. They think differently, challenge the status quo, and are constantly looking for new ways to improve product delivery to gain that competitive edge. Unfortunately many find it really challenging to work with a legacy tool that no longer meets their needs. What is the risk to the business? What is the cost to move all the old data to a new solution?
We have built a world-class solution to help you move active data from IBM DOORS to Jama, a lower cost, cutting-edge product delivery platform. Jama’s import capabilities for IBM DOORS include the ability to bring along the requirements, test cases and other information you care about.
Don’t work the old way. Now is the time to move off IBM DOORS. We can help. Bring what you need into Jama, when you need it. The Jama DOORS migration solution will maintain all relationships, so you can easily configure or change any elements.
/media/jama-logo-primary.svg00Jama Software/media/jama-logo-primary.svgJama Software2013-05-15 09:00:272023-01-12 16:56:57Transition from IBM DOORS to Jama in Three Easy Steps
I was the IBM® DOORS® Product Manager for nearly 20 years and the roller coaster journey was fun. I started by managing the creation of an integration between DOORS and Mercury TestDirector and eventually picked up the DOORS family, working with Telelogic and then on to the acquisition by IBM. 
