How enterprise architects and software architects can better collaborate

The launch of a new product is the result of entire teams of people, each with their own talents and experience, merging their viewpoints and skills to launch a new product. It’s a beautiful thing to witness—except, of course, when it’s not so beautiful and all those viewpoints and skills begin clashing.

One area of potential conflict is the collaboration between enterprise architects and software architects. But these roles are intrinsically connected and when they’re encouraged to be allies, an incredible synergy can emerge. Here are some of the differences between the two roles and how you can bridge those differences so that a beneficial process can emerge.

Enterprise architects vs. software architects

Here’s a short analogy: enterprise architects are like art gallery owners while software architects are like artists. The artists focus on their own art. The art gallery owner focuses on making the gallery run and selling art. Together, they’re able to accomplish their individual goals and make money. 

Here’s a more direct explanation:

Enterprise architects: Enterprise architects look at the high-level strategy of the company. They may analyze the most efficient technology for a company to use or determine the best end-to-end tech strategies to use to meet the business’s goals. Enterprise architects are concerned with how all the company's solutions interact and how they can be improved. EAs are commonly involved in the solution life cycle. They’re concerned with the technology mesh across the entire enterprise and they delegate their recommended solutions to others to implement. Enterprise architects are concerned primarily with innovation, security, and optimization.

Software architects: Software architects have a much more micro view than EAs. They define best practice standards and provide technical guidance and leadership for dev teams. They’re responsible for the design and strategic planning of new products, including software planning, design code methodology, and hardware planning. Software architects are concerned primarily with deployment, compatibility, tech strategy, and support.

When enterprise architects and software architects work together, they can develop an accurate view of the entire IT landscape and how it fits into the future needs of the enterprise. Then they can work together to begin minimizing waste and optimizing resources to meet the priorities of the business. 

Tips for collaboration between enterprise architects and software architects

As you’ve likely gathered from the above definitions, enterprise architects and software architects live in separate worlds, but they rely on each other to achieve their objectives. Here are some strategies for helping these different roles work better together:

1. Make a map

Since EAs have a high-level view of the entire tech ecosystem, they should be encouraged to map out their enterprise architecture and how data needs to flow across the different systems and applications in order to achieve business objectives. 

2. Share the map 

After the EAs have developed the enterprise architecture map, they should share these plans with software architects across each solution, application, or system. After all, it’s important that the software architect who works most closely with the solution shares their own insight and clarity with the enterprise architecture, who is more concerned with high-level architecture.

3. Collaborate 

Software architects and EAs can collaborate and suggest changes or improvements based on the existing architecture. Software architects can then go in and map out the new architecture based on the business requirements. Non-technical leaders can gain a better understanding and this can lead to quicker alignment.

4. Evaluate 

Software architects can evaluate the quality of architecture and share their learnings with the enterprise architect, who can then incorporate findings into the enterprise architecture. Software architects are also largely interested in standardization and they can help enterprise architects scale that standardization across the business.

5. Optimize 

Once the EA has developed a full model or map, it’s easier to see where assets can be reused. Software architects can recommend standardization and innovation and weigh in on the EA’s suggestions of optimizing enterprise resources. This is when reducing costs comes into play alongside helping the business change and grow elegantly and efficiently. 

6. Report 

After a strategy has been agreed upon and the software architect has implemented that strategy, it’s important to keep the enterprise architect apprised of the change. After all, it can be easy to lose track of what’s been implemented and that can end up being quite expensive.

7. Summarize 

The enterprise architect should compile all of their findings and suggestions into a summary document that can be shared with stakeholders so they understand the risks and costs associated with the proposed decisions. This is useful for the software architect as well, since it keeps the ultimate business objectives at the forefront of every implementation. The summary document can serve as a north star for the business’ technological assets and their maintenance, and it can also be changed according to feedback from stakeholders and from the software architects. 

8. Perform a post-mortem 

There’s a chance that the solution that’s implemented isn’t quite what the EA had in mind due to budgetary or time constraints or other myriad reasons. When that happens, thanks to the documentation performed above, it’s easy to see how this improper implementation will impact the rest of the business. The EA should perform this post-mortem or gap analysis and communicate its impost both to the software architect and to other stakeholders. The architects can then work together to address gaps, understand the cause of the gaps, and inform any affected stakeholders.

Benefits of better synchronicity between software architects and EAs

If software architects are concerned primarily with technical blueprints and development best practices and enterprise architects are more interested in high-level strategy, what benefit can there be to encourage them to collaborate? As it turns out, there are many reasons why the two roles should develop a close working relationship. When this happens, your enterprise will likely experience:

• Reduced costs
• Shortened development cycles
• Increased standardization
• Better management of IT assets
• Better risk management
• Better change management
• Better implementation
• Smarter decision-making
• Better communication
• Better alignment between business strategy and IT
• Better optimization of assets

Technical assets are often thought of as the most important and most valuable assets of a company. But without a high-level view of these assets, the entire technological mess can end up affecting the bottom line and undermining business objectives. 

A great enterprise architect will build a high-level map of the enterprise and suggest ways to reuse assets, manage them, and save the business money while improving value. The software architect has the benefit of being more technologically-minded than the enterprise architect and can offer valuable insight into how well a solution can be implemented. When these two roles collaborate, they’ll be able to ascertain which deployments are most important, which are most feasible, and which will impact the rest of the business.