PLM Solution Architect – Part 1: Key Responsibilities, Core Competencies and Skills

Lionel Grealou Digital PLM 4 minutes

Image Credit: PEXEL

In the enterprise digitalization world, Product Lifecycle Management (PLM) is often perceived as the difficult child of IT due to its complexity; PLM is nowadays a necessary commodity platform for engineering and manufacturing to interlock and operate effectively across the enterprise. When implementing or upgrading PLM platforms, the Solution Architect plays a critical role in ensuring the solution delivered is viable and fit-for-purpose to enable both deployment and future scalability. This role is technical in nature, focusing on defining the technical direction, adapting user stories to process configuration, converting them into application level requirements with infrastructure, integration, data migration and other technical dependencies across each solution elements. 

In this post, we explore core competencies and skills that the PLM Solution Architect is expected to bring to the table when leading such technical implementations.

Business and digital platform solutions typically required trade-offs between business and technical requirements; managing these compromises directly fall into the remit of the PLM Solution Architect:

  • How will the business scope translate in terms of application, software and system requirements?
  • How will solution elements be grouped logically to optimize value realization, yet provide a robust platform for business growth and modularity?
  • What will be the technical dependencies and assumptions to validate, and in what order of priority?
  • How much of the solution will be out-of-the-box (OOTB) versus configured or customized / integrated?
  • What type of configurations and customizations will be needed, how complex will they be and what will need to be tested early?
  • What integration strategies will be selected, from point-to-point interface to an enterprise service-oriented architecture (SAO)?
  • What plug-ins or third-party technical elements (e.g. middleware, connectors, bridges, etc.) will be required to integrate the solution in the wider enterprise and migrate / convert data to or from it?
  • How will the implementation be phased from a delivery perspective, and will it align to the business roadmap?
  • What delivery mechanisms will be adopted (e.g. waterfall vs agile) and what are the enablers (data assessment deep-dives, technical governance, design iteration and proof-of-concepts, etc.)?

Solution Architecture goes beyond system requirements

The Open Group Architecture Framework (TOGAF, 2018) rereferred to 5 main architecture capabilities:

  1. Architecture requirements: key principles, vision, strategy, constraints, assumptions, gaps, etc.
  2. Business architecture: functions, roles, business units, suppliers…
  3. Information systems architecture: data, logical model components, services, to physical application components.
  4. Technology architecture: platform services, logical and physical components, infrastructure.
  5. Architecture realization: planning, work packages, capabilities, standards, governance, change management, migration transition and integration.

The Architecture Development Methods (ADM) as defined by TOGAF refers to the entire implementation stack for each solution element:

“A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and / or IT system specifications, and a portfolio of implementation tasks.”


Some of these architectural capabilities are typically managed at the wider Enterprise Architecture level; they need to be adhered to at the project level, whereas other elements solely relate to PLM application level architecture decisions—which are under the direct ownership of the PLM Solution Architect.

Solution Architect: key responsibilities

The PLM Solution Architect is a technical leadership role with direct interface with the Product Owner, Delivery Manager or Program Director; the Solution Architect has a duty of care to ensure technical alignment across the enterprise. It is a business facing role with technical authority and governance responsibilities across business and IT stakeholders, working with delivery leaders to:

  • Derive the required solution elements to validate and influence the business roadmap.
  • Assess and select technologies and tools, and all technical building blocks.
  • Develop detailed technical specifications for each solution elements and obtain business sign-off (more on Solution Architect’s deliverables in part 2).
  • Assess and mitigate technical risks and constraints.
  • Interface with Enterprise IT Architects and SMEs to align the required infrastructure elements; with different flavours of the work required based on the selected infrastructure, hosted cloud IaaS, PaaS, etc.
  • Prepare gap analysis and present design trade-offs, sanction technical decisions in formal review forums.
  • Oversee process and data discoveries; develop and test technical remediations or recommend design solution alternatives.
  • Align with enterprise architecture governance and standards (and avoid reinventing the wheel) or propose how to fill the gap when they don’t exist.
  • Keep in touch with technology advances, from system to functional and integration aspects.

Solution Architect: core competencies and skills

PLM can be perceived as an art rather than a science—hence many executives are staying clear from it. The PLM Solution Architects are perhaps more “solution doctors” than “technical guru”. They must continuously learn and adapt, about both technical elements and product-related challenges; they must:

  • Have experience in dealing with complexity, have excellent understanding of business data and process requirements.
  • Able to deal with complexity and simplify things, develop and maintain a 360 degree “big picture” view of the solution.
  • Demonstrate efficient communication and stakeholder management skills, coupled with both organizational and leadership skills.
  • Understand master data principles and technical overlaps among digital platforms, from PLM to ERP, MES, SCM, etc.
  • Have in-depth understanding of design patterns, coding and customization languages, middleware and other IT principles; and able to interface openly with other IT Architects on such matters.
  • Be a great problem solver, with excellent analytical and self-starter skills.

Adopting holistic architecture frameworks such as TOGAF and other equivalent architectural frameworks can help—though they do not guaranty success; the mandate of the PLM Solution Architect is to pragmatically tailor the required practice to an organization and its PLM context, and to continuously communicate about it with both technical and non-technical stakeholders.

In the next part of this two-part post series, we will discuss typical “design” deliverables owned by the PLM Solution Architect and their associated challenges; we will also cover how certain aspects of the role might need to evolve in order to align with new cloud paradigms.

What are your thoughts?


  • The Open Group Architecture Forum, 2018. TOGAF Version 9.2, Open Group Standard. The Open Group, USA.

This post was originally published on Momentum-PLM on 2 September 2020.

Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption. 

About the Author

Lionel Grealou


Lionel Grealou, a.k.a. Lio, helps original equipment manufacturers transform, develop, and implement their digital transformation strategies—driving organizational change, data continuity and process improvement, managing the lifecycle of things across enterprise platforms, from PDM to PLM, ERP, MES, PIM, CRM, or BIM. Beyond consulting roles, Lio held leadership positions across industries, with both established OEMs and start-ups, covering the extended innovation lifecycle scope, from research and development, to engineering, discrete and process manufacturing, procurement, finance, supply chain, operations, program management, quality, compliance, marketing, etc.

You may also like: