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 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, identify 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,” says Stafford.
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 software, 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.
In the end, software architects are really only as good as their relationships with stakeholders. “Let’s face it—the critical thing for an architect’s career is to build a good reputation,” says Shepherd. Good reputations don’t spring from dysfunctional relationships with stakeholders.
If you want to earn your stripes as a software architect, you can’t relate to stakeholders by flinging furniture at them across the conference room. You need to understand what they want. They need to understand what you can deliver. Bring those two elements together through clear communication and everybody wins.
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 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, identify 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,” says Stafford.
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 software, 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.
In the end, software architects are really only as good as their relationships with stakeholders. “Let’s face it—the critical thing for an architect’s career is to build a good reputation,” says Shepherd. Good reputations don’t spring from dysfunctional relationships with stakeholders.
If you want to earn your stripes as a software architect, you can’t relate to stakeholders by flinging furniture at them across the conference room. You need to understand what they want. They need to understand what you can deliver. Bring those two elements together through clear communication and everybody wins.
No comments :
Post a Comment