The Solution Architect Role

Overview

The Solution Architect (SA) role is responsible for designing a technical strategy or solution that will work (it matches business needs, it can be built, it can be supported & maintained, etc) for all stakeholders. While this role can apply to any custom development or technical project, this article was specifically written to address the needs to a Solution Architect on an integration project.

Teams & Roles The Solution Architect Role Solution Architect Role For Technical Projects Drawio

For Integration Projects (CIMcloud-to-Any Platform)

For integration projects, the Solution Architect role will map out a solution by factoring in the platforms being integrated, the business goals, the technical complexities, the many tradeoffs, etc). It’s tricky. It’s required. And it’s the absolute foundation for success.

Note: This role is related to, and sometimes referred to, as a Business Analyst or Product Manager.

Part of a Series of Articles

The article you are currently reading is part of a series of articles that are all organized and summarized in this Integration Reference Guide (Using the CIMcloud API).

Audience (for This Article)

The intended audience for this article is CIMcloud customers (and their contractors / partners) that are considering 1) building and/or managing / supporting an integration between CIMcloud and any other software system, or 2) designing and building any other customization or extension to the CIMcloud platform.

Overview Videos

A General Overview (of the SA role on any technical project)

The provides a quick, general overview of the Solution Architect role.

Details (of the SA role on complex integration projects)

The video walks through more details of the Solution Architect role. It steps through all of the content presented in this article, and adds additional context and commentary.

Role Overview

This is a quick overview of the Solution Architect role (particularly for an integration project).

The Solution Architect designs the “target” (goal) for the project.
This role designs a strategy that will work (factoring in the platforms being integrated, business goals, the technical complexities, the many tradeoffs, etc). It’s tricky. It’s required. And it’s the absolute foundation for success.
This is the single most critical role for an integration project. You can NOT miss when filling this role (it is a must get right assignment).
This must be filled by 1 and only 1 person.
The person must have strong technical skills, the ability learn from and leverage documentation + consultants / experts on each of the platforms being integrated to make high quality decisions on data mapping
The proper assignment of this role probably equates to 50% of more of the overall risk on an integration project.
If you have a weak (or no) Solution Architect, your integration project will be slow, painful, and expensive… and will most likely either fail or result in you finding a google Solution Architect to fill the role.

Key Responsibilities

This role is responsible for the following (this is focused on integration projects):

Sitting in the middle of the major components of an integration and making sure there is a plan and strategy that will make them all work together. Those 5 components are the 1) the CIMcloud platform, 2) the software application being integrated with CIMcloud, 3) the technical planner / developers who have to “code” the integration, and 4) the business / business needs, 5) the project planner / managers who are responsible for making sure the project gets done, and 6) the operators / users that have to execute after project goes live.
Creating The Data Mapping Sheet (this is one of the key tools / documents)
- This is the table and field-level mapping that shows exactly what data tables and fields will move in each direction.
- This requires making decisions on what will server as SOR (System of Record) for each table and which syncing strategy will be deployed for each table (pull & discard, 1-way, 2-way linear, 2-way same table).
- This requires insuring that the field-to-field data formats will be compatible and/or addressing any data clean up, new validation, and/or lookup / translation logic that will be needed. The the technical planning section for more details and examples on field-to-field mapping and translation.
- This requires understanding any “tricky logic” related to the data that will sync in both the source and destination platforms
  - Example: Pricing settings need to sync from an ERP system to CIMcloud.
  - This is a more complex problem to solve, but it demonstrates the need for a strong Solution Architect.
  - The SA must have a firm understanding of how the CIMcloud pricing engine works, how the ERP’s pricing engine works, and how pricing is implemented in the ERP (i.e. which parts of the ERP’s pricing is being used). They then have to determine how the data will be translated from the ERP systems’ pricing engine (they literally have to understand how the pricing data is stored and how it feeds into the logic / output that a customer sees) to the CIMcloud pricing engine (they have to understand this data structure and logic as well) to result in the correct price showing up for each customer. If there are pricing rules being used in the ERP system that won’t work in CIMcloud, they would work with business stakeholders (and potentially the CIMcloud consultant and/or the ERP consultant) to see 1) if the usage of the ERP pricing engine could be changed to insure compatibility, or 2) if the incompatibility is an acceptable business outcome, or 3) if there is a workaround or some capability in the CIMcloud pricing engine that could work (the CIMcloud consultant could potentially help with this), or 4) if a customization could be done in CIMcloud (by the CIM pro services group) to make the pricing rules work.
Creating a prioritized “sort” order for the integration work to be completed in (including determining if some work will be broken out into future phases).
- This results in recommendations and direction to 1) the technical team (so they can do work in a business-friendly order), 2) the project planning and management team (so they can manage / insure the high priority work is getting done first), and 3) the program manager / business stakeholders so they can confirm or correct the business assumptions behind the recommendations and make the final decision on what gets added to the current phase (vs. potential future phases) of work.
- This includes understanding exactly which tables of data are critical vs. nice to haves when it comes to completing the integration.
- This is based on balancing the work / complexity/ risk involved, the business needs and potential return on investment (with regards to the data being integrated / synced).
- For example, if syncing from an ERP system to CIMcloud, the ERP system may contain sales tax calculation settings that need to be translated and sync to CIMcloud’s sales tax engine. The SA may determine that syncing products, inventory levels, and pricing is far more important than syncing the tax settings because most of the business’s customers are B2B and pay via invoice… so a phase 1 deployment could involve just showing a message when orders are being placed saying “sales tax (if applicable) will be added to your invoice”. The SA would know that 1) CIMcloud is can support that messaging, 2) the business needs / use-case will allow that as a solution with little to no negative impact on customer adoption, and 3) the technical complexity of accurately translating and syncing tax settings between the two systems is high.
Create the Live Data Take-over Plan (this one of the key tools / documents)
- This only applies if 1) the software that is the destination for data that will be syncing is already live, and 2) the data that will be touched by this integration project is in use and critical to the current live operation of the destination software. In short, you need a plan to make sure this new integration won’t screw up the live operation of your existing software.
Work with the Project Planner to make sure their project plan (the list of tasks and who will do this, when they will do them, etc) makes sense.
Work with the Technical Planner to make sure the software development work will deliver the require results.
Work with the team throughout the project to address any need for large deviations / changes to the two documents (the Data Mapping Sheet and/or the Live Data Take-over Plan).

Visual Diagrams of the SA Role

Diagram #1: Solution Architect Role (Any Technical Project)