Cloud solutions and platforms are often nebulous and need structure. A robust information architecture is essential for explaining what these systems provide to users.
Imagine a software solution being like a doll, a simplified model of the real world. Would it be best described as a nested doll with smaller units tucked inside larger ones or as a Mr Potato Head, where many appendages can be affixed to a common body? Solutions can resemble both.
The metamorphosis of enterprise software
I’ve spent much of my career designing, implementing, and explaining enterprise software. This work keeps getting harder.
When I started working with enterprise software a couple of decades ago, it was custom-built but had a well-defined scope. Scope creep was a bad thing.
Next, vendors emerged who offered prebuilt packages that allowed limited customization. The scope was defined for you. You had to live with what the vendor decided.
More recently, enterprise software has become “composable,” and organizations are responsible again for deciding what they need and how to integrate the various elements.
What’s changed over time is that software is no longer a self-contained system. It doesn’t have a defined scope. It is connected to many other systems, whose boundaries are blurry.
The screen as the product
Vendors once talked about portals, a now-dated term that simply meant you could access systems via the web. Everything you need would be right there on your screen. On the far side of the portal was a vast ecosystem delivering the information.
The user didn’t need to worry about ecosystems. Most iPad users, for example, think of their iPad as a physical device: a touch screen with some circuitry behind it. The biggest worry is dropping the device and cracking the screen.
Yet, the deeper experience of an iPad is the by-product of all the associated software that is available for the device. Most of that software lives in the cloud rather than on the device itself.
Beyond the screen, the iPad’s product architecture enables the experience. Users don’t need to think too much about the pieces that allow that experience. Navigation is reduced to a bunch of icons. A cheerful app store offers an endless range of options to add to the device. Apple provides a walled garden experience, acting as the gatekeeper for what’s allowed.
Enterprise software likewise encourages users to believe everything they need will be at their fingertips. Unfortunately, the ambition to address everything generates its own problems.
Solutions in search of problems
We live in a world of many problems. Products solve specific ones. Solutions promise to solve the problems of running a business.
Solutions are hard to pin down. It’s not clear exactly what they do or the problems they solve.
What is clear is that the solution isn’t a tangible device. Any device is incidental to the capabilities offered, especially as many organizations allow employees to bring their own personal devices to access work systems. The cloud has replaced the device.
Solutions are frequently called platforms, which implies they are the foundation of other things. But they might be called build-your-own solutions, flexible toolchains, composable stacks, or open ecosystems.
If you are wondering what the distinctions are among these terms, you are not alone.
Solutions seem fuzzy, unlike products, which seem solid. Products have an architecture that determines how they are assembled.
Product architecture is similar to the recipe of a dish served at a restaurant. All dishes exist to feed the appetites of diners, but not all are made the same way.
Diners can order a preconfigured dish decided by the chef. Or they can go somewhere where they can configure their own by choosing a base, protein, and topping. Within that spectrum, other possibilities exist where diners modify a dish with additions or substitutions. Diners follow the rules or try to negotiate new ones.
In software, the rules are less clear.
Users must form a mental model of available options so they can adapt products to fit their needs. They need to understand the underlying product architecture to some extent to make effective use of the product.
Product architecture expresses what designers call affordances, which indicate what users can do with them. But what are the affordances of a solution?
- The options that are available – the features?
- The practical tasks that users can perform – the functions?
- The outcomes the platform delivers – the benefits?
Vendors tend to talk about all these dimensions, freely mixing them together. They zoom and pan their discussions, shifting between granular technical details and sweeping generalizations. Users get confused about why features exist, what they can do, and why the promised benefits are so hard to realize.
(De)Composition
Solutions are built from layers that require deciphering.
Describing solutions resembles the parable of various people describing an elephant by reference to its parts. The parts don’t capture what solutions do, but it is still necessary to understand these elements.
Vendors can hide details about how preassembled products are built, provided users don’t need to change them.
But enterprise solutions can’t be entirely prebuilt. They need to adapt to the customer’s context. They can’t be a black box because users must make choices about which parts to use and how.
Users must be able to identify the components of a solution
- What they are
- How to use them
- How they fit together
- What can be changed or substituted
Imagine if the solution’s components were packaged in a box. What pieces would the box say are included, optional, or elective?
A typical enterprise platform includes generic components, such as workflows, user management, project dashboards, search, metadata, analytics, or notifications. Generic components are features available to all platform users. They are normally considered as services or infrastructure rather than as products.
More specialized components will be specific to a role or to a subscription tier, which are what users typically think of as products. Users start to notice differences between platform capabilities and products on the platform, which might be called apps, extensions, or packages.
Products are often categorized by whether they are interdependent or modular.
- Interdependent or monolithic products have functionality that can’t be used without other functionality within the product
- Modular products have functional modules that can be standalone
Modular products, in theory, allow a buffet style of choosing what you want. You can add and drop capabilities, mix and match them, and choose which vendor to supply them.
Modular products can be complements to various degrees; they may work in tandem. Compatibility becomes critical when different modules must work together. Users start to learn distinctions in compatibility:
- Certified compatible
- Backward compatible
- Partially compatible
- Capable
- Standards compliant
While solutions are composed of many pieces, unlike a jigsaw puzzle, solutions can have missing or leftover pieces, and there’s more than one to assemble them.
Complexity arises whenever there are multiple ways to do something.
Where does the solution live?
It’s possible for users to get lost in the clouds.
Platforms are everywhere and nowhere. They live on clusters of servers. Yes, devices owned by someone still lurk in the background, but vendors gloss over these details by talking about the cloud.
Yet, the cloud is no longer a simple concept. We have flavors of the cloud solutions:
- Native cloud
- Cloud agnostic
- Multi-cloud
- Hybrid-cloud
These dimensions affect whether applications are “always-on” or “on-demand.” How “on” a capability is will determine the process and speed with which users can do things.
These terms may sound like geeky jargon, and they are. Most users couldn’t care less about them. But they influence performance and costs and often involve parameters that the user must specify:
- Where is the data stored?
- What system is doing the processing?
- How is usage charged?
Users may also need to know about limitations with their setup. There’s a concept called “data sovereignty” that relates to how much control users have over the platform. In many platforms, users give up sovereignty.
Platform control
A metaphor conceptually related to platforms is the operating system. PC users are familiar with the concept of operating systems, such as whether software is Windows-compatible. iPhone apps, likewise, must be iPhone-compatible.
The platform-as-operating-system suggests a degree of lock-in. It is hard for users to move off the platform.
Lately, platforms have sought to build services on top of operating systems.
A recent article in the New York Review of Books looks at China’s WeChat platform, which is similar to, but more expansive than, WhatsApp:
WeChat is perhaps best thought of as an operating system that sits atop a phone’s own operating system, whether Android or Apple, because many users start their days within its capacious universe of apps and never leave it. People book rideshares and doctors’ appointments on it, use it to pay their bills and taxes, engage with their local government, play games, conduct business meetings, buy stocks, transfer money, reserve train and airline travel, share documents, live-stream entertainment, and yes, arrange food delivery.
The article notes this concept may be coming to the United States:
Elon Musk has stated his interest in turning X, the former Twitter, into a WeChat-like, all-in-one platform that supports financial and commercial operations. Critics cite this as a motive in the recent elimination of the Consumer Financial Protection Bureau, which would supervise such a company and the banking and data privacy rules that would govern it.
Compatibility issues reflect whether platforms are tightly coupled or open. In other words, what does the platform do, and what does it pass off to other services or platforms?
The Instant Bloomberg (IB) messaging on Bloomberg financial terminals is another famous example of an operating system. For years, Bloomberg has kept the IB as a walled garden. But recently, it has signaled it may be loosening control by allowing other services to run within it:
Opening up Bloomberg to chatbots is a way of making it easier to get data in and out of the Bloomberg ecosystem. Chatbots can allow you to ‘write’ to external databases, and allow you to pull from external databases. The move shifts IB from a pure communication layer to a User Interface (UI) as well. It may very well be Bloomberg’s goal to have you interact with all internal front office systems through IB. It’s a way to query and write to the firm’s knowledge graph. This opens a world of new opportunities.
Platform responsibilities
A critical dimension when explaining a platform to users is conveying what the platform is responsible for and what it isn’t.
This answer is cloudy for several reasons:
- Platforms encourage à la carte options so that each situation may be different
- Platforms outsource services to other platforms
The platform is entangled in a wider ecosystem. Yet, users are expected to understand what capabilities have been delegated elsewhere.
Users reasonably want to know what the platform is responsible for providing and what they are responsible for. But this seemingly simple question is complicated by the architecture of platforms and the ecosystems they connect with.
The architecture involves layers of functionality that are woven together in an implementation:
- Various user interfaces
- Multiple products having discrete functionality (for example, apps)
- The platform supporting the products, which may coordinate with other platforms (for example, “X” as a Service)
- The infrastructure that supports the platform(s) – often via cloud service providers like AWS or Azure
The solution may be supported by separate UI, product, platform, and infrastructure teams, each worried about different metrics and subsystems. Multiple UIs can access a single product, and platforms may draw on common functionality from the platform such that products sometimes have overlapping functionality.
If those boundaries are less than obvious, the complexity is compounded by a multitude of actors who may be responsible for different dimensions. The platform vendor is essential for some services and optional for others. Users must use other vendors for some services, can choose to use third parties if they want an alternative, or maybe will build their own.
Platform vendors sometimes promote the notion of “BYO” options, though BYO can alternately stand for either “Build Your Own” or “Bring Your Own” – very different concepts.
Users must know which services on the platform are “core” and which are auxiliary.
Some vendors promote a distinction between “in-product” and “in-platform” functionality. In-product functionality involves core services. But in-platform functionality is more nuanced.
It’s often unclear if the vendor or the customer manages the in-platform functionality. Users expect to know what they can change – what they are permitted to alter, given the gatekeeping for access, security, and so on.
Outside functionality can be added to platforms in two ways:
- Third-party integrations that are prebuilt, typically from an endorsed vendor partner
- Connectors or on-demand (APIs) options that the customer will load or link themselves
In contrast to “suites” of related products from the same vendor, any use of third-party solutions will introduce new behaviors, concepts, and terminology to users. One major complaint about “composable” solutions is that they are not coherent when combined.
Vendors boast that their platform is “open,” but third-party options will have varying degrees of technical and experiential compatibility. They may say you can mix and match their product with those from other vendors, but they won’t necessarily work together as advertised. Combinations can require effort to create and maintain and may not be performative – they can be slow or glitchy.
A fundamental question users have is to what extent a vendor takes responsibility for
- Their platform’s end-to-end (e2e) experience
- What SLA (service level agreement or uptime reliability) is operative
- What’s trusted (guaranteed) in terms of security and accuracy
Such issues influence many downstream user decisions.
Who is the user?
Platforms are multi-user products. Yet, having many users is only part of the story.
Basic platforms offer an app store geared to an individual or, occasionally, a household. While there are many users, they are not affiliated with one another. In a platform like eBay or Shopify, buyers and customers only have a transactional relationship with each other.
Enterprise platforms, by contrast, can have thousands of users belonging to the same organization. Many users will be associated with a single account.
It’s thus important to distinguish a platform intended for singleton users, where each individual has their own priorities, from those intended for group collaboration, where various roles work together on common priorities.
What do enterprise users want from the platform? The more agnostic a platform’s architecture is about the use cases it supports, the more abstract the product is and the more difficult it is to anticipate how users will use it.
Platforms that support generic tasks can be hard for users to adopt. They need to mentally translate the generic functionality into their specific work context.
The users’ mental model of the platform will reflect their prior experience with it. A platform will seem simple when experienced in a closed demo environment or limited trial. Platforms may be discovered through a cloud Marketplace, where users pay as they go and must be able to understand the capabilities quickly. However, once organizations contract to build systems on a platform, users must develop a deeper knowledge of its workings.
What users need and want to do will depend on their role. Platforms, more than other products, serve users with multiple roles. Different user roles want different – sometimes conflicting – things from the platform.
Some common user roles in platforms are:
- Admins who connect and configure platform resources and monitor costs
- Engineers who build tailored solutions on top of platforms
- Line of Business users who use tailored solutions
Engineers may want to bypass Admins, while Business users may want no code options that bypass Engineers. But roles defined by the platform (and the Admin setting it up) entail permissions about what options users have or will even know about.
The variability of implementations
To paraphrase Tolstoy, “All platforms seem alike; each implementation is quirky in its own way.”
The idea of a platform is one of happy possibilities. The reality of a platform is the limitations of its implementation.
Faced with a sprawling solution, the user needs to somehow identify the capabilities available on the platform and operationalize them.
They might start with a job to be done – what the user is trying to accomplish. They will consider variables that are inputs or influences on their work:
- Data or content sources
- Formats of those sources
- Tools that are relevant
- Analytics to measure
- Workflow to get raw sources into the output they need
Some vendors refer to these workflows as orchestration, implying they are repeatable processes. But before orchestration can happen (if that’s even realistic), individuals must understand the capabilities that are available and how to assemble and sequence them. They must map their mental model of how to perform work tasks to the conceptual model of the platform.
The platform may refer to concepts that may be unfamiliar to the user, such as frameworks, tools, or data models and formats. Often, the framework of tasks gets upsized when a person transitions from applications focused on managing their individual tasks to those focused on enterprise-scale processing.
The user interface assumes a prominent role in guiding users through the platform. But there may be multiple UIs, sometimes from different vendors. Plus, the UI can take many forms:
- Web-based (dashboards, configurators, rule-builders)
- AI bots, agents, and copilots
- Code editors and notebooks
- Command line interfaces (CLI) and APIs
Many times, a user can do the same task in alternate ways using different UIs. That flexibility may have advantages, but it also adds potential confusion.
In the face of this complexity, the onboarding experience becomes critical to orienting users. Yet, onboarding is challenging since many pathways and possible configurations exist.
Users need a range of supporting content, including tutorials, in-product help, and documentation, that must be contextually relevant to the user’s situation.
IA for platforms: Labeling and terminology challenges
Platforms promise to unify often disparate processes. Yet, they also amplify complexity by connecting previously separate and dissimilar activities. The technology underpinning platforms comes from different teams and vendors.
Information architecture provides the only realistic option to unify the platform and bring coherence.
The significance of information architecture in platforms is poorly recognized. Platforms tend to be designed by engineers who think in terms of enterprise architecture rather than in concepts relatable to users who are not enterprise architects.
So far, we’ve discussed some of the concepts and relationships that users must navigate. Once the key concepts and relationships are identified, they must be given clear names.
Platforms are burdened by jargon. Again, de-jargonizing platforms is not easy.
The first challenge is that platforms draw on diverse sources of terminology:
- Proprietary named products or capabilities
- Industry or third-party names for protocols and standards,
- Branding concepts – phrases capturing what makes a product different
- UI terminology such as panels, knowledge centers, assistants, etc
Many of these terms resist revision, even if they are unclear, because they are deeply embedded in organizational decisions made outside of the platform’s design team.
The second challenge relates to the diversity of platform users and the differences in their domain knowledge. Users have different expectations about the formality and detail associated with terms. Some terms will be interpreted differently by different roles. Simple-sounding terms like “projects” may convey a range of associations. Actions such as “activation” can apply to accounts, users, or environments, so what’s active or inactive can get confusing, depending on what the user needs to know or has control over.
Platform terminology is prone to contextually-specific meanings. A procedure implies something different to a business user and a programmer.
Even terms that should have a singular definition may have several. A single term may have diverging and seemingly unrelated:
- Internal (technical) definition
- Marketing (benefits-focused) definition
- User (jargon-free) description
Clear terminology needs to be:
- Self-explanatory
- Distinct with no disambiguation needed
- Defined clearly so that terms are not dependent on another definition (definitions should not raise new questions) and are understandable to all personas
The information architecture must account for how concepts are described within the platform and note who needs to see these terms and when. From this inventory, the IA must work to harmonize terminology across the platform, avoiding naming collisions. All terms must be tested with persona roles to ensure they are clear to all.
Architectural landscaping
The information architecture of platforms will be shaped by product architecture but should not mirror it. Platforms have many product managers. Information architects can’t assume one unified product vision exists.
Information architects must know the ecosystem in which the platform operates and understand the many user journeys through that ecosystem.
One useful tool for mapping these relationships is a product canvas, especially those that focus on enterprise use cases.
Platforms are rarely designed all at once. They tend to evolve and reflect many inputs. The landscape is always shifting.
The information architect must react to what exists already and anticipate how the platform might continue to evolve.
Making what’s complex understandable to diverse users takes effort that should not be underestimated.
– Michael Andrews