PLM Solution Architect – part 2: design deliverables and associated challenges
PLM implementations follow an iterative process during which business problems and requirements are translated and aligned to detailed level design modules through a number of technical deliverables. As previously discussed in part 1 of this post series, the “PLM Solution Architect” role is critical in translating vision, high-level roadmap and business requirements into tangible solution elements which can be technical implemented, tested and deployed. In this part 2, we look at generic “design” deliverables expected from PLM implementations, with associated challenges that Solution Architects must overcome.
Simply put, solution design deliverables vary in depth and breadth based on the PLM scope and complexity of the integration and transition. The PLM Solution Architect contribute directly to creating and managing these deliverables:
Signing off how business storyboards translate into detailed functional use cases and non-functional requirements; iterating through these in carefully prepared design workshops with business SMEs.
Piloting proofs of concept, documenting and demonstrating use case design principles to validate each element and obtain both business and IT acceptance.
Developing functional and non-functional specification documentation (including performance, security, protocols, sequences, etc.), to align use cases and storyboards with application capabilities and configuration requirements.
Creating and maintaining business process model blueprints, covering logical data model and required augmentations, configurations and customizations.
Collaborating in creating integration / interface specifications (message protocols, file formats, producer and consumer interfaces, message models, structures and transformations, service behaviors, connectivity requirements, error handling scenarios, security patterns, including expected maintenance and support service level requirements), in partnership with other Enterprise and System Architects.
Documenting data quality requirements and impact specifications related to data quality assessment, deployment models and legacy migration strategies—also contributing as input to the above technical specifications.
Performing and documenting technical and delivery impact analyses, setting up technical governance forums, and maintaining a technical decision log based on changes raised from either the business or IT; this includes proposing recommended way-forwards and supporting Delivery Managers in gaining stakeholder acceptance of the revised deployment plans.
Some deliverables will require working hand-in-hand with other IT technical teams, following up on issues raised during functional and non-functional testing, including system penetration, data migration, application and integration performance, as well as middleware, database and coding optimization requirements.
In leading the development of these deliverables, the PLM Solution Architect is likely to interface with vendors and implementation suppliers in leading technical discussions and continuously seeking for alignment. Typical challenges associated with creating, maintaining and getting approvals for these deliverables can be grouped in the following 8 categories:
Having access to the required legacy information, ‘as is’ processes and business intent.
Defining and maintaining clear architecture design principles, leading to effective “design authority” governance.
Continuously and proactively aligning with business delivery authority on solution assumptions, gaps, plans and necessary delivery activities.
Having early understanding of source data quality and related target integration or migration challenges.
Aligning with other Enterprise and IT Architects on design elements that might refer to existing architecture standards (or identifying gaps due to the lack of such standards and proposing solutions).
Understanding the organization maturity, as well as the maturity and modus operandi of its selected maintenance partners.
Building credibility and alignment with both business Change leads / Key Users and IT Architects—including Cloud Architects and other solution providers.
Having an essential understanding of project and programme management and being able to support certain design trade-offs when other delivery parameters must be prioritized.
On the one hand, with the rise of cloud hosted solutions, further hybrid integration requirements will emerge; they will most likely be impacting configuration and customization design elements. On the other hand, in the context of platform-as-a-Services (PaaS) solutions providing to multi-tenant clients, the role of “PLM Solution Architect” might become less relevant—at least for PLM solutions targeting the small and medium enterprise market. At the application level, a lot more focus could be expected from the Solution Architect on business process architecture, integration and data mapping.
What are your thoughts?
Original Publication by Momentum PLMand written by Lionel Grealou