The

Evolutionary
Architect
By Abhijeet Gole
Inaccurate Comparisons

• You keep using that word. I do not think it

means what you think it means.
—Inigo Montoya,
from The Princess Bride
 Inaccurate Comparisons

• Architects have well defined role to play in the society

• We are still searching our space
An Evolutionary Vision
for the Architect
An Evolutionary Vision for the Architect

• So, our architects as town planners need to set direction in broad strokes, and only
get involved in being highly specific about implementation detail in limited cases.
• They need to ensure that the system is fit for purpose now, but also a platform for
the future.
• And they need to ensure that it is a system that makes users and developers equally
happy. This sounds like a pretty tall order
Zoning

• service boundaries
• coarse-grained groups of services
• Within each service, you may be OK with the team who
owns that zone picking a different technology stack or data
store.
A Principled Approach

• Rules are for the obedience of fools and the

guidance of wise men.
—Generally
attributed to Douglas
Bader
 A Principled Approach

STRATEGIC GOALS PRINCIPLES PRACTICES COMBINING

PRINCIPLES AND
PRACTICES
Strategic Goals

• What is the driving vision for the business?

• how does it change?
• the nontechnical parts of your organization
 1 2
Principles Principles are rules
you have made in
order to align what
The more
principles you
have, the greater
you are doing to some the chance that
larger goal, and will
sometimes change they overlap or
contradict each
other.
Practices Our practices are how we ensure our principles are being carried
out.

They are a set of detailed, practical guidance for performing

tasks.

They will often be technology specific, and should be low level

enough that any developer can understand them.

Practices could include coding guidelines, the fact that all log
data needs to be captured centrally, or that HTTP/REST is the
standard integration style.

They change often more than the principles due their technical
nature.
Combining
Principles and One person’s principles are another’s practices.
Practices

There is value in having overarching ideas that guide

how the system evolves, and in having enough detail
so that people know how to implement those ideas.

larger organizations, where the technology and

working practices may differ, you may want a different
set of practices in different places, if they both map to
a common set of principles.
A Real-World
Example
The Required Standard

• What is a “good citizen” service in your system?

• What capabilities does it need to have to ensure
that your system is manageable, and that one
bad service doesn’t bring down the whole
system?
• the balance between optimizing for autonomy of
the individual microservice without losing sight
of the bigger picture.
• Defining clear attributes that each service
should have is one way of being clear as to
where that balance sits.
Monitoring • It is essential that we are able to draw up
coherent, cross-service views of our system
health. This has to be a system-wide view,
not a service-specific view.
• Ensure that all services emit health and
general monitoring-related metrics in the
same way.
• Nagios
Interfaces • Picking a small number of defined
interface technologies helps
integrate new consumers.
• Having one standard is a ideal
and two is good.
• But more than that is not
considered to be a good thing
Architectural • We cannot afford for one badly behaved
service to ruin the party for everyone.
Safety
• We must ensure that our services shield
themselves accordingly from unhealthy,
downstream calls.
• This means you will probably want to
mandate as a minimum that each downstream
service gets its own
• connection pool, and you may even go as far
as to say that each also uses a circuit breaker.
Governance
Through Code
•Exemplars
•Tailored Service Template
Exemplars • Developers like code, and code they can run
and explore.
• set of standards or best practices, then having
exemplars that you can point people to is
useful
• The idea is that people can’t go far wrong
just by imitating some of the better parts of
your system.
• Ideally, these should be real-world services
you have that get things right, rather than
isolated services that are just implemented to
be perfect examples.
Tailored Service Template

• Wouldn’t it be great if you could make it really easy for all developers to follow most of the guidelines you
have with very little work?
• What if, out of the box, the developers had most of the code in place to implement the core attributes that each
service needs?
• Dropwizard and Karyon

• By tailoring such a service template for your own set of development practices, you ensure that teams can get
going faster, and also that developers have to go out of their way to make their services badly behaved.
Technical Debt • short-term benefit have long-term cost
• Depending on your organization, you might
be able to provide gentle guidance, but have
the teams themselves decide how to track
and pay down the debt.
• For other organizations, you may need to be
more structured, perhaps maintaining a debt
log that is reviewed regularly
Exception Handling • So our principles and practices guide how
our systems should be built. But what
happens when our system deviates from this?
• Sometimes we make a decision that is just an
exception to the rule.
• In these cases, it might be worth capturing
such a decision in a log somewhere for future
reference.
Governance and • Governance ensures that enterprise
objectives are achieved by evaluating
Leading from the stakeholder needs, conditions and options;
Center setting direction through prioritization and
decision making; and monitoring
performance, compliance and progress
against agreed-on direction and objectives.
—
COBIT 5
Governance and Leading from the Center

• Governance can apply to multiple things in the forum of IT.

• If one of the architect’s jobs is ensuring there is a technical vision, then governance is about ensuring what we
are building matches this vision and evolving the vision if needed.
• Normally, governance is a group activity. It could be an informal chat with a small enough team, or a more
structured regular meeting with formal group membership for a larger scope.
Building a Team • Being the main point person responsible for
the technical vision of your system and
ensuring that you’re executing on this vision
isn’t just about making technology decisions.
• Relevance of Microservices
• With larger, monolithic systems, there
are fewer opportunities for people to
step up and own something. With
microservices
• on the other hand, we have multiple
autonomous codebases that will have
their own independent lifecycles.
Summary • Vision
• Ensure there is a clearly communicated technical vision for the system that will help
your system meet the requirements of your customers and organization
• Empathy
• Understand the impact of your decisions on your customers and colleagues
• Collaboration
• Engage with as many of your peers and colleagues as possible to help define, refine,
and execute the vision
• Adaptability
• Make sure that the technical vision changes as your customers or organization requires
it
• Autonomy
• Find the right balance between standardizing and enabling autonomy for your teams
• Governance
• Ensure that the system being implemented fits the technical vision