Cloud solutions and platforms are often nebulous and need structure. A robust information architecture is essential for explaining what these systems provide to users.\u00a0<\/p>\n 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.<\/p>\n I\u2019ve spent much of my career designing, implementing, and explaining enterprise software. This work keeps getting harder.\u00a0<\/p>\n 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.\u00a0\u00a0<\/p>\n Next, vendors emerged who offered prebuilt packages that allowed limited customization. The scope was defined for you.\u00a0 You had to live with what the vendor decided.<\/p>\n More recently, enterprise software has become \u201ccomposable,\u201d and organizations are responsible again for deciding what they need and how to integrate the various elements.<\/p>\n What\u2019s changed over time is that software is no longer a self-contained system. It doesn\u2019t have a defined scope. It is connected to many other systems, whose boundaries are blurry.\u00a0<\/p>\n Vendors once talked about portals, a now-dated term that simply meant you could access systems via the web.\u00a0 Everything you need would be right there on your screen. On the far side of the portal was a vast ecosystem delivering the information.<\/p>\n The user didn\u2019t need to worry about ecosystems.\u00a0 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.\u00a0<\/p>\n 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.\u00a0<\/p>\n Beyond the screen, the iPad\u2019s product architecture enables the experience. Users don\u2019t 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\u2019s allowed.\u00a0<\/p>\n Enterprise software likewise encourages users to believe everything they need will be at their fingertips. Unfortunately, the ambition to address everything<\/em> generates its own problems.\u00a0<\/p>\n We live in a world of many problems. Products solve specific ones. Solutions promise to solve the problems of running a business.\u00a0<\/p>\n Solutions are hard to pin down. It\u2019s not clear exactly what they do or the problems they solve.<\/p>\n What is clear is that the solution isn\u2019t 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.<\/p>\n Solutions are frequently called platforms, which implies they are the foundation of other things.\u00a0 But they might be called build-your-own solutions, flexible toolchains, composable stacks, or open ecosystems.\u00a0<\/p>\n If you are wondering what the distinctions are among these terms, you are not alone.<\/p>\n Solutions seem fuzzy, unlike products, which seem solid. Products have an architecture that determines how they are assembled.<\/p>\n 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.<\/p>\n 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.\u00a0 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.\u00a0\u00a0<\/p>\n In software, the rules are less clear.<\/p>\n 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.\u00a0\u00a0<\/p>\n Product architecture expresses what designers call affordances, which indicate what users can do with them.\u00a0 But what are the affordances of a solution?\u00a0\u00a0<\/p>\n 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.<\/p>\n Solutions are built from layers that require deciphering.<\/p>\n Describing solutions resembles the parable of various people describing an elephant by reference to its parts.\u00a0 The parts don\u2019t capture what solutions do, but it is still necessary to understand these elements.\u00a0<\/p>\n Vendors can hide details about how preassembled products are built, provided users don\u2019t need to change them.\u00a0\u00a0<\/p>\n But enterprise solutions can\u2019t be entirely prebuilt.\u00a0 They need to adapt to the customer\u2019s context.\u00a0 They can\u2019t be a black box because users must make choices about which parts to use and how.<\/p>\n Users must be able to identify the components<\/em> of a solution<\/p>\n Imagine if the solution\u2019s components were packaged in a box. What pieces would the box say are included, optional, or elective?<\/p>\n A typical enterprise platform includes generic components, such as workflows, user management, project dashboards, search, metadata, analytics, or notifications.\u00a0 Generic components are features available to all platform users. They are normally considered as services or infrastructure rather than as products.<\/p>\n More specialized components will be specific to a role or to a subscription tier, which are what users typically think of as products.\u00a0 Users start to notice differences between platform capabilities and products on the platform, which might be called apps, extensions, or packages.\u00a0<\/p>\n Products are often categorized by whether they are interdependent or modular.\u00a0\u00a0<\/p>\n Modular products, in theory, allow a buffet style of choosing what you want.\u00a0 You can add and drop capabilities, mix and match them, and choose which vendor to supply them.<\/p>\n Modular products can be complements to various degrees; they may work in tandem. Compatibility becomes critical when different modules must work together.\u00a0 Users start to learn distinctions in compatibility:<\/p>\n While solutions are composed of many pieces, unlike a jigsaw puzzle, solutions can have missing or leftover pieces, and there\u2019s more than one to assemble them.\u00a0<\/p>\n Complexity arises whenever there are multiple ways to do something.\u00a0<\/p>\n It\u2019s possible for users to get lost in the clouds.\u00a0<\/p>\n Platforms are everywhere and nowhere. They live on clusters of servers.\u00a0 Yes, devices owned by someone still lurk in the background, but vendors gloss over these details by talking about the cloud.<\/p>\n Yet, the cloud is no longer a simple concept. We have flavors of the cloud solutions:<\/p>\n These dimensions affect whether applications are \u201calways-on\u201d or \u201con-demand.\u201d\u00a0 How \u201con\u201d a capability is will determine the process and speed with which users can do things.<\/p>\n These terms may sound like geeky jargon, and they are.\u00a0 Most users couldn\u2019t care less about them.\u00a0 But they influence performance and costs and often involve parameters that the user must specify:<\/p>\n Users may also need to know about limitations with their setup. There\u2019s a concept called \u201cdata sovereignty\u201d that relates to how much control users have over the platform. In many platforms, users give up sovereignty.\u00a0<\/p>\n A metaphor conceptually related to platforms is the operating system.\u00a0 PC users are familiar with the concept of operating systems, such as whether software is Windows-compatible.\u00a0 iPhone apps, likewise, must be iPhone-compatible.<\/p>\n The platform-as-operating-system suggests a degree of lock-in.\u00a0 It is hard for users to move off the platform.\u00a0<\/p>\n Lately, platforms have sought to build services on top of operating systems.<\/p>\n![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXfKkrVHp0pj5r0Jqk7l22IwMrykrVQi5RieOTudT2V76Gdgoa1dOCpQrbb2fxknKdOgZ4nt20CfGDgE5yvtSGhZb4wg-qIGCWIK9P_b4bySyFk4wprY_LmswlH7t40gEVMxcJZqpw?key=sRKZJ3-qto9wF2xyoxgaISTr\")
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXf1BDycYpt3bLBZTvi8CLRRQs0-Tf5IPIsgdPQ4mNccU532HhKJRIhGx9VWbZln-mbk8Gs9xBzzciYQ8xe8aF0MtkanPvVGOiaNF-lF_IGSfFsgwquBsm0LZ0HMNym36OOat9j2iA?key=sRKZJ3-qto9wF2xyoxgaISTr\")
The metamorphosis of enterprise software<\/h2>\n
The screen as the product<\/h2>\n
Solutions in search of problems\u00a0<\/h2>\n
\n
(De)Composition<\/h2>\n
\n
\n
\n
Where does the solution live?<\/h2>\n
\n
\n
Platform control<\/h2>\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXfqDbc0-J2DjLdXlFKZ9nO51ZJvqCziCJ1j607eHklGbgI5cfNQReE1m0XUmM52SKxVTa13Qs-vK5JrRC0iKD27lqelxTVaqGHqd53mrIVokQdC0Gb2SbW0mfalRX7qM7d_Yb1TnA?key=sRKZJ3-qto9wF2xyoxgaISTr\")
<\/figure>\n