Developer vs Architect

Imagina en una orquesta que tocas el violín, el director debe dirigir como ira la orquesta, de así
trabajar juntos con los instrumentos y las habilidades del compositor.
Conductor = Architect
Instruments = Developers

 Keep many different components in your mind.

 Have a rudimentary knowledge of how they all work.
 Software Architects focus on the big picture.
 High-level understanding.
Potential Questions

 Will a performance change occur?

 Will it cause another component to behave differently?
 How will it impact the application?
 Will it expose a bug?
 Will it have an impact at multiple levels?
 Will parts of the system need to change?
 Will other teams support the changes?

You now focus on wide-ranging, interaction between multiple, disparate

systems.
 Management and others look to you for external knowledge and system
understanding.
Teacher vs Dictator
Developer as Hero

 Person others turn to in order to fix problems.

 Brings delayed projects back on track
 Fixes critical systems.

The hero developers are the one called in to bring things back on track.
Developer as Hero Architects

 Assume same skills are useful?

 Is not the architect the one ultimately technically responsible?

The hero developers must take great architects.

Newly Promoted Architects

 Take all available data.

 Internalize it.
 Solve the problem.
 Broadcast the solution.

Simply announce the answer

Best Architects

 Work with developers.

 Understand the facts.
 Guide team to a solution.
 Lead developers to the right decisions.

The best architects guide developers to the right decisions

The best architects are not dictators. They are teachers.
 The best architects work with their teams.
 Need a motivated team to do their best work.
 Leverage experience of the team.
 Train, encourage, and energize the team members.

Architects make the entire organization betters.

 Architect as Evaluator
 Evaluations have huge impact on application.
 The major opportunity to influence application.
 Reviews all major design initiatives.
 Keeps technical debt in mind.
 Input must be direct and actionable.

The Architects Responsibility

 Beyond the design and architecture.
 Performance of the engineers.
o Mentor.
o Technical coach
 Communication
 Explains rationale and reasonings.
 Teaches and grows shared vision.

Learn and Experiment

Anna

 Solves immediate problems.

 Steps back and learns.
 Studies new algorithms.
 Experiments with machine learning.
 Contributes to team and industry as a whole.
Anton

 Similar responsibilities to Anna.

 Dedicates time weekly to self-learning.
 Reads about best practices
 Attends conferences
 Growing networking
Architects

 Take time for self-growth and self-learning.

 Help make better procedures and policies for the team.
 Help make better decisions.
 Help make better architectures.

Train and Coach

Anna

 Selects CloudyAPI service management library.

 Studies how it can help.
 Believes it could be useful for her team.
 Trains her team
 Company is hiring new engineers.
 Inexperienced.
 Mentors and trains.
 Evaluation time.
 Raises and promotions.
 Helps evaluate engineers.
 Mentors to improve.
Anton

 Selects CloudyAPI as well.

 Integration is not working as expected.
 Role: educator and coach.
 Must train and coach entire team.
 Extended member of management team.
 Advocates new initiatives.
 Natural link between team and management.

Responsibilities Beyond Technical

 Train the team on new technologies
 Train new engineers.
 Help evaluate how team members are performing.
 Extension of management team.

Review Plans and Guide Decisions

Anna

 Team has come up to speed.

 Reviews plans
 Keeps team moving in right direction.
Anton
  Existing application issues
 Guides team brainstorming.
 Implements recommendations.
Anna and Anton

 Make decisions
 Train and coach
 Work with peers and stakeholders
 Responsible to their teams, product management, and upper management.

Agile Architecture Processes

Modern Application Architecture

 Ongoing collaboration between developers, product managers, operations, and

infrastructure engineers.
 Fluid and dynamic.
 Requires constant and incremental improvement.
Agile Foundations

 Doug Rose
Agile Software Development

 Shashi Khenar
Constantly Listening to Feedback

 Developers, operations, product management, upper management, and customers.

 Usage grows, expectations clarify, changes are required.
 Listening and responding to feedback
The same agile skills you learned as a developer will help you maintain dynamic
architectures.
Utilizing Sprints

 Sprint cycle is independent and unique from development cycle.

o Architecture should be a bit more stable than development cycles.
 Architecture cycle should lead development cycle.
 Updated architecture becomes input into development cycle.
Growing the Team and Team Skills
  Major responsibility of the architect.
 You may not directly train the team, but you are ultimately responsible for their growth.
 Training is a constant process.
Extension of Management Team

 Evaluate current knowledge and expertise.

 Determine the skill necessary to be successful.
 Create a plan to fill gaps.
 Provide a growth path for the less experienced.
Making sure your team has the skills it needs when they need to be applied is a critical role for a
software architect.
Dev and Ops: Both Work Together
Dev and Ops

 Even with traditional dev-only teams

o You as an architect still have operations responsibility
 Your architecture decisions must focus both on dev and ops.
High Load

 Does it brown out?

 Does it fall behind?
 What is the load limit?
In all organizations, the architect must think about operation and development requirements
Separate Types of Architects

 Separate operations and development architects

o Not every common
 Does not change scope of responsibility, just authority.
 Development architects are still responsible for operational aspects
 Both architects need to work with the other architect closely.
 Avoid “someone else problem” mentality.
You have an opportunity to evangelize and drive forward a DevOps culture within the
organization.
Scale and Availability: Beyond the App

 All modern applications work at a high scale.

o Especially true for software as a service (SaaS) applications.
 All modern applications must maintain high availability.
 o Most sensitive at heavily used times.
 Architecting for Scale. O’REILLY
 Risk management
 Service tiers
 Service connectivity
 Service-level agreements
Mindset Adjustment
As you move from developer to architect, you will need to adjust your mindset.
Your scope of responsibility will expand from a single component to the interconnection of all
components.
Currently an Architect

 Recently became an architect

 Need to understand your job.
Want to be an Architect?

 Currently a developer.
 Looking for next career step.
Next Steps: New Architects

 Reach out to other architects.

 Use your manager.
 Understand business needs of your company.
 Get to know developers.
 Realize that your role is different now
Next Steps: Become an Architect

 Take on more responsibility.

 Look for architectural problems in your application.
 Figure out a plan to fix problems.
Talk to Your Manager
Managers may be reluctant to have you move into an architecture role.
Conversation

 Be prepared for a hard conversation.

 Talk to your manager about the big picture.
 Be understanding of their problems.
 Help groom your replacement.
Unsupportive Manager?

 Find other allies.

 Do not undermine them or their authority.
 Find a mentor (peer manager is best)