At a point of a complex Agile project, from client or consultant perspective, have you ever asked yourself “Am I supposed to do that? Is it the scope of my colleague/partner? What exactly, as System Integrator, is the job of the Solution Architect?”

Rather you are a Solution Architect, a Development/Functional Team Member, a Product Owner, a Scrum master or a Project leader, rather the project is complex or not, the aim of this article is to help you to know how a Solution Architect will help an Agile implementation project to its success. It also might be helpful to read this when the project becomes “challenging” and positions are getting questioned.

I personally lived this kind of project where we asked each other what the best position for the Integrator Solution Architect (ISA) was. It was needed to (re)communicate, especially with part of the team offshore, why the ISA seems sometimes far away of the front and why he/she doesn’t reduce regularly his/her remaining time on the scrum.

After enquiring this article, you will be able to understand the Integrator Solution Architect (ISA)’s position in a project and how his/her implication is a key success factor from various perspectives:

  • Firstly, we’ll be reminding the ISA’s functions,
  • Secondly, we’ll be describing his position compared with the editor,
  • Then, we’ll be looking his position compared with the client,
  • Finally, we’ll be examining his contribution to his own system integrator team.

Integrator Solution Architect (ISA) key functions

For this article, let’s take the context of a complex solution implementation, such as a Product Lifecycle Management (PLM) project I personally lived. During the past decade, the project management improvement led to Agile methodologies, at least for the core solution implementation.

About its organization, we might have at least three kinds of stakeholders as below:

SOFTWARE EDITOR is the stakeholder that provides the out of the box solution. We will call him “editor” in this article.

CLIENT is the company/entity which will use the software solution in a business context. In their context, the project usually implies:

  • the CIO (Chief Information Officer) and IS/IT as they are responsible of the digital solutions landscape of a company,
  • the Business members who will use the solution within a targeted scope, and
  • the Project owner of the solution implementation.

SYSTEM INTEGRATOR is the contractor leading the implementation of the business scope, adapting the out of the box solution, and managing the deployment with potential migration and interfaces. System integrator might be an entity of the software editor or not.

The Solution Architect involved during the entire project belongs to the System Integrator entity. However, in the context of three stakeholders as above, the Editor needs another solution architect at least during the presales phase and partially during the project.

The project is defined by many transformation phases and streams described as below with the suggested Transformation life cycle of:

Chronologically, the ISA takes the lead on Vision:

  • By drafting the main solution epics and features,
  • By studying the feasibility of the targeted system (Architecture Plan),
  • By replying the business requirement,
  • By describing the fit/gap analysis and quoting the specific developments.

Then on Workshops:

  • By planning the macro project implementation in order to plan the amount of releases and sprints,
  • By prioritizing the workshops planning accordingly,
  • By leading the workshops in order to define and refine the solution with the Product Owner and Business.

ISA with the System Integrator Project Lead & Client Lead Team is an ambassador of the Agile methodology to be followed by the project.

Right arm of both Integrator Project Leader and Client Product Owner (PO), ISA is responsible of the functional delivery and reliability. He oversees the functional part of the contract which has been dealt between the Integrator and the Client.

Last but not least, ISA plays a key role in the convergence (migration, interface, change management) and the deployment phase preparation.

These different roles follow one to another according to the project progress:

In another perspective, the following picture shows the main interactions and actors with the ISA:

Indeed, we will differentiate flows of about:

  • Suggest/Decide: which is a decision-making flow for the project,
  • Share: in order to challenge the technical path to be used,
  • Teach: in a training approach,
  • View: in order to inform and detail the architecture strategy in perspective,
  • Secondary flow of information: a flow which is triggered by the Solution Architect but managed by another entity in order to support the Solution Architect role and position.

We will be detailing those flows and interactions in the following parts of this article.

Note that, according to the complexity and scalability of the project:

  • ISA can be leader of many other ISA,
  • PO can be a leader of PPOs,
  • Agile Development Team can be many specialized Agile Development Teams.

It is not because ISA has “Solution” in his position title that he is the only one to contribute to the “Solution” success. First actor for that is, of course, the editor.

Editor – Integrator SA Partnership

The editor and its own Solution Architect (also called Solution Expert) have the full legitimacy to define the architecture plan of the solution to be put in place for a need expressed by a client. Moreover, the Editor Solution Architect will also contribute as well as promoting Software coming roadmap (new features covering potential today development, etc.).

Depending in the size and complexity of the project, Editor Solution Architect (ESA) and Integrator Solution Architect (ISA) might be the same person. They may belong to the same company/group or not. Nevertheless, ISA and ESA usually depend on different entities in order to protect them in respect with the defined RACI. Let’s take the assumption that those roles are ensured by two different persons for the rest of this article. Considering this, it is for the best to respect those different positions and roles in order to keep harmony on the project.

During the pre-sale’s activity, ESA and ISA both define the macro assumptions to be followed by the client and the chosen integrator. The big picture vision is shared between ESA, ISA and of course between SAs. This vision is shared too with both system integrator Project Leader and client Account Manager. This last flow should be maintained regularly during the project as it might be source of future opportunities and/or quoted mitigations.

As soon as the project starts, the ISA becomes a buffer of the requirements expression to the solution to be chosen and implemented. Because a project has impediments, the ISA shares with the editor and more precisely with the ESA the new issue or level of details on particular requirements to be addressed. This allows a continuing vision with consistent recommendations. It also ensures trust between client and editor solution without by-passing the system integrator skills. As a secondary flow of request, the ESA has the correct position in order to ask Editor R&D on complex recommendations or improvements in case a deeper level of expertise is needed.

In terms of positive results, the best examples I have with the editor – system integrator partnership is a process where, without any particular contract between them, except few days of ESA provisioned by the client, the system integrator anticipates and keeps the editor on the loop of any change on the implementation approach and chosen solution by the client. By the other hand, the editor provides needed resources in order to advice and to confirm the SA’s vision. This allows a bilateral anticipation in case of major impediment on the project. With this process, and thanks to the editor resources along the project progress, editor keeps the position of design authority.

Client and ISA Trust relationship

As soon as demos or proofs of concept happen, the Solution Architect and especially ISA will be a creator of the long-term contact between:

  • the targeted system and the Product Owner (PO),
  • the targeted system and the Key Users (KU), and
  • the targeted system and the Business users.

In parallel, and of course at the beginning of the project, ISA is an ambassador of the Agile Methodology, especially if the Scrum Master is not yet involved on the project (before the kickoff for instance).

What seems nice and fantastic at the beginning will become concrete and specific. This journey is clarified by the workshops and the agile methodology itself. The ISA has to lead to solutions and to address them in order to provide to the PO the complete inputs panel. This will help to select the best to the client company and the future business users. ISA is the main character to move from requirements to functionalities. Even if a vision is defined at the beginning, with details, ISA doesn’t always have the accurate answer: part of the job is also to read, learn, adapt to client and business needs.

PO Client with the business owner team have to ensure the scope completeness of the solution. That’s why, the ISA is the PO’s project partner and right arm in order to:

  • Understand the key solution points and efforts,
  • Structure the Product Backlog from the requirements to the solution using User Stories,
  • Prioritize it in order to identify “Should have”, “Must have”, “Nice to have”,
  • Create the implementation plan among the releases and sprints,
  • Help in client decisions, especially when he asks to review the business process in place.

Those last one is helpful to argue in front of the business across both Core solution stream and another stream such as Change Management or Interface stream. This is where, together with the PO, ISA takes a guardian position of the Value (where ).

During the sprints and when the product backlog is refined, a significant mitigation work is regularly done by the ISA and PO to agree if a requested specific development is in or out of scope:

  • If it is due to an initial misunderstood by the system integrator, then the ISA will find the best feasible solution to fit with the initial requirements without client contractual impact.
  • If it is due to a wrong requirement expression, then the classification of “must have”, “should have” and “nice to have” functions, might allow to perform a swap, according to their weight in terms of development time and complexity. As a consequence, the scope will remain the same between the client and system integrator.
  • Last category: the wrong needs. They usually happen when a legacy system had a technical limitation and now the target system asks to find another process to ensure a given functionality. They must be identified by the PO and the ISA in order to keep a lean system. Compared with the previous one, they must be flagged on the Product Backlog as “out of scope” with a comment and not as “to be implemented in future release”.

The entire relationship between the PO and the ISA is based on trust and transparency in decisions, dialog, and work activities. With them, the ISA is a bridge between the PO and the Agile Development Team. Otherwise, agility doesn’t work.

ISA serving his integrator team

ISA is usually involved by his team during the pre-sale’s activities and until the deployment. His/her knowledge helps not only to build a consistent technical and functional answer but also to quote the project. This part allows to define the team composition and to have a first sketch of the targeted solution.

As soon as the project is confirmed, the kickoff preparation is crucial for the good process of the project. The ISA helps the Project Leader to share the good message on Agile methodology to be applied. More than with the client, this kickoff phase is an opportunity to put in place internal rules between the Project Leader, the Scrum Master, the Agile Development Team and the ISA. If team members already know each other, it is time to cross-check and use previous concerns and retrospectives to put in place the most appropriate organization. When the project is launched, the newbies are always surprised by the speed and rhythm of sprints. Their concerns are an opportunity for the ISA to remind the project vision and share the big picture again.

Trust with client is consolidated by trust with everyone across the system integrator teams. The swap system, as explained previously, must be followed during the project in order to be able to keep the scope as defined and must be communicated with everyone. Otherwise, frustration of the business and the Agile development team will grow together. This is why, business concerns and functional issues should be shared with the Agile Development Team in order to maintain harmony. ISA helps the Scrum Master for a part of this communication between the PO and the Agile development team. He also keeps the vision to the next steps in order to help the Agile development team to anticipate.

But before that, the ISA is responsible of the quality and reliability of the delivery. Regular cross-checks needs to be done on the choices made by the Agile Development Team and on tests purpose. In order to do that, every project has its own rules. One effective way is to use User Story start and finish meetings with responsible of:

  • Business case (Product Owner),
  • Context vision (Solution Architect in charge of the Epic),
  • Dev and Test responsible (Agile Development Team member(s)).

Those meetings, in the context of the sprint, have as first intent to remind to the PO that his/her story is taken “now”. Thus, he/she must be ready to answer potential questions during its development time. Then, the intent is to make sure the story is well understood by every stakeholder and pre-validate it during its development in order to make the sprint review smoother. Finally, it joins the project members together, it pushes the Agile team member(s) in front of the scene and thus it improves the decentralization of decision making.

This last point is very important because ISA is NOT a super Agile Development team member, but only a Solution Architect. He/she is a resource for the Agile Development Team in order to start on a good path of technical/functional solution and to take the time to interact with the editor or client in case of concerns.

Therefore, ISA must be placed as a resource out of the Agile Development Team. This place, out of the team, must be compensated by trust. Indeed, ISA remains a compass to keep coherence between the streams and epics. His/her job is to stay free for every question raised by the Agile Development Team members and to ensure regular status of the project progress in the solution context. In my past experiences, this last point is always touchy. Retrospectively, just after the sprint planning is a good time slot to put in place a “30 min” meeting in order to share a big picture of where the project stands in the context of the solution and the implementation plan.

Right arm of the Project Leader and the Scrum Master as functional/technical leader, he/she will help for project decisions and planification of project phases in terms of needed resources: ISA’s expertise participates to predict if any specialization or punctual skills will be needed during the project. Moreover, ISA might be involved at the highest level to light a topic which requires technical explanations and quotations, always in the perspective to smooth the decision process.

As mentioned earlier, ISA has a key role in the implementation project convergence. Indeed, as the solution is in the center of the targeted system and as it is built on another technology compared with a legacy, the other streams (migration, interface, change management) need information and advices for decision making. This is very critical to keep the coherency of the global ecosystem and this must be considered at the very beginning of the project. ISA occupies this place due to the centralization of information. This is where he becomes an historian. At least, he will be able, as community manager, to create the contact between the good persons.

At this point, we can transpose into a kind of temple of skills for ISA like:

In conclusion

ISA is needed in a complex project implementation in order to maintain the vision and technically share information between actors. According to that, he/she helps the Agile development team(s) and Product Owner to keep control on the target. Moreover, the consistency of the targeted system to implement is ensured compared with the editor initial intention and the global ecosystem of the target.

This is done thanks to:

  • The Editor and Integrator Solution Architect partnership,
  • The Client and Integrator Solution Architect trust relationship,
  • The fact that the Agile Development Team and the Scrum Master use the Integrator Solution Architect as a resource in order to move forward and improve the delivery.

The second aspect to define the position of the Integrator Solution Architect is that she/he must focus on different topics according to the progress of the project. Indeed, holding the vision in mind and sharing it with people, keeping a mentoring aspect on the team, suggesting, and deciding preferred paths are the main competences of ISA.

Communication and harmony must be key assets of the Integrator Solution Architect during a project as she/he will seek the global conciliation in order to hit her/his target: a successful project with satisfied members.

References

Andrew K Johnston / Questa Computing Ltd. (2015, 05 11). The Role of the Agile Architect. Récupéré sur Agile Architect: http://www.agilearchitect.org/agile/role.htm

Boisvert, M. (18, 02 16). Le rôle de l’architecte Agile. Récupéré sur https://fr.slideshare.net/pyxistech/le-rle-de-larchitecte-agile-jeanren-rousseau-mathieu-boisvert-frdrick-lussier

Scaled Agile, Inc. (2019, 12 30). System and Solution Architect/Engineering. Retrieved from SAFe: https://www.scaledagileframework.com/system-and-solution-architect-engineering/

Scaled Agile, Inc. (2020, 02 24). Agile Architecture in SAFe. Retrieved from SAFe: https://www.scaledagileframework.com/agile-architecture/

 

Author: Olivier Jacquot, Inensia Senior PLM Consultant 

About Polina Todorova