How to succeed as an enterprise architect: 4 key strategies

Stepping into the enterprise architect role can be daunting, no matter the situation. An individual taking over at a more mature organization may be called to modernize complex, legacy infrastructure, while someone joining as a company's first enterprise architect may face the pressure of building a new program and transforming cultural norms.

Regardless, there are a few key strategies that any architect can employ to succeed in the role. Calling on both technical and soft skills, these recommendations build respect and enthusiasm among team members while laying out a roadmap that balances short- and long-term priorities. Any architect can lay the foundation for future success by adhering to the following strategies.

1. Build trust

One of the architect's jobs is to guide the evolution of software systems. But actually making those changes is largely the responsibility of other engineers, so cultivating trust with these teams is essential.

Building and maintaining relationships with engineers on the teams requires thoughtful communication and time spent working alongside them. This helps you stay in touch with the implications of architectural decisions and the reality of working with the systems. Software architecture should be highly participatory. By remaining involved with implementation, operation, and maintenance, architects can build rapport and trust with those teams while also gaining valuable context and familiarity with the systems they are designing. In the long run, this will enable better decision-making.

[ Download Cloud-native meets hybrid cloud for a step-by-step guide to tackling modern IT strategy. ]

Architects must also build trust by showing their work. There is no universal "best" system design, and any set of decisions might appear suboptimal without context. A rationale necessarily includes the context for these decisions, which allows a design to stand on its own merit. Ultimately, the goal is to avoid architecture by mandate, which erodes credibility rather than builds it. Enterprise architects who consistently provide compelling arguments for their recommendations will effectively build trust with their engineering teams.

2. Focus on ownership

An engineering organization cannot survive without a healthy attitude toward ownership. It is a critical element for efficiency and morale, which are essential to longevity and growth.

Consider the non-owner versus the owner. Non-owners, through no fault of their own, are set up for drudgery and given too little responsibility to feel invested in the outcome for the business. Owners have much more autonomy and potential for growth and are equipped to build better products. They design and build with context and understand how their part of a project interacts with and serves the rest of the system and stakeholders. They comprehend how what they do from day to day impacts the business. This understanding promotes autonomy in making decisions in a rapidly changing environment.

The architect is one of the few roles with a significant influence on ownership. If architecture and design are too prescriptive or care is not taken to share necessary context, ownership is stifled. It is essential that the architect does not constrain the design so much that the team working on the implementation cannot establish any ownership. Without ownership of anything but the most basic implementation tasks, context will not get shared, morale will diminish for lack of sense of one's contribution, and engineers will not get the opportunity to grow.

An architect can promote ownership simply by bringing others into design processes at an appropriate point. There are certain aspects for which the architect is responsible, but as long as those are met, the teams or individuals should be allowed to have a hand in designing their solutions.

[ Download the digital transformation eBook to gather team tools to drive change. ]

3. Use technical debt effectively

Technical debt should be used intentionally to make incremental gains, not accumulated from neglect. Every architect must decide how to deal with debt—both addressing it and taking it on—to succeed in their role. Get comfortable with technical debt as a tool. The key questions that need to be addressed are when to take on debt and when to pay it off.

Take on debt when the future of a product or feature is uncertain. Whether for a proof of concept or a minimum viable product, use debt to move fast and prove or realize value quickly before committing more cycles to make it robust.

[ Aging legacy systems affect many enterprise IT plans. Get a handle on your technical debt by downloading Technical debt: The IT leader's essential guide. ]

Architects can minimize the impact of debt by first solidifying interfaces. Changes to interfaces impact users. Consequently, these changes are not only sometimes technically difficult but can also be logistically challenging. And the more difficult it is to address debt, the less likely it is to be managed.

Pay down technical debt when its value proposition turns negative and has a measurable impact on the business. That impact could come in the form of decreased engineering velocity, infrastructure brittleness leading to repeated incidents, monetary cost, or many other related effects. These ultimately lead to lost opportunities, revenue, or both. At this point, there is a strong justification for paying down that technical debt

4. Plan for innovation and change

Being able to innovate and adapt are advantages in any competitive landscape. To respond to change and take advantage of unforeseen opportunities, an architect should keep an eye on the future but use it only as general guidance for today's priorities.

To innovate effectively, system architects must strike a balance between specificity and flexibility—accounting for and implementing valuable technologies in the short term while planning for as-yet-unforeseen technologies and circumstances that will change how their companies run in the long term.

There is an inverse relationship between how far ahead architects plan and how much they can assume about the future state of their companies. For architects to be effective stewards of innovation, they need to strike a balance between the far future, near future, and present. At every step, consider the future, but don't allow assumptions about the future to unduly constrain the present. It is not beneficial to design a super-flexible system to meet the far future's demands if they may never come to fruition.

Success is out there

The challenges of modern architecture are demanding but feasible to overcome. Success as an enterprise architect relies on building trust and engagement among engineers, fostering ownership, and providing compelling support for architectural decisions. A healthy relationship with technical debt and balanced consideration of the future are also essential. Of course, every architect must account for their organization's specific culture and needs. Still, these strategies can be invaluable when taking on a new role and establishing a foundation for success.