Application Architect and How to Document Salesforce Application Architect?
Application Architecture: What Is It ?
One of the many architecture domains that serve as the foundation for an enterprise architecture is application architecture.
- It explains how business applications behave, with an emphasis on how they communicate with users and one another.
- It focuses on the data that applications generate and consume.
- It outlines the users who are using the application and their permissions to access it.
- “Defining the major kinds of application systems necessary to process the data and support the business” is what TOGAF says it is.
Architectural Overview – How to Document ?
- Captures the SCOPE of the project
- Describes the current, interim and future state architectures
- Points to relevant artifacts / documents
- Unifies a project team
Key Artifacts
- Context of the system: Optional
- Current and target system landscape diagram: Suggested
- Data model: Required • An optional logical data model
- Entity relationship diagrams and physical data models are required.• Role hierarchy: strongly advised• Process flows or sequence diagrams are advised.
- Test plans are typically represented in documents or models in test management software. Functional and non-functional requirements are mapped to solution components using the Traceability Matrix.As required, release notes and handover paperwork are provided.
System Context Diagram
- Specify the main “Actors” and the scope.
- Describe the components of the system.
- Don’t try to explain technological design.
System Landscape
Important elements (apps and systems)
The new and retired items that are currently in use
Important Salesforce licenses and actors: • Which license or licenses are used by which actors?
Key third-party systems or apps, either single or multi-organization
How will the data be migrated—initial or ongoing?
Data Model
An entity-relationship (ER) model describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between instances of those entity types.
- Record every entity
- Document the connections between things
- Make a clear distinction between physical and logical data models.
Sequence Diagrams
A sequence diagram illustrates the relationships between things and their order of operation.
- A thorough examination of the main interactions
- Explains the messages and timing between the various parts.
- Explains the relationship between async and sync
Role Hierarchy
- Not always the HR hierarchy of the company
- Pay attention to the data privileges.
- If something is repeated, don’t sketch it in its whole!
Business Requirements
What constitutes a suitable prerequisite?
- Making Use of a Template
- Using a hierarchical framework for organization
- Using a common language for your requirements
- Maintaining consistency
- Making sure every criterion can be tested
- Outlining criteria that are functional versus non-functional
- Establishing Presumptions
- Outlining What Is and Is Not Within Scope
What about User Stories?
A user story is a brief statement describing:
- What can be done using the solution
- By whom
- For what reason
- Should be expressed in the voice of the user
As a <what type of user>
I want to <goal>
So that I can <business objective>
■ By whom
Why should the user’s voice be used to convey this?
Business analysts and developers can better align with each other through the use of User Stories.
However, they don’t cover the system as a whole.
Non-functional Requirements
Quality qualities that outline the functions of the system, including:
Data Integrity in Regulations Usability Qualities
