IBM Business Automation Platform
An object model and authoring container that unified IBM's Business Automation portfolio.
- Client
- IBM
- Role
- Senior Advisory Designer
- Year
- 2016–2020
Thesis
I led design across IBM's Business Automation portfolio, a dozen products accumulated over thirty years of acquisitions and countless additions, sold together but designed apart. The job was to turn the portfolio into a platform.
The main work was defining the information architecture and introducing new paradigms for how the products would work together. The central piece was something I called Projects: a unifying space that let the products interoperate, share a common mental model, and come together in a cohesive experience.
Years later, that unification work and that concept are still living in the product.
The project required working with senior VPs across competing business strategies, defining cross-portfolio direction, wrangling stakeholders, and directing design across five product teams. I was the senior advisory designer for the portfolio, overseeing the platform and its core experiences, with an advisory role to each team's design lead. Throughout, I advocated for design as the lens that could unify a portfolio that did not have much experience with design thinking before.
The mess
Two IBM sales teams once accidentally arrived at the same customer meeting, pitching competing products from our same portfolio. The story was told as a joke inside the organization, but it described the problem we were still facing.
The portfolio was the result of thirty years of acquisitions, re-orgs, and sprawl. Each product came with its own users, data models, interaction patterns, and a team whose internal incentives kept things siloed.
From the outside, customers saw unrelated experiences. Navigation diverged between products. A "task" meant something different in each one. From the inside, every cross-product workflow became an integration project, every shared concept needed a translation layer, and every new capability was hindered by old patterns. The easy became hard.
The Opportunity I saw
Consolidation was already being pushed from multiple directions, and none of them lined up. IBM's Software Group wanted the portfolio pulled together into platforms called Paks. Business Automation leadership was running its own independent platform push. The product teams inside Business Automation were not interested. They had roadmaps of their own to hit. There was no internal alignment, just pressure from above and resistance from below.
Meanwhile, the portfolio was shifting underneath us. The target user was moving from central-IT specialists toward line-of-business. Adjacent platforms had their own roadmaps to coordinate with. The legacy products needed modernizing while new capabilities kept arriving. Any consolidation plan had to absorb all of this at once.
Three things I did had the biggest impact.
Product teams ran against the platform direction by default. Each had its own revenue targets, and cross-portfolio work always lost to local KPIs. Above me, a cross-platform design team was setting pattern vision without the constraints it was designing into. Design VPs had their own priorities. None of it cohered on its own.
I worked through the design leads embedded in each product team: carrying constraints up, bringing elegant solutions back down from the executive stakeholder, and coordinating laterally with adjacent platforms to keep the picture coherent. Design played the facilitator and guide role the org otherwise lacked.
The competing pushes, the shifting user base, and the product-level misalignment formed a mess no single stakeholder could see whole. Design could, so I articulated the real problem space: what was actually broken, where the seams had to go, and what the target state needed to look like. That articulation was what made solutions possible.
Products across the portfolio used different words for the same concepts, and the same words for different concepts. Rather than negotiate vocabulary upfront, I worked at the level underneath: defining the objects and their relationships, then extending the model where the existing concepts fell short. The largest of those extensions was projects.
The unifying concept
My solution was Projects, a concept I prototyped and pitched across the org. A project is a container for collaborative work, organized around an initiative. It became the central concept across the portfolio and the synthesis that unified the landscape. Inside a project, assets authored by each tool in the platform — forms, processes, decisions, cases, documents — reference each other natively. A form from one product calls a process from another without glue code. Teams have one entry point instead of a branching decision about which product to open first.
Projects became the foundation. Everything else followed from them.
Five decisions defined how a project worked, what lived inside it, and how it connected to the rest of the platform.
This container object of ‘Projects’ allowed a place to address many of the pain-points and execute our strategy goals.
- Interoperability. One place where different products' assets reference each other and work together.
- A cohesive object model. Shared content objects across products: tasks, actions, properties, forms, services.
- Mental model and entry point. Start a project, pull in whichever tools you need.
- Branching out. A specialist user moves beyond their silo because adjacent capabilities are reachable inside the container.
- Team collaboration. A shared surface for work that spans tools and roles.
- Extensibility. New capabilities plug into the same container rather than spawning parallel product shells. Automation and intelligence asset types emerged this way.
The past reality was specialist-driven. Central IT and legacy teams ran the deep work; bandwidth was always the bottleneck. Line-of-business users didn't know how to get help, didn't want to wait for capacity, and didn't get on the roadmap. Along with new low-code tooling, the project container shifted that. LoB users could build solutions for themselves, pulling in shared artifacts or coordinating with specialists as the work required.
Before
The same process used to spread across four roles working in different tools. The Hiring Manager identified the need and submitted a requisition for Department Head approval. HR published the listing, received and reviewed every application by hand, scheduled and conducted onsites, ran background checks, made offers, and processed onboarding. The few automated parts (sponsorship rules, resume extraction, tiering, routing) lived in different products and had to be wired together by specialists. Each was authored separately, deployed separately, and integrated by hand. Most flows never got integrated at all because the cost outweighed the value, so HR ran the steps manually.
After
The same process composes inside one project. Submitting a requisition is an app. Publishing a listing is a workflow. A content service extracts resume data, and the tiering decision references it natively. Sponsorship eligibility and candidate tiering are decisions that share the same data. Routing decides what happens next: Tier A goes to a phone screen, Tier B gets a request for more information, Tier C gets a rejection email. Background checks, offers, and onboarding all run as workflows in the same project. The Hiring Manager and HR step in for the parts that still need a person, like identifying the need, writing the job description, conducting the onsite, and the final approval. The integration cost is gone, and most of the manual work goes with it.
Implementation
Design only helps users once it ships. The rest of the work was championing the concept, leading the teams that built it, and seeing it through to delivery. I made the case through mockups, concept decks, and iterative playbacks. Every VP, product lead, and design team got a tangible object to react to, commit to, or debate. Skeptics became sponsors once they could see their product's capabilities plugging in.
I was the point person across the five design teams that built the concept out. I kept rallying them around the vision and was hands-on helping the other design leads work through their team's version of the problem. I understood each team's core product goals and the tensions they were working through, and proposed solutions that held up across products. I often understood the crux of a product better than its own lead did.
I worked with the teams to prioritize, plan, and set up sprints against the vision so they could execute it. The concept got adopted, built, and landed in the product. Teams that had been skeptical were shipping inside the shared container. What I'd been championing became the default.
What it changed
We were able to successfully ship Projects and impact real users. Tools that moved into the platform and adopted the shared object model went on to show measurable impact.
A Forrester Total Economic Impact study in 2022 found that customers running on IBM Cloud Pak for Business Automation realized substantial returns and gains in productivity. The platform being studied was the consolidated one: the object model, the container, the shared authoring surface that came out of this work.
Customers running cross-pillar work inside the container reported concrete outcomes. Tools that had once been separate products were now working together inside one project, shipped by one team, deployed as one thing.
This was an ambitious, hard-fought design endeavor, and one that was very rewarding as a designer. Setting vision, directing teams, and collaborating cross-discipline is my favorite part of the profession. The results speak for themselves.
Note: Due to NDAs, some assets have been redrawn or generalized.