International SOS: Platform Product Management

ISOS Workforce Resilience Platform Playbook

Research on Platform Transformations

Explore

Research on Platform Transformations

⁠

See Sources⁠

⁠

People & Partnerships

Stakeholders

Who am I serving?

In a typical project we deal with multiple stakeholder types, user types and collaborator types, all of whom “matter” — all of whom we “serve” with our work, whether that be through our process or our results. All of whom come with their own unique perspective

We started our workshop today by ideating on the following 5 groups of people they will ideally deal with in their thesis work:

People their products and services serve directly

People who might help them in their career

People who are within the industry/market/field(s) that their work touches or impacts

People who they seek to make proud

People who they shouldn’t care about the opinions of, but do.

Cost Rationalizing

Rooting out unnecessary—and costly—complexity is made more difficult in many cases by the lack of accounting transparency around niche offerings and products that sell in small quantities. Typically, costs are allocated by share of revenues. But since many specialized models have higher true costs arising from customization and lower production runs, they effectively freeload off more profitable lines. They often require more investment in R&D, tooling, testing, marketing, purchasing, and certification.

To identify hidden complexity costs, companies must dive deep into the data, applying granular assessments to individual components so as to understand the impact of customization or scale on the cost profiles of each model.

Strategy

Product Strategy Canvas

A good product strategy

Defines a long-term vision (winning aspiration)

Is a single, integrated set of choices that reinforce each other and increase your odds of success

Defines the market (problems) and your playing field’s constraints

Focuses on customers whom you can’t control

Has a theory on how to persuade them to do what you want

Explains what competencies, resources, and systems you need

Passes the Can’t/Won’t Test. Your competitors can’t or won’t copy it

Has many levels (organization/division/team)

Allows you to formulate hypotheses

Ways to Consolidate

Consolidation isn’t easy, or quick, which is why it is oft-neglected. The key thing we’re aiming for is a smaller, cohesive footprint; i.e. less to manage. Specifically, we’re looking to identify features that perform similar jobs, and then find opportunities to only use a single one.

As a general rule of thumb, the Consolidation phase is:

Identify the similarities.

Prioritize their importance.

Create a single service to represent all variants of that feature.

Route all existing applications to this new service (e.g. Strangler pattern).

Migrate data to the new service.

Discard the old feature for each application.

Repeat.

Note — Approach to Consolidation

Consolidation probably should not be undertaken as a big-bang. You can migrate one application at a time, prove it works, then move on to the next one. You might begin — for instance — with the most heavily used application, leaving applications marked for deprecation till last (if ever).

Prioritization

“When we think about product teams as a whole, there’s one jar with lots of big rocks. As the company scales, when you start looking at a problem space, you have different focuses and goals. They are relevant, but they’re not always the same size or type. So the jar becomes how leaders define the focus. These are different dimensions you can look at.

Now, as the leader, not only do you need to define the focus, you also need to make sure you understand the resource allocation in order to size the jar. From there, you empower your team with a framework that guides them.”

– Becky Flint on creating the jars of Portfolio Management

⁠

Rock Pebble Sand Management⁠

gives you your high-level needs and allows you to visualize your dependencies so you can easily identify bottlenecks. That makes restructuring teams and adjusting much easier.

Start the Rock Pebble Sand Product Management approach with your jars as this will represent what holds your resources. Define your jars (focus) and jar size (resource allocation) to better understand your company focus that quarter.

The next step is filling your jars with rocks. These are your bigger impact items. By filling your jar with rocks first, you can prioritize easily. Naturally, you can begin to fill up the rest of your jars with pebbles and sand.

Consumer First

When complexity is good, it is targeted, manageable, and linked directly to value creation. When complexity is bad, it creates unwarranted cost, fragmentation, and consumer confusion. The balance lies in understanding how to design the right kind of complexity into a product portfolio while eliminating the wrong kind.

In doing so, brands have an opportunity to give consumers exactly what they want at the right price—with bottom- and top-line impact. At a major beauty company, a portfolio-performance program improved margins and reduced costs by more than 10 percent across about half of the company’s cost base. A beverage company achieved similar cost reductions and increased its speed to market. And a food company successfully expanded margins in a highly competitive subsector while reducing inventory and increasing manufacturing capacity.

Balancing Complexity

The goal of portfolio management is not simply to reduce complexity as much as possible—that would be easy. It is rather about differentiating good complexity, which generates more customer value than it costs (because customers are actually willing to pay for the variance), from bad complexity, which adds complexity without contributing significant customer value (see sidebar, “The good and bad of complexity”).

Some variance and complexity is important for every product portfolio. It helps distribute risks and, when combined with a smart modularization effort, can increase scale effects on a large number of components while also providing customers with choice. However, too much variance and complexity can create their own risks while raising overall costs, such as by generating additional compliance requirements that absorb more management attention than anticipated—or spurring further R&D efforts to maintain the products over their lifecycle.

Change Management

Why Product-Led?

Your company’s product—no matter how unique or superior to a competing product, no matter how affordable or cost-agnostic—isn’t enough anymore. Winning the war for customer acquisition and retention is no longer a product game, it’s a relationship game. The battleground is omni-channel consumer engagement. This requires a holistic view, which can only be achieved by having a complete customer platform.

What’s the difference? The traditional product-based company is a love ’em and leave ’em type of organization, wooing anonymous consumers to make one-off purchases, then abandoning them once they have done so. Platform-based companies build relationships with consumers at the center. These relationships extend beyond a product sale and impact the way people engage with a product long after the transaction is complete.

More importantly, platform companies seek to understand the intent behind the purchase, layering complementary services around their product offering that enhance the experience for the consumer.

“Platform companies seek to understand the intent behind the purchase, layering complementary services around their product offering that enhance the experience for the consumer.”

One company that has done a good job of leveraging their product to extend their relationship with consumers is Gatorade, which is now leading the way for sports brands.

With sales falling behind strong competitors in the sports drink market, PepsiCo implemented a 40% increase in R&D spending in 2011 and 2014 with a focus on building a unique smart cap technology system that would deliver customized formulas, a significant enhancement on their existing squeeze bottle product.

The resulting analytics-driven platform was designed to help athletes better understand their unique hydration needs, and optimize performance. From sodium and electrolyte deficiency to sweat production, Gatorade’s turbine censored smart cap and skin patch are individually linked to each player, retrieving and sending data back to a software program after each sip and sprint, catch or kick. The suite of critical new physical, digital and service-based consumer experiences is built around an established product; designed to better understand, engage with, and ultimately sell additional offerings to its consumer.

Service-Led to Product-Led

In theory, people initially liked the idea of becoming a product-led company, but the effort required to make that change could sometimes be overwhelming. Effecting this change required a comprehensive overhaul of how all departments operated within the company. In service-based companies, the sales force is often localized and specialized within specific regions. This specialization is necessary to ensure that the sales team has a thorough understanding of the client’s business so that they can provide tailored solutions and add value. Conversely, the sales force for product companies operates with a more standardized offering. In addition to in-depth knowledge of the product they are selling, they must also possess a deep understanding of its use cases and target markets.

In the services-led company, sales and customer success folks often dictate what the product team do. “A customer is wanting this now. We’re sure other customers will too. Regardless, we’ve already sold it to this customer. So please go and build it…now!”

A complete change in mindset is required when you’re having to position the value of a standard offering versus being able to do whatever a customer is asking for.

The challenge didn’t just stop with sales and customer success. Our analytics and delivery people were also sceptical as they were bringing their health and analytics expertise to each offering and felt like “productising” this meant we’d lose the creativity they bring to each customer engagement. We addressed this by standardizing the things that drained their time and didn’t require their expertise, allowing them to focus on high-value, complex analysis and consulting.

End of Life Management

Emotions – it's ok. You are human. Learn to manage them…FAST

Clearly articulate WHY a product is being placed in EOL.

Focus on customers

You are not on your own. Create a cross functional team (CFT)

Get executive leadership team sign-off

Determine readiness for execution

Execution = go! go! go!

Check in with the CFT for status updates.

Saying No to Customers

Generalize features.

Know your customer directly, and especially their decision-makers.

Solve problems, not support tickets.

Code as last resort.

Coalesce and stack-rank requests from different stakeholders at the same customer.

Proactively meet with your largest customers about their requests.

Always ask how new requests should be prioritized vs. old ones.

Include your roadmap (as a list, not swimlanes with dates!) in prioritization discussions with trusted customers.

Get your customers together!

Show progress.

Prove that you understand how important the problem is, even if you can't solve it yet.

Propose partial solutions.

Leverage decision-maker vs. team mismatch.

Maybe: empower partners and developers to fill feature gaps.

Charge a lot to influence the roadmap.

Use the “positive no”

Managing Complex Change

Encouraged to ask the following questions:

What is your vision? Why is a change needed?

What skills are needed? Does the team have expertise or training in what they are being asked to do? If not, will it be provided from someone they trust?

What incentives are needed? How will it benefit the team? There is nothing worse than feeling as if time is being wasted on something that does not benefit them directly. Your team need to understand how their work contributes directly to the success of an organization and its mission statement.

What resources are needed? A lack of resources leaves people frustrated. What resources are readily available? Are they appropriate? Are there in-house people who are resources that can assist with implementation

What's the action plan? What is the timeline? Who is responsible for what? How will progress be measured? What are the follow-up steps if there are problems?

Information Architecture & Domain Mapping

Alignment Personas

Alignment personas are hypotheses about who the people that you are building a product for are, and what those people want and need in their own terms. Once alignment personas exist, the executives who helped to create them can see them for what they are: strong hypotheses with deep ties to the reason a business exists in the first place.

Once you have alignment personas, you know what the assumptions are, and you’ve helped the executives align their assumptions. You may hate assumptions, but you have to embrace them if you want to change them.

Domain Mapping

Building a basic model starts with extracting the noun and verbs from the user story to identify the key objects, attributes, patterns, and relationships.

— Alibaba Tech’s Team, in
Making a Case for Domain Modeling⁠
⁠

Getting a Domain Model requires connecting with Domain Experts. Also known as Subject Matter Experts, Domain Experts are individuals with substantial experience in the field. Subject Matter Experts help identify critical entities of the Domain as well as how they relate to each other.

I learned that acquiring Domain Expertise from Subject Matter Experts to build the Domain Model is a journey on its own. In this journey, you develop interpersonal skills that expand and complete your engineering expertise.

In this article, I provide you with a step-by-step guide on how to run a Domain Modeling Interview. It involves those four steps;

Before the interview — Define the goals, contact the experts, and invite them to read this article.

Running the interview — Acquire Domain Expertise and become a junior Subject Matter Expert.

After the interview — Do your homework and connect the dots.

Deliver the Domain Model — Make the Domain Model knowledge durable and available.

Domain Modeling is an iterative process, and you’ll never get it 100% done. Depending on the complexity of your Domain, you’ll need to reiterate the sequence: 1. → 2. → 3. two to three times to get the 80~90% understanding that can get you going.

Service Design

TUG’s co-founder, Dan Klyn, often uses the mantra of "WHAT Before HOW" to encourage us to align on our intent and goals before figuring out how we'll accomplish them. In a similar manner, Lou offers four starting questions to ask as you're designing (or redesigning) a service:

What does the service do?

How does the service work?

Who is the service for?

Why does the service exist?

These are largely analogous to the questions we ask of stakeholders during our Program phase, especially if you replace the word "service" with "product," "website," or "mobile app." (And note that in thinking through the "how" in step two, Lou is referring to the details of how the service works for the end user, not the backend systems and processes that would fall under the backstage category in Service Design Blueprints.)

Many of the other principles reflect best practices from the perspective of those using the service, our customers and users, distilled down to their essence. These include:

Be easy to find

Clearly explain its purpose

Require no prior knowledge to use

Be usable by everyone equally

Be consistent throughout

Structured Content Design

A structured content approach to digital work has a number of advantages over typical “interface first” processes:

Website and app designs are optimized for their actual content

Content is created and stored in a way that allows it to be reviewed, displayed, mixed, and remixed across platforms

Structured content works hand in hand with

component driven architectures⁠

that prioritize user preference, personalization, and adaptability

Content as data is machine actionable, which makes it

better prepared for emerging platforms like voice and AI-mediated experiences⁠

(like Siri, Alexa, and Google Home), and facilitates the integration of natural language processing (NLP) and

knowledge graph technologies⁠

⁠

More than any individual benefit, however, structured content focuses on communicating effectively to an organization’s patrons, constituents, and customers, wherever and however they choose to access content. While it is the cornerstone of effective, scalable content design for the web, structured content design is much more than a “web” technique: it is a way to prioritize effective communication across contexts.

User Experience Design

It is tempting to make UX improvements to features as you port them over. We think you should avoid this. Before you know it you will be wrapped up in product debates about how exactly it should be improved. And where does one stop with these improvements? Instead you should copy the existing system as closely as possible, and maintain a list of potential improvements that you could work on later. Not changing functionality also has the advantage that the same tests can potentially be run against the old and new systems.

Key takeaways

If you are considering a rewrite, or need to bring divergent or duplicate together, it’s worth considering these lessons:

It’s easy (and necessary) to create prototypes or start new projects without a view on their final integration with legacy systems. This shouldn’t be allowed to go on too long.

Green field projects are so productive, they can lure us into a false sense of being the right direction (e.g. productivity gains vs working on existing systems).

Favour incremental improvements to existing systems where possible. If you decide a rewrite is necessary, there are incremental approaches (e.g.

the strangle fig application⁠

) that are less risky than a full rewrite.

The systems we build really do reflect the shape of our organisation, for good or bad (i.e. our real life validation of Conway’s Law).

The latest greatest technology doesn’t always solve the fundamental issues with accrued complexity (micro services, SPAs).

Platform Design & Integration

Five key actions for scaling product and platform transformations:

Build product teams around the end-user experience. An effective organizational approach has often been to build product teams around stages of the customer experience surrounding a purchase, from search to payment, or adjacent capabilities, such as loyalty programs or billing functions. Teams might also be organized around the employee experience, from recruitment to onboarding. In these approaches, the emphasis is on models that can be broadly applied and reused.

Don’t forget the platforms. A well-defined product and platform design can function as the de facto organizational structure (Exhibit 1). Our experience suggests that, since strategic priorities shift from year to year, organizations can anticipate that the design of their products and platforms may also shift by 10 to 15 percent in order to align with strategy.

Reinvent tech funding to make product and platform teams autonomous. The quid pro quo of providing more autonomy to product and platform teams is that the teams commit to clear OKRs linked to outcomes and aligned with the goals of the company. Organizations using OKRs to track progress and dynamically reallocate investments based on performance increase financial accountability, improve control of end-to-end product expenses, and can ultimately capture more value.

Establish joint accountability between tech and the business. Where broad business support for the product and platform transformation exists, a larger scale-up of the operating model and structural changes to it can happen relatively quickly. In other cases, however, initial business champions and early adopters should launch a few teams to start.

Commit to creating a great developer experience. These measures enable developers to seamlessly spin up a platform in minutes, easily consume platform services with multiple consumption models (APIs or GitOps), and rapidly make improvements to platforms through an open-source approach (aka InnerSource) to manage code contribution.

Transformation Prioritization

Assuming that we’ve done all the heavy lifting of discovering the reasons why the legacy architecture is in place, begun the process of building a coalition of interested parties willing and able to bring things into the present, and we’ve sold the company on the benefits of using new and updated technology, we’re faced with the obvious question: now what? Simple -- figure out something small and relatively innocuous you can meddle with that’s unlikely to trigger those fears mentioned above -- revenue and stability. Generally speaking, there are always projects that lie on the periphery of the core platform -- APIs, UIs, and internal tools can be a really great place to start. In fact, with all of those things, you can wire in future goals or needs that can be put in place in a fault-tolerant fashion -- so that when you can light up something new, there’s instant value found in work that you’ve already done.There’s two reasons to start with these small, evolutionary steps. First, they’re usually small projects that can be done relatively quickly, with a small resource impact, and that you can use to demonstrate success rapidly and definitively. Second, you’re not putting any recurring revenue or any of the fundamental stability of the product at risk if you’re updating something that’s already been or needs to be “tacked on” to the underlying platform. Both of these factors allow us to be relatively certain that we’ll be able to show The Powers That Be that new technology isn’t as scary or dangerous as they think, and let us take the next step, then the next, then the next, until we’ve managed to change all of the wheels while nobody on the bus was any the wiser.What we don’t want to do is try to jump right in on something that’s mission-, customer-, or product-critical. Remember that legacy systems are there for a reason -- they’re reliable, they’ve been tested over years of work, and they’re the life-blood of the current system. Messing with those components as a first effort is like performing your first open-heart surgery as a resident medical student...but without any supervision or assistance. You’re equally likely to do something to cause the patient to flatline as you are to succeed in your efforts. We need to minimize the risk that we’re taking on, because we’re trying to assuage fears. And the worst thing that can happen in these early efforts is to make a significant and revenue-threatening mistake. If you approach the problem piecemeal, one small component at a time, you’ll have significantly more success, and each such success will lead to more leeway and flexibility on the next project.Every once in awhile, a new technology, an old problem, and a big idea turn into an innovation.-Dean Kamen, inventor

Putting the Pieces Together

The end goal of all of these efforts and this overall framework is simply to build trust, negate uncertainty, and push the company and product into the present or future where its technology is concerned. This will not happen overnight, and it will not be without struggle and setbacks. As product leaders we need to be diligent in balancing the needs of our existing customers and our existing product’s success and footprint with the need to expand, revise, and improve on our technology. We cannot expect The Powers That Be to bless our efforts at using new and improved technology just because we want it to be; we need to convince them first that it’s the right thing to do, then that it’s the safe thing to do, and finally that it’s what will allow the product and the company to maintain its growth and success in the customers’ eyes. If we can do all of that, then we can slowly chip away at those legacy horrors such that they can be relegated to a small closet in the back room that nobody ever opens again.

Integration Planning

Every type of integration has manual interventions in the process. Self service will require customer support effort and FAQs to be maintained. Custom integrations require project management, design and development capacity, as well as support. These manual interventions incur a cost, both in terms of hours spent as well as opportunity cost for not doing something else with those hours. For each component in the integration landscape, you ask the following questions:

What is the combined contract value of the customers who will use this component?

Can we bring those customers on without this component?

How much additional cost in manual work do we incur when this component is not there?

You start with those components that have the largest answer to the first question. Then you prioritise the ones where the answer to the second question is "No". After that you prioritise the ones that save the most cost as answered to the third question.

APIs - iPaaS

So, what’s different with the next generation of iPaaS solutions? Today’s users have developed certain expectations of how cloud applications should work, and an iPaaS 2.0 schema should reflect that sensibility. This means:

Platforms need to be as intuitive as any cloud application.

Users should be guided clearly through the integration process.

Integrations can be federated across different parts of the organization.

It should be easy to deploy, customize, maintain, and scale.

Best practices should be productized into pre-built integration apps that can be licensed and reused.

Pricing models should fit the needs and accommodate small and large businesses.

Leveraging Pre-Built Best Practices

Many integration use cases have already been performed and documented — lead to cash, procure to pay, hire to retire, and more. It is important for the next generation of iPaaS to make it easier to leverage that work into future integrations, through connectors, templates, and integration apps, so that workflows no longer have to be rebuilt from scratch.

iPaaS 2.0 as a Key Component of Any Automation Strategy

Automation is one of the most important tactics to ensure operational success in an age of soaring competition and high customer expectations. Integration is a key component to any automation strategy. Today, iPaaS 2.0 technology is becoming a more critical part of a company’s tech stack and should be considered much earlier in a company’s life cycle than they normally are.

With the next-generation of integration Platform as a Service solutions, IT can centralize integrations and automation onto a single platform, while significantly reducing the time and resources needed to build and maintain these integrations. iPaaS’s ease of use allows integrations to be done by functional consultants, junior developers, or even non-technical users. Because anyone can manage an integration, they can be handed off to other departments, freeing up IT bandwidth to move to other projects and to spend time on more valuable activities.

Automation is one of the most important tactics to ensure operational success in an age of soaring competition and high customer expectations. Integration is a key component of automation.

A well-considered integration strategy supported by a robust iPaaS 2.0 solution ensures applications are working in concert, eliminating manual processes, lack of visibility, and costly errors, while enabling companies to be more adaptable in the ever-shifting business environments.

Automation is the future of business, and the companies that don’t adopt a powerful, holistic application integration strategy will lose out to those who do.

Headless Systems

A headless system like

Penzle⁠

Kentico.ai⁠

Contenful⁠

by can be a valuable tool in avoiding the anti-pattern of over-bounded contexts during software migration. The first step should be to focus on migrating the functionality of the service, while keeping in mind that adjustments to the level of granularity may be needed as the migration process progresses.

Once the service functionality has been migrated, the data migration process can begin, with the goal of creating a limited context between the service and the data. Using a headless system like

Penzle⁠

Kenitco.ai⁠

allows for more flexibility and scalability during the migration process, and the decoupled architecture can make it easier to integrate the system with other systems, and to retrieve data in a structured format.

In conclusion, a key aspect of successful software migration is achieving the correct level of granularity for the service and its related data. By focusing on migrating the service functionality first, adjustments can be made as needed. Once the appropriate level of granularity has been determined, the data migration process can proceed with the goal of creating a bounded context between the service and the data. I believe that this approach can help ensure a smooth transition with minimal disruptions.

Case Studies

Expedia

In 2019, Expedia decided to consolidate the functionality offered by their many brands and become a holistic travel platform company. As part of this restructuring effort, Expedia recognised the importance of:

Improving DX across the company in order to improve productivity and decrease costs.

Externalising consistent, discoverable and easy to use APIs to their business partners and the wider Expedia developer community, in order to support and grow revenue from integrators.

Over the years, acquisition had resulted in Expedia having many applications and APIs with duplicated functionality. The duplication meant that external developers who wanted to integrate with Expedia’s travel APIs are faced with multiple options, each with their own experience, feature set and developer hubs. Duplication also required internal developers to work with many different tech stacks and tools, even when working within a single business domain such as flight search.

Expedia’s holistic platform vision included a single set of uniform APIs and an AWS-like developer console experience where business partners and the wider development community could browse and utilize the full suite of tools on offer.

Hubspot

HubSpot’s multi-product strategy contributed to much of the company’s success over the past 10 years. HubSpot meticulously picked off areas of customer pain and created adjacent solutions for its customers’ needs and also sold the products effectively. HubSpot is a great inspiration; there is no doubt a multi-product strategy can pay massive dividends for SaaS companies of all stages and is a strategy that any company should consider, particularly in today’s environment.

eBay

Each module migration was kicked off with a deep dive into related legacy code. Due to the age of the codebase, the teams responsible for the migration no longer contain the original code authors. Initially, we focused on generating comprehensive documentation of the legacy system to aid in development of the new code. It was quickly determined that this process was not yielding the expected value; it was getting stale as we discovered new use cases. A pivot was made to focus on a rapid survey of the legacy modules to generate a high-level summary. We then relied on reverse-engineering while creating the new modules with comprehensive documentation on only the new code, to avoid future teams suffering the same fate.

The first few modules to be migrated followed a holistic approach that revised all portions of code that interacted with it, all the way down to including the client and display layer. Such changes are always A/B tested to be sure customer experience is improved. The data for some module migration with UX changes showed a negative impact on our customers. This cost us extra time waiting for the test results and to implement a new pivot to the feature to address those shortcomings. The most important thing we learned early on in the project was that we needed to completely segregate the back-end code modernization from any user-facing behavior changes. This new approach allowed our back-end teams to finalize all subsequent migrations in a shorter time. Client developers could then work on independent timelines for implementation, testing, and iteration.

The overarching theme of these lessons is to be flexible. We cultivated a team culture of continuously challenging our decisions and assumptions. Iteration on the plan itself was the most important part of being agile on such an ambitious project.

Intuit

At Intuit, the engineering department has committed to “Tech Bets,” or large goals that we as an engineering department want to achieve. One of these tech bets is to “Power our vision with One Intuit Services Platform.” In other words, we are trying to have one platform, with a clear Application Programming Interface (API) architecture and clean data model, as well as enabling easy setup on this new and centralized system. I work as a part of the Intuit Platform organization that aims to do just that. Specifically, I am on the Intuit Design System (IDS) team and we create components to be used across all of Intuit’s applications.

When we are creating a new component, we follow an in-depth process.

Product designers, subject matter experts, and user-experience designers conduct extensive interviews to understand how teams want to use the component in their product. User experience designers then incorporate design and usability best-practices, along with platform-specific knowledge.

When teams agree on how a component should look and function, IDS designers create specifications for colors, spacing, and overall look and feel of any base component used in our applications.

Those specifications then go to the software engineers (me and eight others), and we turn them into functioning components. We standardize the API to be used based on the needs of the various business units.

Finally, the component goes to the internal accessibility champions for review, where they verify that all of our components comply with the needs of all users, making sure we hold ourselves to the highest standards.

Zoominfo

The following goals were kept front of mind when deciding how to implement features and which ones to include in the initial release of the combined platform:

Speed of design and implementation – the initial release had a set timeframe that made efficient development a priority. A quicker solution that was good but not perfect was generally preferable to a perfect solution that took longer to implement.

Implementing as many existing features as possible – a priority was given to feature parity with the legacy platforms over completely new features. Of course, new features were developed too, but existing features were given preference over new features of approximately equal priority.

Reuse as much legacy behavior and code as possible – when the existing implementation in the legacy ZoomInfo platform was good enough and met customer needs it was retained as is or close to it. This goal is a logical extension of the first goal, speed.

Improve usability and consistency of features – a priority was set to make features work uniformly across the combined platform.

Centric

Integrating a new framework into an existing application requires careful planning and forethought by architects highly experienced in both the old and new frameworks. Without this guidance, it is easy to fall into a situation where the two frameworks are inefficiently converting data and application logic back and forth. Every time one of these conversions take place, there is typically a performance cost. SitePen dove into Centric 8 PLM to understand and identify the optimal insertion point for React that would result in the smallest performance impact while still offering maximum productivity gains. This enabled Centric to begin feature development on several new features created with React and TypeScript.

Having a central place to store and share the application state is key to maintaining a large-scale reactive application. Before such techniques were commonplace, Dojo Toolkit relied heavily on the publish-subscribe pattern, in which parts of the application would subscribe for notifications from other parts of the application. While it solves the problem of communication between components, this pattern tends to be challenging to debug, as the code cannot simply be traced to its source, and can often lead to difficult to diagnose bugs. SitePen introduced an application store, MobX, into Centric 8 PLM and demonstrated how to integrate this store into the new React-based features as well as transition old publish-subscribe Dojo Toolkit components to use MobX as well. This provides a single place in which Centric can reliably store observable application state and have it available in both legacy and new features.

For some commonly used web UI components, creating them from scratch is often not worth the effort. For example, writing a data grid or styling components that fit Material UI specifications could easily require as much effort as developing the feature itself. The React ecosystem is vast, and with thousands of third-party options to choose from, finding the best fit for a specific use case can be difficult. SitePen helped evaluate and recommend optimal right third-party libraries for each situation, providing proof-of-concept examples and documentation weighing the pros and cons for each. This enabled Centric’s developers to concentrate on the features that differentiate their product, rather than wading through and evaluating potential libraries or reinventing the wheel.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.