Can You Relate?
Your success as a software architect depends
on your relationships with stakeholders.
Being a software architect is all about relationships. No, forgetting your
anniversary or not getting along with your
mother-in-law won’t necessarily have any
impact on your success as a software architect. But unless an architect’s relationships
with project stakeholders are based on clear
communication and a thorough understanding of expectations, the project is likely
to end in a scene befitting a reality television
show, with at least the possibility of flying
furniture and crushed dreams.
So if you want to succeed as a software
architect, establishing a solid relationship
with stakeholders and a crystal-clear understanding of their expectations must be job #1
on any project.
The first step in that process is knowing
whom you’re dealing with. Identifying
stakeholders is essential. “You need to know
who has the power to call an engagement a
success or failure,” says Pat Shepherd, enterprise architect at Oracle.
But there’s more to building relationships
than memorizing names and roles—you
need to get inside stakeholders’ heads.
“Make sure you know the stakeholders
and what’s driving them,” says Oracle ACE
Director Ronald van Luttikhuizen, a solution
architect and senior consultant at Approach
Alliance, a Netherlands-based information
and communications technology consultancy
focusing on SOA and business intelligence.
Randy Stafford, a software architect with
the Oracle Coherence development group,
agrees. “The first thing I do is make sure I
understand the motivation for the project,
because it usually translates directly to
measurable success criteria,” Stafford says.
Once you know what your stakeholders want, you need to make sure they
understand what you bring to the table.
“Stakeholders should know you and understand your added value and what you want
JULY/AUGUS T 2011 ORACLE. COM/ORACLEMAGAZINE
“The critical thing
for an architect’s
career is to build a
to achieve with them in the project,” says
van Luttikhuizen. Stakeholders need to smell
what you’re cooking and like it, because
the project has little chance of succeeding
without their complete support.
“This may sound a bit trivial,” adds van
Luttikhuizen, “but I’ve seen too many ivory-
tower architects who just throw something
out there. Without stakeholder support my
architectural activities will not be followed
and will just end up gathering dust.”
In order to earn that support, Brian
Jimerson, a technical architect at Avantia
in Cleveland, Ohio, sets up a project kickoff
meeting with his internal customers. “I want
to ensure that project goals are understood,
establish communication channels, iden-
tify stakeholders and roles, and discuss the
high-level project schedule,” Jimerson says.
He also holds similar kickoff meetings with
development teams to discuss project goals,
milestones, and team structure.
Once you and your stakeholders are
on the same page, it is time to impress
everyone by waving your architecture wand.
“In between the first steps and the project
completion, a combination of creativity and
engineering happens to identify and implement architectures that meet the goals,”
But there has to be some substance
behind the magic. As the project progresses,
it’s important to maintain your relationship
with stakeholders by demonstrating your
progress. “I try to deliver something useful
as early as possible in the project,” says van
Luttikhuizen. “Depending on the type of
architecture assignment—whether my role
is software architect, solution architect, or
enterprise architect—this can be a quick
advice document, a working piece of soft-
ware, or a guideline to help stakeholders.”
These project milestones are important not
just as progress indicators but also as proof
of the value of architecture.
is manager of the
on Oracle Technology
Network, the host of the
Oracle Technology Network ArchBeat podcast
series, and the author of the ArchBeat blog
LIS TEN to ArchBeat podcasts
GET more architect information