Solution Architect

Solution Architect job covers many aspect of the work life cycle as well as solution design and business analysis. Here I want to cover aspects of this job.

Like in every responsible job, training self reflection and managerial reflection is a key to growth 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 to be more 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

Single responsibility: 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.
Open–closed: 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.
Liskov substitution: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface segregation: Many client-specific interfaces are better than one general-purpose interface.
Dependency inversion: Depend upon abstractions, not concretions.

Cohesion

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 class's methods and data themselves.

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.

Are all this principles important?

Let's have a look.

Robert Zaremba