I am currently preparing to take the Microsoft Dynamics 365 + Power Platform Solution Architect certification. Or “MB 600” for short! As I prepare I plan to write revision notes in this post I will cover topics connected with the heading “Identify organization information and metrics”.

The skills measured statement for MB 600 mentions the organisation’s business processes and risk factors. Therefore in this post I will include my revision notes related to these two topics.

Identify and document an organization’s business processes

A key first step in evaluating business requirements will be “getting to know your customer” which will begin in the initial discovery phase.

You should begin by completing research about the customer, this might be via the internet or by interviewing key business stake holders. Below you will see a list of some types information you might wish to collect in the “getting to know the customer” phase;

• Corporate Information:
  
  • Detail any products line / services.
  • Obtain a definition of any key corporate divisional structures. (For example, one division may “look after” a particular product line whilst other divisions focus on other products. Or maybe the company is divided based on functions such as R&D, sales or service.
  • Record details of headquarters and regional offices.
  • Locate any stock / earning information. (For example, a search on companies house may prove useful.)
• Culture / News:
  
  • Understanding the corporate culture can help you appreciate how the company “ticks”! You can do this in several ways;
    • Reviewing any company press releases.
    • Read posts on social media accounts. (Both official and unofficial accounts.)
    • Listen to what others say about the company. Maybe read news reports, social media posts and product reviews.
  • If possible identity the top pains points created by the corporate culture.
• Organizational Structure:
  
  • Identify the c-level executives. Obviously you’ll want to know their names, job titles and contact details. But also try to understand a little bit about their current and prior work, maybe connect with them on social media. (aka LinkedIn).
  • Additionally review the profiles for key stake holders in the specific project being delivered.
• Current Approach to Technology and development:
  
  • Does the customer prefer any specific cloud providers / services?
  • Are there any openly stated technology preferences?
  • Are IT services delivered by inhouse or 3^rd party providers? (Assuming you are representing a Microsoft Partner, identify other 3^rd parties that might be involved.)
• Request for Proposal (RFP)
  
  • Often you will be responding to an RFP. These can be weighty documents that will contain much information about why the system is needed, who the key stake holders are and more.
  • Consider the authors of the RFP! Sometimes the documents are written by the business owners but they can also be created by IT. Understanding the authors and their point of view can be valuable.

A discovery phase is a common early approach to understanding the current and proposed solution. Although customer discovery is actually an ongoing process. It maybe performed in pre-sales, during project kick-off and continued throughout each iteration of solution building.

A Solution Architect may be presented with a well-documented set of existing requirements. Other times workshops maybe needed to tease out this information. The documents and workshops can lead to a mass of requirements, some of which will be just “noise”. The Solution Architect will need to extract / collect a set of actionable requirements that will help drive the project towards the stated goal. In workshops it may be the Solution Architect’s responsibility to ensure that focus on the goal is maintained and the requirements being discovered are relevant.

Many techniques can be leveraged to help with these discover activities including;

• Holding workshops – if doing this circulate an agenda in advance and ensure the meeting stays on track. Often making notes on whiteboards or writing requirements on post-it notes can help define, refine and prioritise requirements.
• Surveys – sending questions to key stake holders can help capture requirements and also gain insights into priorities.
• Job shadowing – Often “user champions” within the business may have been identified. Shadowing these champions to understand their pain points can be very helpful. It is also important to note what currently works well … as the new system must avoid “breaking” these things!

The most important question a Solution Architect must keep asking is “why”!

Creating a dictionary of business terms maybe very useful. Many industry sectors have their own sets of terms which imply very specific things to the customer. Documenting these terms can be useful. I worked at one company when the same phrase implied different things to different divisions of the same company. Documenting these differences and agreeing a common vocabulary can be an essential task. Just consider for a second the word “customer”. Even such a simple term can mean different things to different people!

When considering the business processes the Solution Architect should also consider the data which supports those processes. Understanding current and future requirements for what data is held, where it is held and what retention policies exist maybe a significant task. Additionally the Architect should consider any privacy policies or data access laws which may influence the final design.

Assess organization’s risk factors

Sadly … if it can go wrong, it will go wrong!

Risk management is therefore a key activity within every project, generally speaking identifying and mitigating risks will be the responsibility of the project manager. But the Solution Architect can and should play an important role in the management of risks.

The Solution Architect maybe a key member of the project governance team(s). They will help manage changes in scope, risks and much more. It will be common that the customer already has their own governance processes, that the Architect should work within. But if no process exists it should be the Architect’s duty to push for the creation of agreed governance processes.

Understanding what the risks are within an project and how to avoid them is obviously a critical task. There are several typical approaches to handling risks. Including; Risk avoidance, risk reduction, risk sharing and risk acceptance. You can find out more about general risk management concepts in this Wikipedia post.

The Solution Architect is well placed to spot issues or gaps in the requirements around topics like regulatory compliance, auditing and security. All of which if not filled could result in risks on the project.

Governance and risk management should be kept inline with any contractual terms agreed with the customer. For example, if the contract includes any statements around the expected quality or performance of the application then processes must be in place to ensure these terms are delivered.

There maybe many risks associated with the proposed solution. The Solution Architect must recognise these and communicate them to the project manager / customer. For example, is there a risk that the proposed design will not reach future performance expectations? Or will technical complexities in the solution make it challenging to deliver within the specified timescales?

Some organisations will have a very low tolerance to risks associated with data breaches or unauthorised system access. The Solution Architect will be responsible for defining a security architecture that will protect the customers assets. This process may begin with a discovery session to learn about the clients environment. They will then need to map any security policies and requirements to the proposed design. Security may take the form of network access security. Or it can also imply access restrictions to specific entities, records or even fields within the solution.

The Solution Architect may need to assess any risks associated with any proposed integrations. How stable is the design of these integrations? What will happen if any external systems aren’t available? How will support staff monitor the integrations post go-live and what steps can they take if/when issues arise.