One of the most asked questions that I get when I talk to large global institutions, enterprises, healthcare or other larger organizations about managing their application testing process is: “What is the best way to organize my application owners? How do other businesses do it?”
This has always been an important question — but recently, the hows, whats, and whys of your app management organizational team structure have taken on a completely different dimension. As organizations are increasingly managing hybrid environments consisting of legacy business applications mixed with software-as-a-service and cloud computing, the frequency and complexity of packaging and testing cycles have skyrocketed and, therefore, constant diligence is critial to stay afloat.
In the last decades, you were rolling out a new Windows OS every three to four years. Now, you run updates every six months. These have to be coordinated with the Office 365, Windows 10 Server, and SCCM updates. Add in other third-party business applications, like Bloomberg, that require monthly updates, and you have complete chaos.
[For more IT automation ideas, check out our resource guide “12 Ways The Fast And Bold Use IT Automation To Achieve Evergreen”.]
Modern IT Managament Requires An Agile, Evergreen IT App Management
To avoid mayhem, you will have to manage your applications differently. Modern IT management requires a more agile, Business-as-Usual application management approach that certifies, packages, and tests applications strategically on an ongoing basis — rather than in a once-in-a-while overhaul.
IT also has to deal with invasive application sprawls caused by Shadow IT organizations who purchase and maintain applications separate from central IT. As you can imagine, an operation like this has to be run like a tight ship with clear responsibilities, rule-driven workflows and automation.
If you’re managing your application packaging and testing in-house, you will need to decide how you will structure your app management team as well as organize your application owners.
In most organizations, product owners aren’t part of your application packaging and testing team, but rather non-technical end users in business units with extra responsibility. They submit requests to facilitate the packaging (technical work) to the packaging team who will than script up the product for the delivery to the users.
Product owners can be designated to manage the lifecycle of individual products, by product suites, or by a combination of both:
- Product Owner Per Product (e.g., Adobe Reader)
- Internal, custom-developed product
- External, commercial-off-the-shelf product
- One Product Owner Per Product Suite (e.g., Adobe Captivate)
- Internal, custom-developed product suite
- External, commercial-off-the-shelf product suite
Some enterprises consider splitting their app management by regions or business units. However, since most applications should be centrally managed because they will be used by your global workforce, we will take a closer look at the two options presented above, as those are your most likely options. And even if some products need to be managed by business unit or regional teams, the same principles apply. Let’s have a look at each in more detail.
Product Owner For A Single Product
In this scenario, you have one Product Manager or Product Owner as the owner of a single internally custom-developed application or an external “Commercial Off The Shelf” (COTS) product, such as Adobe Reader.
Since the product owner would look after his or her product and know all the intricacies of it, he or she might be the the product owner, the technical Subject Matter Expert (SME), and the responsible User Acceptance Testing (UAT) person all rolled into one. Internal and external apps can have client component desktop installs or client and server installs.
The advantage to this approach is that the product owner knows this product very well and has the required business context in which the software will be used — which enables them to run an actual application test following a natural test script.
Product Owner For A Suite Of Products
Alternatively, you can also have a product owner be responsible for a top-level product suite, whether this is an internally developed software or a third-party application. A great example for this approach is Adobe Captivate, an eLearning solution that leverages a variety of Adobe products to make it work.
The product owner may be the technical Subject Matter Expert (SME) for this product suite or he/she might have an additional resource for that. However, since there are several products to maintain, there will be most likely one or more dedicated UAT testers to cover user acceptance testing of all associated products in their domain — which can also be aligned by geographic or by business function.
How To Organize Your Internal Product Owners
Most larger enterprises will use one of these approaches or a combination of them. In very large organizations or for more complex products, it is common that a product owner has one dedicated technical SME fit and one or more UAT testers. UAT dedicated test owners can also be aligned by geographic or by business function.
Regardless of whether the product owners are responsible for a single product or they own an entire product suite, it is common to have a separate technology arm that looks after the product management, the technical subject matter expertise and the user acceptance testing as the organizational setup. This division purchases and supports the product. However, more often than not, the business units are the ones that actually sign off on the testing.
Usually, these organizations have a full blown Change Management Database (CMDB) as well as a managed asset inventory. While the exact organizational setup can vary from organization to organization, there usually is some form of product ownership and assigned contacts which is incredibly important to keeping things organized and manageable — especially if you are using IT automation.
Why A Formal Organizational Setup Is Beneficial For IT Automation
Let’s say you just migrated to Windows 10 and you are running Office 365, Windows 10 Server, SCCM, Bloomberg, and many more applications. With Microsoft’s expedited service models as well as constant updates with software-as-a-service, you have to juggle different support cycle timelines and application packaging and testing requirements.
If you have a dedicated contact for the roles of product owner, subject matter expert, and UAT tester stored in a central database, you could not only create email notifications for the appropriate person which let him or her know it’s time to test his or her app, but you could also automate a large portion of this process.
For example, with Access Capture, you can run through an automated discovery stage that auto-creates documentation and then routes the packaged application to the responsible tester. It will notify him using email, including login credentials, for a newly spun-up virtual machine that has everything the tester needs. If the app passes the test, it will get recorded as passed. Otherwise, it gets routed back to manual packaging.
