Architects leverage the Human instinct communication and pattern recognition. They must spend time and listen to the business team to understand the business process, and leverage the solution to the business groups needs, then communicate the solution to the business combining the business groups needs with the new solution process. Further improvements on the business process should focus on user ease-of-use and corporate ROI benefits.
Listen to the Business Team
First step is understanding and listening to their current business process.
Understand
Gain some business knowledge by asking to review the documentation of the current business process. You can tell a lot by the documentation given. If the documentation is a pdf from the software provider, it is likely that the information is embedded in a few resources (or corporate knowledge) with they rest of the business depending on the longevity of those resources. More extensive user created documentation is great since, at one point, the business has embraced the business process.
Once given the documentation, use it. Go into the previous solution and do up to five transactions. This can give you a window of what the user base is doing. Make notes in the document, as this will empower you and your stakeholder during your workshops.
Listen
Workshops are a favorite time of a project for me. As a sports coach, workshops are like bringing a basketball to the offensive side of the court and setting up the offense. An architect’s goal is to gather the stakeholders and discuss the current business process step by step on a whiteboard, with out bringing out the current software. I have led multiple workshops where the discussion was on a process like Procure-to-Pay, and stakeholders that have sat next to each other for years, start to truly understand what their peers beside them do. Bring the documentation you were given with your notes and incorporate that onto the whiteboard process flow, and take picture of the process flow that are documented in your Solution Architecture document.
This is also the first risk of scope creep. Your goal is to listen, not solution. Have a second chair at the meeting to records all the clients needs, wants, desires for the solution. Make sure your meeting primary topics are covered and the meeting ends a few minutes early.
Leverage the Solution
Solutions architects are experts in pattern recognition. We are given a business problem statement and recognize a solution pattern that may fit and investigate more through the Listen to the Business Team step to find out more information. Solution Architects leverage their experience, training and additional research to provide a Solution Architect artifact for the project to implementation. Given the business history and the problem statement, a solution is documented that best fits the business process on the solution desired.
This section requires a brief description of Architect roles:
Business/Enterprise Architects – Large to Enterprise Corporations: Focus on Business processes specialization and IT Enterprise resources.
Solution Architects - All corporations: General Business process expertise and Solution software stack.
Technical Architects – Enterprise & IT corporations: Specialize in specific software.
Solution Architect are commonly misrepresented as Technical Architects. As a Solution Architect, I focus on Microsoft Dynamics and solution related to those ERP and CRM solutions and while I can develop in CE, GP and BC is just because of my length in the industry and not common in the Solution Architect role. Technical Architect focus on a specific software solution like Dynamics 365 CE.
A note on Innovation
Innovation is a seductive buzzword used on most projects now. Yet businesses still try to 'be-married' to previous business process while being innovative with new software. The two objectives don’t correlate. During the Covid lock downs, businesses had invocation thrust upon them be forcing them to change their Order to Cash process or close their business. The short way of establishing a business’s capacity of innovation is to force them to think about how a business process can be completed if their current system was unavailable for the foreseeable future. The resulting process will merge innovation with business need (also give the stakeholders a fresh take).
The Goal: Solution Architect artifact
A failure to plan is a plan to fail. Project Managers rely on a project plan for a project status. A Strong Solution Architect artifact is life blood to how the project is completed. Putting in back to Basketball, the coach is the solution architect that implements the offensive/defensive systems. Without those systems the players are just playing street ball in a team game. Without a Solution Architect artifact, the project is bound to miss targets, if not be an outright failure, or cancelled.
There is a tendency for Solution Architect artifact to be a fixed document. My success has been to leverage the document as something that changes throughout the project. I will leverage corporate Wiki pages or something similar to allow for version history, wireframing, cross functional diagrams for the different stakeholders and their interests. Control Forms are also heavily leverages to minimize procedural changes (leveraging my past Biopharmaceutical experience).
Communicate the Solution
The first version of the Solution Architect artifact is never the last version. Once presenting the solution, changes and clarifications will need to be made. The riskiest part of planning the solution? Exceptions. Human nature is to appease another peer group or follow the will of the group. When completing changes and clarification, Solution Architects must ensure that the overall project objectives are being maintained. This is hard (if it was easy, then everyone would be a solution Architect with over 20 years experience), as several of your project wants and desires need to be backlogged or even said no to as they don’t meet the project goals.
The Solution: Solution Architect artifact
This artifact must be your rock of communication. With a focus on:
- Ease of Use: When defining business processes. Simplify, simplify, simplify. Continue to document and create process flow diagrams until all parties understand the process. This isn’t wasted work as this documentation will be used for onboard resources onto the new business process and even future training.
- Diagraming: Pictures are worth a thousand words and diagrams visualize how a process moves to each stage and responsibility. Diagrams cross language barriers better then translating a document.
- Exceptions are decisions: A common mistake is to discuss process decisions as exceptions. Exceptions are seen as customizations and unique tasks. The funny thing about exceptions since they are treated rare occurrences, they are solutioned as such and cost the project time and money. By treating exceptions as decisions, a proper business process flow is defined and saves money.
In writing this first article, I've noticed I can write chapters on each heading or even sub-heading. Having spend almost 25 years in Business Software focusing on ERP and CRM business processes for Microsoft Dynamics (and other solutions), I have been asked to conduct Business Processes workshop for some very large corporations across North America that use Microsoft and Non-Microsoft software. Regardless of the size the corporation and the project needed a solution architect, the fundamentals of Listening to the Business Team, Leveraging the Solution, Communicating the Solution is used every time. As your experience grows, your template tool box grows with every project. I am sitting on 50ish templates that I can bring to bear on any given project and that list grows by a couple template ideas every project.
Please let me know of any questions or comment on additional topics or information you want to see.
Next article in this series will be on Designing Holistic Solutions
Thank you and have a great day.
