Solution Architect

Solution Architect job covers many aspect of the work including solution design, business analysis and a deep reflections. It requres both business and tech expertise.

Like in every responsible job, training self reflection and managerial reflection is a key to grow the efficiency of personal work and the team work around you. With that in mind, I would like to start with listing the key habits that help you being efficient in all aspects of life:

IMPACT = CREATIVITY × ORGANIZATION.
Be Proactive.
Remember about the end goals.
Focus on important issues and limit urgent issues.
Build → Measure → Learn.
Problem → Solution → Magic.
Search for Synergy.

In my blog post: Essential values for Personal Development I write more about Personal Development activities that improve awareness, skills and develop potential.

Business - Engineering responsibilities

Analyze and design the "to-be" functional business processes.
Work closely with other members of the Architecture and Solutions team as well as engineering team leaders to ensure consistency and dissemination of knowledge across the team.
Work with the product and operations teams to assess current capabilities and identify high-level customer requirements for change.
Recommending innovations which enhance the operation and functionality of Client systems.
Drive compliance to the firms Security, Data Privacy & IT&S Standards within solutions and see through any exceptions.
Proactively identify and effectively mitigate architectural risks
Participate and give technical advice in decisions related to work prioritization and roadmap planning.
Be conscious of the costs of architectural decisions and take these costs into account when jointly making important decisions.
Analyze time, cost, scope with regards to quality.
Manage and evolve legacy solutions. Synthesis existing solutions and integrate with legacy technology when appropriate.
Manage a risk of legacy solutions and make sure to not break the client adoption.
Understand market and customer needs.
Understand the project vision.
Be creative and be aware about difficult decissons.
Think win-win.

Social aspects

Collaborate to bring everyone together around the same design.
Empower and listen.
Kill your Ego. Respect others, especially someones else efforts and experience.
Synergize: the best architectures, requirements, and designs emerge from self-organizing teams.
Support and encourage.

Deliver-ability.

Here we want to ensure that we have right research and development balance with right. The key principle here is the Lean Startup action loop:

Build faster → Measure faster → Learn Faster

Remember the end goal and respect the roadmap.
Begin with end in mind.
"Think twice, develop once".
Prove out new technologies through proof of concept work.
Design limited PoC: minimize, cut and minimize again.
Have a quantitative approach - always measure: time, efforts, technical debt, risks, evolution, how far we are from a production grade product. (this is a joint work with product owners, team leaders and other architects).

Engineering aspects

Be proactive
Design for an evolving software.
Design technical solutions (features, libraries, components, ...) for business requirements and objectively document how well the solutions satisfy the requirements.
Break down solutions into smaller tasks with clear acceptance criteria and a short completion time
Review acceptance criteria of critical task assigned to developers.
Communicate technical details with scientists, researchers and developers.
Define subsystems and their interfaces, allocating clear responsibilities to subsystems.
Document the architecture and technical solution decisions in a common source of truth location
Evaluate and select appropriate software or hardware and suggest integration methods.
Select appropriate solutions to problems. Try to reuse existing solutions (both internal and external).
Make sure the system is flexible enough for future extensions.
Ensure system is testable -- make sure things are easy to test.
Ensure acceptance tests are well defined.
Don't over-engineer.

SOLID principles

Many of us know the famous SOLID principles that were defined for software engineering. Their goal is to make software designs more understandable, flexible, and maintainable by reducing dependencies and making the system easier to extend and refactor.

Interestingly enough we can apply the to Business as well!

Single responsibility

“Do one thing and do it best.”

Software: one component should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the component.

Business: Role Clarity & Specialization. Avoid creating "hybrid" roles that mix conflicting objectives (e.g., a Sales Manager who is also responsible for Quality Assurance). When one person chases two opposing metrics (speed vs. perfection), both suffer.

Open–closed

“Grow by adding, not by breaking.”

Software: Software entities should be open for extension, but closed for modification. Don't break interfaces (keep them closed). You can extend them or change components implementing them.

Business: our core business operations (hiring, billing, customer service) should be robust enough to handle new product lines or markets (extension) without needing to rewrite the entire company policy or disrupt existing workflows (modification).

Liskov substitution

“Reliability allows for interchangeability.”

Software: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Business: If you have a "Senior Accountant" and an "Accountant," the Senior must be able to perform all the duties of the Junior without the system collapsing. Furthermore, if a manager leaves, their successor should fit into the workflow without requiring the entire team to change how they work.

Interface segregation

“Information on a need-to-know basis ensures focus.”

Software: Many client-specific interfaces are better than one general-purpose interface.

Business: Don't burden employees with big meetings (limit "all hands"), CC’d emails, or reports that don't concern them. Tailor KPIs and dashboards to specific departments. Marketing doesn't need to see the granular details of server latency logs; they only need to know if the site is up.

Dependency inversion

“Commit to the mission, not the method.”

Software: Depend upon abstractions, not concretions.

Business: Build your business on high-level goals (Abstractions), not specific tools or vendors (Concretions). Bad: "We are a Zoom company." (Breaks if Zoom fails). Good: "We prioritize face-to-face remote collaboration." (Tool agnostic). The C-suite sets the "What" and "Why" (abstract); the teams choose the "How" (concrete).

Cohesion

Software Engineering

Cohesion refers to the degree to which the elements inside a module belong together. It is a measure of the strength of relationship between the methods and data. Stronger cohesion => better organization!

Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.

High cohesion often correlates with loose coupling, and vice versa.

Business

Purpose-Driven Teams. In a business context, a "module" is a team, department, or business unit. High cohesion means that the people, resources, and skills within that unit are all tightly focused on a single, unified mission.

High Cohesion (Good): A "Product Squad" consisting of a Product Manager, a Designer, and Developers who all work solely on the Mobile App. Every conversation they have is relevant to everyone in the group.
Low Cohesion (Bad): A "General Operations" department that contains HR, IT support, and Janitorial staff simply because they didn't fit elsewhere. They share a budget but have no shared goals, resulting in wasted time during meetings and fragmented culture.

Relation to "loose coupling"
Autonomy. If your Marketing team is highly cohesive (they have their own designers, copywriters, and data analysts), they are loosely coupled to the rest of the organization. They don't need to constantly beg the central Design Department for help.
Result: They move faster because they depend less on others (Low Coupling) while being tightly aligned internally (High Cohesion).

Are all this principles important?

Let's have a look.

Robert Zaremba